date:20210629

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Config-INI-Reader-Orde |perl-Config-INI-Reader-Orde
   |red-0.021-1.fc35|red-0.021-1.fc35
   |perl-Config-INI-Reader-Orde |perl-Config-INI-Reader-Orde
   |red-0.021-1.fc34|red-0.021-1.fc34
   ||perl-Config-INI-Reader-Orde
   ||red-0.021-1.fc33



--- Comment #7 from Fedora Update System  ---
FEDORA-2021-a208f35688 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1973977] perl-Pod-Weaver-4.018 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Pod-Weaver-4.018-1.fc3 |perl-Pod-Weaver-4.018-1.fc3
   |5   |5
   |perl-Pod-Weaver-4.018-1.fc3 |perl-Pod-Weaver-4.018-1.fc3
   |4   |4
   ||perl-Pod-Weaver-4.018-1.fc3
   ||3



--- Comment #7 from Fedora Update System  ---
FEDORA-2021-b58f75f46b has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1973968] perl-Dist-Zilla-Plugin-PodWeaver-4.009 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Dist-Zilla-Plugin-PodW |perl-Dist-Zilla-Plugin-PodW
   |eaver-4.009-1.fc35  |eaver-4.009-1.fc35
   |perl-Dist-Zilla-Plugin-PodW |perl-Dist-Zilla-Plugin-PodW
   |eaver-4.009-1.fc34  |eaver-4.009-1.fc34
   ||perl-Dist-Zilla-Plugin-PodW
   ||eaver-4.009-1.fc33



--- Comment #7 from Fedora Update System  ---
FEDORA-2021-14dd399ce6 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1974142] perl-Config-INI-Reader-Ordered-0.021 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Config-INI-Reader-Orde |perl-Config-INI-Reader-Orde
   |red-0.021-1.fc35|red-0.021-1.fc35
   ||perl-Config-INI-Reader-Orde
   ||red-0.021-1.fc34
 Resolution|--- |ERRATA
Last Closed||2021-06-30 03:15:16



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-1c8320e115 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1973977] perl-Pod-Weaver-4.018 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Pod-Weaver-4.018-1.fc3 |perl-Pod-Weaver-4.018-1.fc3
   |5   |5
   ||perl-Pod-Weaver-4.018-1.fc3
   ||4
 Resolution|--- |ERRATA
Last Closed||2021-06-30 03:15:10



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-2d004ae6b9 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


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

[Bug 1973968] perl-Dist-Zilla-Plugin-PodWeaver-4.009 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Dist-Zilla-Plugin-PodW |perl-Dist-Zilla-Plugin-PodW
   |eaver-4.009-1.fc35  |eaver-4.009-1.fc35
   ||perl-Dist-Zilla-Plugin-PodW
   ||eaver-4.009-1.fc34
 Resolution|--- |ERRATA
Last Closed||2021-06-30 03:15:05



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-2656950f5d has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


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

Re: Fedora Source-git SIG report #1 (June 2021)

2021-06-29 Thread Randy Barlow via devel

On Wed, 2021-06-30 at 01:01 +, Randy Barlow via devel wrote:
> An example of this is gstreamer - in Gentoo I just have
> gstreamer installed, and the various plugin packs like good bad and
> ugly are just USE variables on that one package. 

Ooops, I was wrong on this example. They do package good, bad, ugly as
separate packages.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Attempt to contact "Standard Test Interface" project collaborators

2021-06-29 Thread Michal Schorm

Hello,
I tried to contact the people behind "Standard Test interface" CI.
I sent the e-mail about 3 weeks ago.
Then after about 2 weeks (= ~1 week ago) I reacted to the same email
so it would appear in their inboxes again.

Yet no response came, so i'm trying here.

-- Original message -
From: Michal Schorm 
Date: Wed, Jun 9, 2021 at 9:42 PM
Subject: Fedora - Standard Test Interface - not enough verbose output
To: , ,



Hello,

I have a package: 'mariadb-connector-odbc'.
It has a single STI test in it's dist-git repository, under 'tests' directory.

I've made a PR to the package, attempting (amongst other stuff) to fix the test:
https://src.fedoraproject.org/rpms/mariadb-connector-odbc/pull-request/2#

This is the "Fedora CI - dist-git test", which is passing, but I'm not
satisfied with:
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pipeline/job/master/49774/testReport/(root)/tests/

The thing is, that the Jenkins only show me a quiet log:
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pipeline/job/master/49774/testReport/(root)/tests/mariadb_connection/

However I want to see the verbose log by default.
(A log that does not only show commands ran, but their output too)

I've ran the STI test manually, in a VM.
I've uploaded all the resulting artifacts here:
https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interface-CI/

One of the artifacts is what I got in Jenkins:
https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interface-CI/PASS-mariadb_connection-err.log

And this is the one I want to see in jenkins:
https://mschorm.fedorapeople.org/ARCHIVE/Fedora-PR-Standard_Test_Interface-CI/PASS-mariadb_connection.log

Is there a way to get the type of the result I want from STI ?

--

The artifact I want seems to be generated by default, so it shouldn't
be difficult to add it to the Jenkins, right ?

Also, it might be just a configuration issue in my own test.
If I remember correctly, I wrote this test as an early adopter, about
3 year back. (git blame says 2018-05-10) and maybe I just need to
update my 'tests.yaml' somehow ...

--

Btw the Jenkins calls it "Standard Output", but when I ran it
manually, that output was actually an error log:
  "PASS-mariadb_connection-err.log"
The actual standard log was the verbose one :)
  "PASS-mariadb_connection.log"

--

I've found your contacts here:
https://docs.fedoraproject.org/en-US/ci/standard-test-interface/#_contact

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Source-git SIG report #1 (June 2021)

2021-06-29 Thread Randy Barlow via devel

On Tue, 2021-06-29 at 15:36 +0200, Tomas Tomecek wrote:
> > On the "uni-repo" counter proposal: there's a bunch of real-world
> > examples here of distributions using this successfully:
> >
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow

Hey Tomas!

As Colin noted above, Gentoo uses a single repo (well, technically,
they also have overlays, but the main distro is just one git repo is
what I mean…) I'll add some comments to your thoughts below:

> * Can you imagine maintaining Fedora's 30k+ packages in a single
repo? > Without some git-fetch magic it would be unbearable to perform
a git-pull.

Gentoo has 19,302 packages according to their packages web app[0]. Some
Gentoo packages map to more than one Fedora package, since Gentoo has
slots and uses USE flags. For example, there's just one package called
"python", but you can get various Python versions from the same name
(vs how we have a separate package for each Python version in Fedora).
Programs with lots of plugins end up being one package that has USE
flags for the plugins, where in Fedora the plugins might be packages
separately. An example of this is gstreamer - in Gentoo I just have
gstreamer installed, and the various plugin packs like good bad and
ugly are just USE variables on that one package. I mention these
differences to say that it's probably fair enough to compare the set to
Fedora's 30k.

I will say that a git pull does take some time, especially if you
haven't run it very recently. It's not unusable, but you do notice it
for sure.

I just ran a quick test on two different systems with wildly different
results:

  *  On a system with an ssd I hadn't pulled for two days, and a git
 pull took 0m3.357s.
  *  On a system with a spinny disk I hadn't pulled since January 17,
 and a git pull took 1m27.878s. I'd say that this is probably close
 to a "worst case" scenario, except that I do have a 200 Mbps
 internet connection. Most of the time was spent doing stuff with
 the disk and not on network. I could imagine a slow network making
 this even longer.

I would say this is the top downside to the monorepo approach that I
personally experience. But I also tend to use the SSD system for this,
and also tend to pull often enough that it's not a big deal.

> * Git history would be immensely bloated (though `git log $path`
> would work well).

Yeah I always just use git log $path myself, and it works fine. I also
think it's kinda cool that I can tail a single git log and see what
people have been up to across the project, but we can also do that with
the message broker in Fedora.

> * On the other hand, I like that changes could be done "atomically"
> in a single commit, even for multiple packages.

I *love* this, and to me it's the best thing about the design. If you
have a change to one package that requires a corresponding change in
others, you just do it in a single commit. In Fedora we don't have an
easy automatic process for this. We *could* build one, but it would be
harder to do. With a monorepo, it's just something you get for free.

> * How would CI function?

Due to the atomic commit, I'd say CI could function better because you
know what changes need to be tested together.

Gentoo doesn't have per-package CI that I'm aware of, but they do have
general checks that they do on all packages. They've got a QA bot that
check PRs on GitHub and marks them as pass/fail.

> * Where and how would tests be stored?

As said, I don't think Gentoo does this, but I could imagine having a
tests/ subfolder in the package's folder, not too different from what
we do now.

> * As Neal pointed out, ACL mechanics would need to be thought
> through.

GitHub does have a codeowners feature, which I think could be adapted
for this purpose. One could imagine a server-side git push hook that
checks an ACL rule list against the paths that were altered. I think
such a thing could probably be implemented in not GitHub as well. I
wouldn't say it's trivial to do so, but not extremely difficult either.

> * src.fp.o and koji would need to be updated, significantly.

Agreed.

> * How would contributions be handled? It would be hard to detect
> stalled PRs, maintainers would be swarmed with changes not related to
> their packages.

Here's an example of a Gentoo PR I worked on recently:

https://github.com/gentoo/gentoo/pull/20975

Note that there are two bots that have commented on it. The interesting
one for this question is gentoo-bot - it came and marked the PR with
some metadata, helpful links into the bug tracker, CoC, and other
stuff, and most usefully, labeled the PR with some special labels.

If Fedora had such a bot you could imagine it doing things like
assigning it to the right person (or otherwise notifying them), pinging
long-open PRs, or other things like that.

The other bot on that PR is the Gentoo QA bot, and it does some basic
checks on your

Re: List of long term FTBFS packages to be retired in August


On 30. 06. 21 1:32, Miro Hrončok wrote:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 35 approximately one week before branching (August 
2021).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ 



The packages in rawhide were not successfully built at least since Fedora 32.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb 



If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

     Package  (co)maintainers   Latest build

cardpeek  kalev    Fedora 32


Has ASSIGNED bugzillas since Fedora 33:

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


percona-xtrabackup    slaanesh, slankes    Fedora 32


Has a MODIFIED bugzilla since Fedora 33:

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


php-opencloud-openstack   lcts Fedora 32


Has CLOSED (but not fixed) and NEW bugzillas since Fedora 33:

https://bugzilla.redhat.com/show_bug.cgi?id=1865221
https://bugzilla.redhat.com/show_bug.cgi?id=1923428
https://bugzilla.redhat.com/show_bug.cgi?id=1977297


proxyfuzz psklenar Fedora 32


Had no bugzillas because it failed to build even the SRPM.
I've opened one quite recently:

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


radamsa   huzaifas, mrniranjan Fedora 32


Has no bugzillas, the mass rebuilds builds never finished (they hang for days)


sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31
   tuxbrewr


Fails to install, fails to build since Fedora 32, was exempted from this policy 
last time with a promise of a fix.


Has many bugzillas 
https://bugzilla.redhat.com/buglist.cgi?component=sugar-view-slides=Fedora



zram  pbrobinson   Fedora 32


This might not actually be a FTBFS, but simply a package that has not been 
built in 1.5 years.

It has a noautobuild file with:

> it's a couple of bash scripts, no need for rebuilds

I tend to disagree with that statement. The rebuilds are useful for:

 - new possible dependency generators
 - new possible buildroot policy scripts
 - new RPM/buildsystem features (compression, content signatures, etc.)

I think it's worth rebuilding it at least once in a year.

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

List of long term FTBFS packages to be retired in August


Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 35 approximately one week before branching (August 
2021).


Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 32.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me 
know and we can work together to get a FESCo approval for that.


If you see a package that can be rebuilt, please do so.

Package  (co)maintainers   Latest build

cardpeek  kalevFedora 32
percona-xtrabackupslaanesh, slankesFedora 32
php-opencloud-openstack   lcts Fedora 32
proxyfuzz psklenar Fedora 32
radamsa   huzaifas, mrniranjan Fedora 32
sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31
  tuxbrewr
zram  pbrobinson   Fedora 32


The following packages require above mentioned packages:
Depending on: percona-xtrabackup (1), status change: 2020-11-22 (31 weeks ago)
holland (maintained by: immanetize, jeffreyness, survient)
holland-xtrabackup-1.2.4-2.fc35.noarch requires 
/usr/bin/xtrabackup

Affected (co)maintainers
callkalpa: sugar-view-slides
chimosky: sugar-view-slides
huzaifas: radamsa
immanetize: percona-xtrabackup
jeffreyness: percona-xtrabackup
kalev: cardpeek
lcts: php-opencloud-openstack
mrniranjan: radamsa
pbrobinson: zram, sugar-view-slides
psklenar: proxyfuzz
slaanesh: percona-xtrabackup
slankes: percona-xtrabackup
survient: percona-xtrabackup
tuxbrewr: sugar-view-slides
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)

2021-06-29 Thread Michael Catanzaro

On Tue, Jun 29 2021 at 11:05:26 PM +0200, Dan Čermák 
 wrote:

Thanks a lot for this Michel!


Yes, this will reduce packager pain and suffering. Nice!

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)

2021-06-29 Thread Dan Čermák

Thanks a lot for this Michel!

Ben Cotton  writes:

> https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros
>
> == Summary ==
> Introduce macros, similar to openSUSE's
> [https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
> memory-constraints]), for optionally limiting build parallelism for
> build-time memory-bound packages
>
> == Owner ==
> * Name: [[User:salimma|Michel Alexandre Salim]]
> * Email: michel AT michel-slm DOT name
>
>
> == Detailed Description ==
> Some source packages have a memory usage per build thread higher than
> the RAM:CPU ratio available in some of our builders. Further, this
> ratio can be different for different build server on different
> architectures.
>
> At the moment, such packages
> ([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49733beff6b3/f/ceph.spec#_1269-1390
> ceph], 
> [https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd108ce9874543f2d/f/chromium.spec#_3-14
> chromium], 
> [https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082358745c7882c86/f/mcrouter.spec#_68-82
> mcrouter]) have to implement their own logic for determining the safe
> amount of parallelism, and redefine `_smp_build_ncpus`.
>
> When this proposal is implemented, they can instead declaratively
> specify the amount of RAM needed per build thread, e.g.
>
>   %limit_build -m 8192
>
> for declaring a build thread should be allocated 8GB of RAM.
>
> Since Koji supports
> [https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-changes
> setting default values for macros], there will be a macro for the
> default memory limit (name TBD) that, if set, will be used to cap
> `_smp_build_ncpus` unless overridden by `%limit_build -m`.
> 0
> I'm proposing to tentatively call the macro package
> `build-constraints-rpm-macros` to allow the possibility of adding
> macros for related needs e.g. [https://pagure.io/copr/copr/issue/1678
> build timeouts] to the same package.
>
>
> == Benefit to Fedora ==
> This change simplifies maintaining specs for software that are
> memory-bounded rather than CPU-bounded on our build servers
>
> It could potentially improve build reliability for these packages, by
> reducing the number of jobs failing because of OOM errors, and reduce
> the need for package maintainers to debug these failures.
>
> By keeping the user-facing API aligned with what openSUSE is using, we
> open up the possibility to collaborate with them and with the upstream
> RPM project to get such macros upstreamed into RPM itself (see
> [https://github.com/rpm-software-management/rpm/pull/821 previous
> attempt]). **note** that is not in scope for this Change.
>
> == Scope ==
> * Proposal owners:
> ** Introduce new macros
> ** Update known packages to use the new macros, replacing their custom
> `_smp_build_ncpus` overrides
>
> * Other developers:
> ** The proposal owners might not catch all references of such logic.
> Individual package maintainers can try refactoring their packages
> using these new macros
>
> * Release engineering: [https://pagure.io/releng/issue/10188 #10188]
> No mass rebuild needed. Affected packages should be rebuilt using the new 
> macro
>
> * Policies and guidelines: Packaging guideline can be updated to
> recommend using these macros for build-time memory-bound packages
>
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A
>
>
> == Upgrade/compatibility impact ==
> No impact, affects package building only. Also, the use of the new
> macros are optional.
>
>
>
> == How To Test ==
> 1. Install `build-constraints-rpm-macros`
> 2. Modify spec to set `%limit_build -n AMOUNT_IN_MB` in `%build`
> 3. Rebuild in koji and make sure it passes on all supported architectures
>
>
>
> == User Experience ==
>
>
> == Dependencies ==
> This can optionally be added as dependencies of `redhat-rpm-config`
> and `epel-rpm-macros`, depending on how many packages need this
>
>
>
> == Contingency Plan ==
>
> * Contingency mechanism: (What to do?  Who will do it?)
> Revert changed packages to their previous way of capping the number of
> build jobs
>
> * Contingency deadline: beta
> * Blocks release? No
>
>
> == Documentation ==
> Previous discussion:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU/#GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU
>
> openSUSE implementation:
> https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
>
>
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List

Re: [ELN] Rebuild ordering and side-tag support


On 29. 06. 21 18:59, Kevin Fenzi wrote:

Would these rawhide builds go out in ELN composes?


I suppose they would got here, see below why I think it would be necessary.
The amount of "true ELN" builds in ELN compose would be the general 
"healthiness" factor. When 100 %: perfect. When 90 %: quite good. When less: 
not great, not terrible. And if the ELN compose is 99 % pure rawhide for years, 
it is a signal to maybe reconsider the effort.



Or would you block composes until you had only eln rpms in it?


Juts like the rawhide composes are (almost?) never finished complete, I don't 
think blocking the ELN compose on being 100 % pure ELN is reasonable. It would 
only make the compose harder to actually consume because it would have tendency 
to be very old.


--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support


On 29. 06. 21 21:10, Troy Dawson wrote:

Two issues I see deal with failed builds and new dependencies.
1 - failed builds.
Will there be an easy way for the ELN SIG (or whoever) to see what the failed 
builds are?  Or are all of these builds fire and forget?


Previously, failed build resulted in outdated ELN content and outdated ELN 
builroot and hence more failed (or "wrong") builds.


When nobody has time to deal with the failures, we eventually end up with a 
very old rawhide snapshot where nothing builds. Once the human operator gets to 
it, they need to manually rebbootstrap everything or essentially use the 
current rawhide to populate ELN with "fresh" content once again.


With this proposal, failed builds result in more rawhide content in ELN 
buildroot which does not degrade over time. Worst case scenario where no ELN 
builds are possible for a long time, we'll end up with... 100 % rawhide 
content. Once the failure is fixed, the content starts to be more and more % 
ELN gradually over time.




2 - new dependencies.
Package foo (in ELN list) get's a new dependency bar (not in ELN list).  bar 
will already be built when foo gets updated and built in rawhide and ELN. bar 
will eventually get put on the ELN list.  But with your proposal, bar has the 
potential to not be built in ELN for 6 months.


I don't understand how is this different than the status quo. Current ELN koji 
buildroot already "sees" all Rawhide packages that aren't in ELN.


It would be nice if there was still something like ELN periodic that checked 
what packages haven't been built and attempts to rebuild them.  I know we've 
had a problem in the past with it spamming due to retrying failed builds 
multiple times.  But it is there for a reason.


That is still necessary with this proposal (although it does not need to be 
that aggressive).


--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros

== Summary ==
Introduce macros, similar to openSUSE's
[https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
memory-constraints]), for optionally limiting build parallelism for
build-time memory-bound packages

== Owner ==
* Name: [[User:salimma|Michel Alexandre Salim]]
* Email: michel AT michel-slm DOT name


== Detailed Description ==
Some source packages have a memory usage per build thread higher than
the RAM:CPU ratio available in some of our builders. Further, this
ratio can be different for different build server on different
architectures.

At the moment, such packages
([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49733beff6b3/f/ceph.spec#_1269-1390
ceph], 
[https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd108ce9874543f2d/f/chromium.spec#_3-14
chromium], 
[https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082358745c7882c86/f/mcrouter.spec#_68-82
mcrouter]) have to implement their own logic for determining the safe
amount of parallelism, and redefine `_smp_build_ncpus`.

When this proposal is implemented, they can instead declaratively
specify the amount of RAM needed per build thread, e.g.

  %limit_build -m 8192

for declaring a build thread should be allocated 8GB of RAM.

Since Koji supports
[https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-changes
setting default values for macros], there will be a macro for the
default memory limit (name TBD) that, if set, will be used to cap
`_smp_build_ncpus` unless overridden by `%limit_build -m`.
0
I'm proposing to tentatively call the macro package
`build-constraints-rpm-macros` to allow the possibility of adding
macros for related needs e.g. [https://pagure.io/copr/copr/issue/1678
build timeouts] to the same package.


== Benefit to Fedora ==
This change simplifies maintaining specs for software that are
memory-bounded rather than CPU-bounded on our build servers

It could potentially improve build reliability for these packages, by
reducing the number of jobs failing because of OOM errors, and reduce
the need for package maintainers to debug these failures.

By keeping the user-facing API aligned with what openSUSE is using, we
open up the possibility to collaborate with them and with the upstream
RPM project to get such macros upstreamed into RPM itself (see
[https://github.com/rpm-software-management/rpm/pull/821 previous
attempt]). **note** that is not in scope for this Change.

== Scope ==
* Proposal owners:
** Introduce new macros
** Update known packages to use the new macros, replacing their custom
`_smp_build_ncpus` overrides

* Other developers:
** The proposal owners might not catch all references of such logic.
Individual package maintainers can try refactoring their packages
using these new macros

* Release engineering: [https://pagure.io/releng/issue/10188 #10188]
No mass rebuild needed. Affected packages should be rebuilt using the new macro

* Policies and guidelines: Packaging guideline can be updated to
recommend using these macros for build-time memory-bound packages

* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A


== Upgrade/compatibility impact ==
No impact, affects package building only. Also, the use of the new
macros are optional.



== How To Test ==
1. Install `build-constraints-rpm-macros`
2. Modify spec to set `%limit_build -n AMOUNT_IN_MB` in `%build`
3. Rebuild in koji and make sure it passes on all supported architectures



== User Experience ==


== Dependencies ==
This can optionally be added as dependencies of `redhat-rpm-config`
and `epel-rpm-macros`, depending on how many packages need this



== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?)
Revert changed packages to their previous way of capping the number of
build jobs

* Contingency deadline: beta
* Blocks release? No


== Documentation ==
Previous discussion:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU/#GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU

openSUSE implementation:
https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: Filtered Flathub Applications (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications

== Summary ==
Enabling third-party repositories will now create a Flathub remote
that is a filtered view of Flathub.

== Detailed Description ==
'Note that this proposal is about user experience, procedures, and
technology - the high-level concept has already been discussed and
approved by the Fedora Council and FESCO.'

Enabling third-party repositories will now create a Flathub remote
that is a filtered view of Flathub. This means that applications on
Flathub that have been explicitly approved (by a new process proposed
here) will be available in GNOME Software and on the
flatpak command line. If the user follows following the
instructions on https://flatpak.org/setup/Fedora/, then the filter is
removed, and the user gets a full view of Flathub.

Roughly speaking, the criteria for including software is a) will not
cause legal or other problems for Fedora to point to b) does not
overlap Fedora Flatpaks or software in Fedora that could easily be
made into a Flatpak c) works reasonably well. For Fedora 35, We expect
to include all software from the top 50 most popular applications on
Flathub that meet these criteria plus selected other software of
interest to the Fedora target audience - Fedora community members are
welcome to propose additions.

Already reviewed: Zoom, Microsoft Teams, Skype, Bitwarden, Postman,
Minecraft
Other likely software from the top 50: Discord, Anydesk, WPS Office,
OnlyOffice, MasterPDFEditor, Slack, UngoogledChromium, Flatseal,
WhatsAppQT, GreenWithEnvy

The expectation is that many included applications will be things that
are hard or impossible to package in Fedora - proprietary
applications, Electron-based applications, and so forth. This is
consistent with the third-party software policy, and does not reflect
a change from what we do currently with third-party repositories.

Fedora Workstation Issue:
[https://pagure.io/fedora-workstation/issue/108 #108 Add selected
Flathub apps to the third-party repos]

== Conformance to Fedora policies ==

The goal here is to be in conformance with the Fedora
[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/
Third-Party Repository Policy]. The current form of this policy was
explicitly written and approved with the filtered view of Flathub
being one of the use cases. See
https://pagure.io/fesco/fesco-docs/pull-request/34

In detail, this proposal meets
[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/#_key_requirements_for_third_party_repositories
Key requirements for third-party repositories]. We consider each
application included in the filter as a separate "mini" repository

Third-party repositories must be approved by an active Fedora working
group or SIG, or by FESCo. Groups who approve the inclusion of third
party repositories must have a documented process which allows for
community input, which produces a traceable history for each decision
(for example, a ticket or other record).

The traceable process is filing a merge request to
https://pagure.io/fedora-flathub-filter/

Additionally, repositories included in an edition or spin’s
third-party repository list must conform to the following
requirements:

* Just as with any software hosted by Fedora, third party repositories
must not contain material that poses an undue legal risk for the
Fedora Project or its sponsors. This risk includes, but is not limited
to, software with known patent issues, copyright issues, or software
tailored for conducting illegal activities. Fedora working groups
should evaluate if a proposed addition or provider poses a significant
risk, and if in doubt, confer with Fedora Legal for advice.

This is done for each pull request to the `fedora-flathub-filter` repository.

* Changes made by one Edition or spin should not impact other Fedora
editions or spins.

Each spin has the ability to include filtered view of Flathub or not.
We do not foresee having *separate* filters for different spins.

* Working groups and SIGs should maintain oversight over the software
that is made available through third-party repositories, to prevent
unvetted software being made available to Fedora users. As part of
this, third-party repositories should allow easy auditing by Fedora
Legal. This requirement implies that third-party repositories should
limit themselves to a small number of packages, or that measures
should be put in place to define which packages are made available
from a particular repository by default.

The filter is a "measure ... to define which packages are made available".

== Technical implementation ==

* The fedora-third-party script added by
[[Changes/Third_Party_Software_Mechanism]] will also include support
for Flatpak repositories.
* A new package fedora-flathub-repository will be added
with a configuration file
/etc/fedora-third-party.d/flathub.conf and a file
/etc/flatpak/filters/fedora-flathub.filter that is

F35 Change: Third-party Software Mechanism (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/Third_Party_Software_Mechanism

== Summary ==
Update mechanism for opting-in to "Third-Party Software Repositories"
so that the repositories are immediately enabled.

== Owner ==
* Name: [[User:otaylor| Owen Taylor]]
* Email: otay...@redhat.com


== Detailed Description ==
''Note that this proposal is about a change to how third-party
repositories are enabled, not about including anything new in
Fedora.'

Currently, when the user opts in to "Enable Third-Party Software
repositories", the` fedora-workstation-repositories` package is
installed, but with the repositories disabled.
With this change, `fedora-workstation-repositories` will be installed
by default (required by `fedora-release-workstation`), and opting in
to "Third-party Software Repositories" will actually enable the
repositories.

Fedora Workstation Issue:
[https://pagure.io/fedora-workstation/issue/105 #105 Ship
fedora-workstation-repositories on install media]

== Conformance to Fedora policies ==

[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/
Third-Party Repository Policy]:


The third-party nature of the repository must be apparent to the user
when they enable it, as should the non-free status of its content, if
such. To ensure this, repository files must initially include the
enabled=0 (or equivalent) setting, and the user must explicitly enable
third-party repositories to install from them.


This proposals is a new implementation of "explictly enable
third-party repositories". There is no proposed change to which
third-party repostories are shipped - and in particular this change
does not include splitting fedora-workstation-repositories to conform
to the recommendation of the current guidelines.

== Technical implementation ==

* There is a fedora-third-party package with a
fedora-third-party script with
enable/disable/refresh/query subcommands. The status is
stored in /etc/fedora-third-party.conf
* Packages like fedora-workstation-repositories that
include third-party repositories will drop config files into
/etc/fedora-third-party.d/*.conf. There will be a
post-transaction file trigger to run fedora-third-party
refresh, which applies the users opt-in status to newly
installed repository files.
* We add a new page to GNOME Initial Setup that asks a single
question, *along the lines of*:
'''Enable Third Party Software repositories?''' 
☑ Access additional software from selected third party sources. Some
of this software is proprietary and therefore has restrictions on use,
sharing, and access to source code. 
[Find out 
more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories)
* If the user leaves the box checked, GNOME Initial setup runs
`fedora-third-party enable`.
* For upgrades, GNOME Software shows an info-bar with the same
question if no status is stored in `/etc/fedora-thirdparty.conf`

== Feedback ==


== Benefit to Fedora ==

The main benefit of this proposal is the removal of the state where
the user has opted in to third party repositories but they are not
actually enabled. PackageKit supports the
enabled_metadata=1 key in a repository file, which allows
applications to be searched in this state, but this is not supported
by DNF.

The new method is also easily extensible to Flatpaks, where there also
no equivalent to enabled_metadata=1, even in GNOME
Software.

== Scope ==
* Proposal owners: Create and test proposed
fedora-third-party package. Implement the graphical
controls for this in GNOME Software and gnome-initial-setup.
* Release engineering: [https://pagure.io/releng/issue/10186 #10186]
No changes are required.
* Policies and guidelines: Third-party Software guidelines will need
minor changes to remove references to `enabled_metadata=1`. Pending
finalization of technical implementation.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No real alignment

== Upgrade/compatibility impact ==
Because the "opt-in" status to 3rd party software is currently
represented by whether fedora-workstation-repositories is installed,
and because fedora-workstation-repositories will become an
installed-by-default package, users will need to opt-in again.

They can do this either by responding in the infobar that will be
displayed in GNOME Software, or by running fedora-third-party
enable on the command line.

== How To Test ==
* A fresh install of Fedora Workstation where the user ''does not''
opt-in should have all repositories disabled.
* A fresh install of Fedora Workstation where the user ''does'' opt-in
should have all 3rd-party repositories enabled.
* On an upgrade from F34, if the user opts-out, the enablement status
of third-party repositories should be ''unchanged'' (try enabling one
before the upgrade)
* On an upgrade from F35, if the user opts-in, all 3rd party
repositories should be enabled.

== User Experience ==
The user will get less confusing behavior around third-party
repositories

F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/MemoryConstraintsMacros

== Summary ==
Introduce macros, similar to openSUSE's
[https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints
memory-constraints]), for optionally limiting build parallelism for
build-time memory-bound packages

== Owner ==
* Name: [[User:salimma|Michel Alexandre Salim]]
* Email: michel AT michel-slm DOT name


== Detailed Description ==
Some source packages have a memory usage per build thread higher than
the RAM:CPU ratio available in some of our builders. Further, this
ratio can be different for different build server on different
architectures.

At the moment, such packages
([https://src.fedoraproject.org/rpms/ceph/blob/d7454e4e0a98208dc569553b901a49733beff6b3/f/ceph.spec#_1269-1390
ceph], 
[https://src.fedoraproject.org/rpms/chromium/blob/baaf27b384295d6288ef367dd108ce9874543f2d/f/chromium.spec#_3-14
chromium], 
[https://src.fedoraproject.org/rpms/mcrouter/blob/a0f7ecad2ccc51c4214646b082358745c7882c86/f/mcrouter.spec#_68-82
mcrouter]) have to implement their own logic for determining the safe
amount of parallelism, and redefine `_smp_build_ncpus`.

When this proposal is implemented, they can instead declaratively
specify the amount of RAM needed per build thread, e.g.

  %limit_build -m 8192

for declaring a build thread should be allocated 8GB of RAM.

Since Koji supports
[https://docs.pagure.org/koji/release_notes/release_notes_1.18/#system-changes
setting default values for macros], there will be a macro for the
default memory limit (name TBD) that, if set, will be used to cap
`_smp_build_ncpus` unless overridden by `%limit_build -m`.
0
I'm proposing to tentatively call the macro package
`build-constraints-rpm-macros` to allow the possibility of adding
macros for related needs e.g. [https://pagure.io/copr/copr/issue/1678
build timeouts] to the same package.


== Benefit to Fedora ==
This change simplifies maintaining specs for software that are
memory-bounded rather than CPU-bounded on our build servers

It could potentially improve build reliability for these packages, by
reducing the number of jobs failing because of OOM errors, and reduce
the need for package maintainers to debug these failures.

By keeping the user-facing API aligned with what openSUSE is using, we
open up the possibility to collaborate with them and with the upstream
RPM project to get such macros upstreamed into RPM itself (see
[https://github.com/rpm-software-management/rpm/pull/821 previous
attempt]). **note** that is not in scope for this Change.

== Scope ==
* Proposal owners:
** Introduce new macros
** Update known packages to use the new macros, replacing their custom
`_smp_build_ncpus` overrides

* Other developers:
** The proposal owners might not catch all references of such logic.
Individual package maintainers can try refactoring their packages
using these new macros

* Release engineering: [https://pagure.io/releng/issue/10188 #10188]
No mass rebuild needed. Affected packages should be rebuilt using the new macro

* Policies and guidelines: Packaging guideline can be updated to
recommend using these macros for build-time memory-bound packages

* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A


== Upgrade/compatibility impact ==
No impact, affects package building only. Also, the use of the new
macros are optional.



== How To Test ==
1. Install `build-constraints-rpm-macros`
2. Modify spec to set `%limit_build -n AMOUNT_IN_MB` in `%build`
3. Rebuild in koji and make sure it passes on all supported architectures



== User Experience ==


== Dependencies ==
This can optionally be added as dependencies of `redhat-rpm-config`
and `epel-rpm-macros`, depending on how many packages need this



== Contingency Plan ==

* Contingency mechanism: (What to do?  Who will do it?)
Revert changed packages to their previous way of capping the number of
build jobs

* Contingency deadline: beta
* Blocks release? No


== Documentation ==
Previous discussion:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU/#GWSXTGOCMNXHPGMTW32LI5EKPGHDKCFU

openSUSE implementation:
https://build.opensuse.org/package/show/openSUSE:Factory/memory-constraints


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: Filtered Flathub Applications (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications

== Summary ==
Enabling third-party repositories will now create a Flathub remote
that is a filtered view of Flathub.

Fedora Workstation Issue:
[https://pagure.io/fedora-workstation/issue/108 #108 Add selected
Flathub apps to the third-party repos]

== Conformance to Fedora policies ==

The traceable process is filing a merge request to
https://pagure.io/fedora-flathub-filter/

Additionally, repositories included in an edition or spin’s
third-party repository list must conform to the following
requirements:

This is done for each pull request to the `fedora-flathub-filter` repository.

* Changes made by one Edition or spin should not impact other Fedora
editions or spins.

Each spin has the ability to include filtered view of Flathub or not.
We do not foresee having *separate* filters for different spins.

The filter is a "measure ... to define which packages are made available".

== Technical implementation ==

F35 Change: Third-party Software Mechanism (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/Third_Party_Software_Mechanism

== Summary ==
Update mechanism for opting-in to "Third-Party Software Repositories"
so that the repositories are immediately enabled.

== Owner ==
* Name: [[User:otaylor| Owen Taylor]]
* Email: otay...@redhat.com


== Detailed Description ==
''Note that this proposal is about a change to how third-party
repositories are enabled, not about including anything new in
Fedora.'

Currently, when the user opts in to "Enable Third-Party Software
repositories", the` fedora-workstation-repositories` package is
installed, but with the repositories disabled.
With this change, `fedora-workstation-repositories` will be installed
by default (required by `fedora-release-workstation`), and opting in
to "Third-party Software Repositories" will actually enable the
repositories.

Fedora Workstation Issue:
[https://pagure.io/fedora-workstation/issue/105 #105 Ship
fedora-workstation-repositories on install media]

== Conformance to Fedora policies ==

[https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/
Third-Party Repository Policy]:


The third-party nature of the repository must be apparent to the user
when they enable it, as should the non-free status of its content, if
such. To ensure this, repository files must initially include the
enabled=0 (or equivalent) setting, and the user must explicitly enable
third-party repositories to install from them.


This proposals is a new implementation of "explictly enable
third-party repositories". There is no proposed change to which
third-party repostories are shipped - and in particular this change
does not include splitting fedora-workstation-repositories to conform
to the recommendation of the current guidelines.

== Technical implementation ==

* There is a fedora-third-party package with a
fedora-third-party script with
enable/disable/refresh/query subcommands. The status is
stored in /etc/fedora-third-party.conf
* Packages like fedora-workstation-repositories that
include third-party repositories will drop config files into
/etc/fedora-third-party.d/*.conf. There will be a
post-transaction file trigger to run fedora-third-party
refresh, which applies the users opt-in status to newly
installed repository files.
* We add a new page to GNOME Initial Setup that asks a single
question, *along the lines of*:
'''Enable Third Party Software repositories?''' 
☑ Access additional software from selected third party sources. Some
of this software is proprietary and therefore has restrictions on use,
sharing, and access to source code. 
[Find out 
more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories)
* If the user leaves the box checked, GNOME Initial setup runs
`fedora-third-party enable`.
* For upgrades, GNOME Software shows an info-bar with the same
question if no status is stored in `/etc/fedora-thirdparty.conf`

== Feedback ==


== Benefit to Fedora ==

The main benefit of this proposal is the removal of the state where
the user has opted in to third party repositories but they are not
actually enabled. PackageKit supports the
enabled_metadata=1 key in a repository file, which allows
applications to be searched in this state, but this is not supported
by DNF.

The new method is also easily extensible to Flatpaks, where there also
no equivalent to enabled_metadata=1, even in GNOME
Software.

== Scope ==
* Proposal owners: Create and test proposed
fedora-third-party package. Implement the graphical
controls for this in GNOME Software and gnome-initial-setup.
* Release engineering: [https://pagure.io/releng/issue/10186 #10186]
No changes are required.
* Policies and guidelines: Third-party Software guidelines will need
minor changes to remove references to `enabled_metadata=1`. Pending
finalization of technical implementation.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No real alignment

== Upgrade/compatibility impact ==
Because the "opt-in" status to 3rd party software is currently
represented by whether fedora-workstation-repositories is installed,
and because fedora-workstation-repositories will become an
installed-by-default package, users will need to opt-in again.

They can do this either by responding in the infobar that will be
displayed in GNOME Software, or by running fedora-third-party
enable on the command line.

== How To Test ==
* A fresh install of Fedora Workstation where the user ''does not''
opt-in should have all repositories disabled.
* A fresh install of Fedora Workstation where the user ''does'' opt-in
should have all 3rd-party repositories enabled.
* On an upgrade from F34, if the user opts-out, the enablement status
of third-party repositories should be ''unchanged'' (try enabling one
before the upgrade)
* On an upgrade from F35, if the user opts-in, all 3rd party
repositories should be enabled.

== User Experience ==
The user will get less confusing behavior around third-party
repositories

Re: [ELN] Rebuild ordering and side-tag support

2021-06-29 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Jun 29, 2021 at 08:34:06PM +0200, Robert-André Mauchin wrote:
> On 6/28/21 5:55 PM, Stephen Gallagher wrote:
> >Summary: I think we can fix the ELN side-tag rebuild problems and make
> >the composes more reliable if we change the mechanism for kicking off
> >rebuilds. I'm soliciting feedback to help identify potential issues
> >with this proposed approach.
> >
> 
> How do you handle packages that need bootstrapping? Several Go
> packages must be built in a certain order with bootstrapping on, on
> a virgin branch. It takes auite a lot of time.

After reading the proposal, I assume the following:
after the bootstrap is done, you can rebuild any of the packages
involved freely. So with the updated package merged into the buildroot
from rawhide, you can just rebuild the packages in eln in any order.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1977466] New: perl-CPAN-FindDependencies-3.06 is available

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

Bug ID: 1977466
   Summary: perl-CPAN-FindDependencies-3.06 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-FindDependencies
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.06
Current version/release in rawhide: 3.05-2.fc35
URL: http://search.cpan.org/dist/CPAN-FindDependencies/

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


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


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


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


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support

2021-06-29 Thread Troy Dawson

On Mon, Jun 28, 2021 at 9:21 AM Stephen Gallagher 
wrote:

> Summary: I think we can fix the ELN side-tag rebuild problems and make
> the composes more reliable if we change the mechanism for kicking off
> rebuilds. I'm soliciting feedback to help identify potential issues
> with this proposed approach.
>
>
> ## Background Information ##
> Currently in ELN, merging a side-tag into Rawhide results in all of
> the packages from that side-tag being rebuilt concurrently in ELN.
> This leads to two problems:
>
>  1. Side-tags containing large numbers of package builds will trigger
> many ELN builds at the same time, possibly overwhelming available
> resources on the ELN automation systems.
>  2. Many (most?) side-tags exist to ensure that packages are built in
> a particular order so as to ensure that they are built after their
> dependencies. Launching all the rebuilds concurrently means that many
> of the builds may succeed *and still be wrong* (such as if they are
> built against an older soname).
>
> ## Proposed Solution ##
> I had a discussion with Miro Hrončok this morning where we tackled
> this problem and may have come up with a workable solution for 99% of
> cases. Instead of treating side-tags as a special event and trying to
> sort the builds such that they are built in the same order, we can
> instead tag in the Rawhide packages first, then issue the rebuilds
> together. With the Rawhide packages available, we won't need to worry
> about the ordering, because the dependencies will already be present
> in a sufficiently-recent version. As a bonus, we'll reduce the
> likelihood of broken ELN composes, since if an ELN rebuild fails, the
> Rawhide version will still be present to satisfy dependencies.
>
> In greater detail:
>
> Whenever a build is tagged into the 'f35' tag (later, whatever tag
> matches Rawhide), ELN automation would take the following steps:
>
>  * Identify whether this package is on the list of packages that ELN
> rebuilds[1]
>  * Tag the Rawhide build into the 'eln' tag (so it is now tagged with
> both 'f35' and 'eln')
>  * Enqueue a Koji build against the 'eln' target from the same Git commit
>
> The queue mentioned above should be maintained in a separate thread
> and used to submit tasks in batches to avoid overloading the
> infrastructure. If the Koji build against the 'eln' target fails, the
> Rawhide build will remain as the most-recently-tagged version of the
> package in ELN and become part of the compose until the ELN rebuild
> can be fixed.
>
> Note that this process would apply to ALL builds in Rawhide, not just
> those coming from side-tags. There would be no difference in behavior
> between standard direct builds and side-tag merged builds.
>
>
> ## Known potential issues ##
>
>  * Some packages may auto-detect functionality based on functionality
> made available by one of their dependencies. If the Rawhide and ELN
> versions of that dependency differ in visible functionality, then
> building an ELN package with a Rawhide version of its dependency could
> result in unexpected behavior. I believe this issue to be rare and
> generally best handled by the packager as the subject matter expert.
> They'd just need to bump the release number and rebuild the package in
> ELN. Alternatively, if this is known to be regularly problematic for a
> package, the maintainer can opt out of the automatic rebuild and work
> out a strategy with the ELN SIG for dealing with it.
>
>
>
> [1] This will be the set of packages provided by
> https://tiny.distro.builders/view--view-eln.html minus any packages
> that have opted out of automatic rebuilds (they perform manual
> rebuilds for ELN).
>
>
Two issues I see deal with failed builds and new dependencies.
1 - failed builds.
Will there be an easy way for the ELN SIG (or whoever) to see what the
failed builds are?  Or are all of these builds fire and forget?

2 - new dependencies.
Package foo (in ELN list) get's a new dependency bar (not in ELN list).
bar will already be built when foo gets updated and built in rawhide and
ELN. bar will eventually get put on the ELN list.  But with your proposal,
bar has the potential to not be built in ELN for 6 months.
It would be nice if there was still something like ELN periodic that
checked what packages haven't been built and attempts to rebuild them.  I
know we've had a problem in the past with it spamming due to retrying
failed builds multiple times.  But it is there for a reason.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Golang 1.17 (System-Wide Change proposal)

2021-06-29 Thread Alejandro Sáez Morollón

According to upstream, they are not going to deprecate GOPATH yet in this 
version.

I built etcd with 1.17beta1 and everything went fine.

> On 29 Jun 2021, at 20:42, Robert-André Mauchin  wrote:
> 
> On 6/28/21 6:57 PM, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/golang1.17
>> == Summary ==
>> Rebase of Golang package to upcoming version 1.17 in Fedora 35,
>> including the rebuild of all dependent packages(the pre-release
>> version of Go will be used for the rebuild if released version will
>> not be available at the time of the mass rebuild).
>> == Owner ==
>> * Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka|
>> Jakub Čajka]]
>> * Email: a...@redhat.com, jca...@redhat.com
> 
> Won't we have a problem since 1.17 is deprecating the gopath way to use Go 
> modules instead. We didn't manage to port our macros to Go modules due to 
> Nicolas Mailhot being MIA since last year, and even if we manage that, I 
> personally won't have the time to rebuild the entire ecosystem. I'm already 
> have problems dealing with all the updates, while taking care of the Package 
> Reviews too.
> Won't this break our entire Go ecosystem?
> 
> Best regards,
> 
> Robert-André
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Golang 1.17 (System-Wide Change proposal)

2021-06-29 Thread Robert-André Mauchin


On 6/28/21 6:57 PM, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/golang1.17

== Summary ==
Rebase of Golang package to upcoming version 1.17 in Fedora 35,
including the rebuild of all dependent packages(the pre-release
version of Go will be used for the rebuild if released version will
not be available at the time of the mass rebuild).

== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]], [[User:Jcajka|
Jakub Čajka]]
* Email: a...@redhat.com, jca...@redhat.com



Won't we have a problem since 1.17 is deprecating the gopath way to use 
Go modules instead. We didn't manage to port our macros to Go modules 
due to Nicolas Mailhot being MIA since last year, and even if we manage 
that, I personally won't have the time to rebuild the entire ecosystem. 
I'm already have problems dealing with all the updates, while taking 
care of the Package Reviews too.

Won't this break our entire Go ecosystem?

Best regards,

Robert-André
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support

2021-06-29 Thread Robert-André Mauchin


On 6/28/21 5:55 PM, Stephen Gallagher wrote:

Summary: I think we can fix the ELN side-tag rebuild problems and make
the composes more reliable if we change the mechanism for kicking off
rebuilds. I'm soliciting feedback to help identify potential issues
with this proposed approach.



How do you handle packages that need bootstrapping? Several Go packages 
must be built in a certain order with bootstrapping on, on a virgin 
branch. It takes auite a lot of time.


Best regards,

Robert-André
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: IBus 1.5.25 (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/IBus_1.5.25

== Summary ==
IBus 1.5.25 will use `transfiletriggerin` script to generate the cache
file instead of `posttrans` script in each engine package, support the
include directive in the user compose file, IBus compose feature will
follow the GTK4 compose pre-edit style, the emoji shortcut key will be
changed to `Ctrl-period`, IBus GTK4 module will proceed the key events
synchronistically to follow GTK4 specification.

== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com


== Detailed Description ==
* Each IBus language engine has run `posttrans` script to run `ibus
write-cache` to cache their component files in
/usr/share/ibus/component whenever the package is installed but `ibus
write-cache` will moved to `transfiletriggerin` script in IBus core
package and the script will be executed only one time per the Fedora
installation.
* IBus compose file will support the include directive in the user
compose file ($XDG_CONFIG_HOME/ibus/Compose,
$XDG_CONFIG_HOME/gtk-3.0/Compose or $HOME/.XCompose)
* IBus compose feature will follow the
[https://blog.gtk.org/2021/03/24/input-revisited/ GTK4 compose
pre-edit style].
* IBus emoji shortcut key is `Ctrl-Shift-e` and it will be changed to
`Ctrl-period` to follow the latest GTK while it's customizable with
`ibus-setup` utility.
* IBus GTK3 module proceeds the key events asynchronistically because
some langauge engines spend much time to compose key events and D-Bus
process could causes a timeout but now GTK4 does not allow the async
events and IBus GTK4 module will proceed the key events
synchronistically.

== Feedback ==
* Only one `transfiletriggerin` script is much simpler than many
`posttrans` scripts.


== Benefit to Fedora ==
Users can use the include directive in their compose files. IBus GTK4
module can send the application specific keys of Backspace, Enter to
the target application to follow GTK4 specification,

== Scope ==
* Proposal owners: Update SPEC file to add `transfiletriggerin`
script. Update libibus.so to enhance compose feature. Update
org.freedesktop.ibus.gschema.xml for emoji shortcut key. Update
libim-ibus.so to fix IBus sync process.

* Other developers: Update SPEC files to delete `posttrans` script.
* Release engineering: [https://pagure.io/releng/issue/10184 #10184]
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:

== Upgrade/compatibility impact ==
We should avoid regressions with `transfiletriggerin` script in the
Fedora installation.


== How To Test ==
# Install ibus and the language engine packages
# `ibus read-cache --system` shows the installed engines.
# `rpm -q --scripts` does not show `ibus write-cache` in engine packages
# `rpm -q --filetriggers` shows `ibus write-cache` in ibus package

# Write the line of 'include "%H/foo.compose"' in your $HOME/.XCompose
and some compose sequences in $HOME/foo.compose
# Run `gnome-control-center keyboard` and configure some IBus language
engines besides XKB engines, likes ibus-hangul, ibus-typing-booster
# Enable an XKB engine with Super-space or clicking of the keyboard
idicator in GNOME
# Launch gedit
# Confirm your compose sequences in $HOME/foo.compose is reflected
# Confirm compose preedit is short

# Run `gnome-control-center keyboard` and configure some IBus language
engines besides XKB engines, likes ibus-hangul, ibus-typing-booster
# Enable an XKB engine with Super-space or clicking of the keyboard
idicator in GNOME
# Launch gedit
# Type Ctrl-period
# Confirm emoji pre-edit and lookup table is available

# Install gtk4-devel
# Run `env GTK_IM_MODULE=ibus gtk4-demo`
# Backspace, Enter keys works


== User Experience ==
The emoji shortcut key is changed if users do not customize it but
they can customize it with ibus-setup utility.


== Dependencies ==
ibus-anthy, ibus-chewing, ibus-hangul, ibus-input-pad, ibus-kkc,
ibus-libpinyin, ibus-rawcode, ibus-sayura, ibus-skk, ibus-table,
ibus-typing-booster, mozc  (`posttrans` script has already been
deleted in each engine package in Fedora rawhide.)

== Contingency Plan ==
* Contingency mechanism: Revert the change to IBus.
* Contingency deadline: Beta release
* Blocks release? No


== Documentation ==
TBD



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)

On Tue, Jun 29, 2021 at 2:07 PM Ben Cotton  wrote:
>
> == Contingency Plan ==
> * Contingency mechanism: If glibc 2.34 provides too disruptive to
> compiling the distribution we could revert to 2.33, but given that
> Rawhide has started tracking glibc 2.34, no show-stopper problems are
> expected.  At this point, we can still revert to upstream version 2.33
> if insurmountable problems appear, but to do so may require a mass
> rebuild to remove new symbols from the ABI/API.
> * Contingency deadline: Upstream glibc ABI freeze deadline of 2021-07-01.
>
I notice that the listed contingency deadline is two days from now, so
it will have passed before this even makes it to FESCo for vote. Is
that date correct?

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/GNUToolchainF35

== Summary ==
Switch the Fedora 35 GNU Toolchain to gcc 11 (lastest point release),
binutils 2.37, and glibc 2.34.

The gcc 11 is already included in Fedora 34, but the release will be
updated to the latest point release. The glibc 2.34 change will be
tracked in this top-level GNU Toolchain system-wide update. Likewise
the binutils 2.37 release will be tracked in this top-level GNU
Toolchain system-wide update.
The gdb 10.2 is already in Fedora 34, but the release will be updated
to the latest point release.

== Owner ==
* Name: [[User:codonell|Carlos O'Donell]]
* Email: car...@redhat.com


== Detailed Description ==


The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities
make up the core part of the GNU Toolchain and it is useful to
transition these components as a complete implementation when making a
new release of Fedora.

The GNU Compiler Collection has already released version 11 containing
many new features documented here:
https://gcc.gnu.org/gcc-11/changes.html. The latest point release for
gcc 11 will be included in Fedora 35, this will be either 11.1
(already released in April) or 11.2 (released later).

The GNU C Library version 2.34 will be released at the beginning of
August 2021; we have started closely tracking the glibc 2.34
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 35 will branch after the
glibc 2.34 upstream release. However, the mass rebuild schedule means
Fedora 35 will mass rebuild (if required) after glibc 2.34 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.

The GNU Binutils version 2.37 will be released near the end of July 2021;

The GNU Debugger verion 10.2 is already released.

== Benefit to Fedora ==
Stays up to date with latest features, improvements security and bug
fixes from gcc, binutils and glibc upstream.

The goal is to track and transition to the latest components of the
GNU Toolchain.

== Scope ==
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, ...)
The gcc and glibc teams will need to move their respective upstream
projects to a releasable state.  For GCC this includes correctly
building Fedora rawhide.

* Other developers: Developers need to ensure that gcc, binutils, and
glibc in rawhide are stable and ready for the Fedora 35 branch. Given
that glibc is backwards compatible and we have been testing the new
glibc in rawhide it should make very little impact when updated,
except for the occasional deprecation warnings and removal of legacy
interfaces from public header files.  An update to GCC 11.2 would be a
minimal change with bug fixes. The binutils 2.37 update has the
broadest scope for change and generated object files should be
reviewed and failures to build analyzed.



A mass rebuild is strongly encouraged. The glibc 2.34 release merges
libpthread.so into libc.so and it would be important to remove
DT_NEEDED on libpthread.so from all distribution binaries.

* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
The compiler, the static linker and the the library are backwards
compatible with the previous version of Fedora.

Some packaging changes may be required for the glibc 2.34 rebase:
https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes

Some source changes may be required for gcc 11 rebase:
https://gcc.gnu.org/gcc-11/changes.html
All changes for gcc 11 will have been included in Fedora 34 alraedy.

There should be no need for any changes to accommodate the new GNU
Binutils release.

We fully expect to fix all packaging changes in Fedora Rawhide without
impact to the release.

== How To Test ==
The GNU C compiler collection has its own testsuite which is run
during the package build and examined by the gcc developers before
being uploaded.

The GNU Binary Utilities has its own testsuite which is run during the
package build and examined by the binutils developers before being
uploaded.

The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.

== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc.

== Dependencies ==
All packages do not need to be rebuilt due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 35 cycle. In particular the glibc merge of libpthread into libc
will remove the dependency in ELF binaries on libpthread, and that
cleanup is valuable for consistency.

== Contingency Plan ==
*

F35 Change: IBus 1.5.25 (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/IBus_1.5.25

== Summary ==
IBus 1.5.25 will use `transfiletriggerin` script to generate the cache
file instead of `posttrans` script in each engine package, support the
include directive in the user compose file, IBus compose feature will
follow the GTK4 compose pre-edit style, the emoji shortcut key will be
changed to `Ctrl-period`, IBus GTK4 module will proceed the key events
synchronistically to follow GTK4 specification.

== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com


== Detailed Description ==
* Each IBus language engine has run `posttrans` script to run `ibus
write-cache` to cache their component files in
/usr/share/ibus/component whenever the package is installed but `ibus
write-cache` will moved to `transfiletriggerin` script in IBus core
package and the script will be executed only one time per the Fedora
installation.
* IBus compose file will support the include directive in the user
compose file ($XDG_CONFIG_HOME/ibus/Compose,
$XDG_CONFIG_HOME/gtk-3.0/Compose or $HOME/.XCompose)
* IBus compose feature will follow the
[https://blog.gtk.org/2021/03/24/input-revisited/ GTK4 compose
pre-edit style].
* IBus emoji shortcut key is `Ctrl-Shift-e` and it will be changed to
`Ctrl-period` to follow the latest GTK while it's customizable with
`ibus-setup` utility.
* IBus GTK3 module proceeds the key events asynchronistically because
some langauge engines spend much time to compose key events and D-Bus
process could causes a timeout but now GTK4 does not allow the async
events and IBus GTK4 module will proceed the key events
synchronistically.

== Feedback ==
* Only one `transfiletriggerin` script is much simpler than many
`posttrans` scripts.


== Benefit to Fedora ==
Users can use the include directive in their compose files. IBus GTK4
module can send the application specific keys of Backspace, Enter to
the target application to follow GTK4 specification,

== Scope ==
* Proposal owners: Update SPEC file to add `transfiletriggerin`
script. Update libibus.so to enhance compose feature. Update
org.freedesktop.ibus.gschema.xml for emoji shortcut key. Update
libim-ibus.so to fix IBus sync process.

* Other developers: Update SPEC files to delete `posttrans` script.
* Release engineering: [https://pagure.io/releng/issue/10184 #10184]
* Policies and guidelines: N/A
* Trademark approval: N/A
* Alignment with Objectives:

== Upgrade/compatibility impact ==
We should avoid regressions with `transfiletriggerin` script in the
Fedora installation.


== How To Test ==
# Install ibus and the language engine packages
# `ibus read-cache --system` shows the installed engines.
# `rpm -q --scripts` does not show `ibus write-cache` in engine packages
# `rpm -q --filetriggers` shows `ibus write-cache` in ibus package

# Write the line of 'include "%H/foo.compose"' in your $HOME/.XCompose
and some compose sequences in $HOME/foo.compose
# Run `gnome-control-center keyboard` and configure some IBus language
engines besides XKB engines, likes ibus-hangul, ibus-typing-booster
# Enable an XKB engine with Super-space or clicking of the keyboard
idicator in GNOME
# Launch gedit
# Confirm your compose sequences in $HOME/foo.compose is reflected
# Confirm compose preedit is short

# Run `gnome-control-center keyboard` and configure some IBus language
engines besides XKB engines, likes ibus-hangul, ibus-typing-booster
# Enable an XKB engine with Super-space or clicking of the keyboard
idicator in GNOME
# Launch gedit
# Type Ctrl-period
# Confirm emoji pre-edit and lookup table is available

# Install gtk4-devel
# Run `env GTK_IM_MODULE=ibus gtk4-demo`
# Backspace, Enter keys works


== User Experience ==
The emoji shortcut key is changed if users do not customize it but
they can customize it with ibus-setup utility.


== Dependencies ==
ibus-anthy, ibus-chewing, ibus-hangul, ibus-input-pad, ibus-kkc,
ibus-libpinyin, ibus-rawcode, ibus-sayura, ibus-skk, ibus-table,
ibus-typing-booster, mozc  (`posttrans` script has already been
deleted in each engine package in Fedora rawhide.)

== Contingency Plan ==
* Contingency mechanism: Revert the change to IBus.
* Contingency deadline: Beta release
* Blocks release? No


== Documentation ==
TBD



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)

https://fedoraproject.org/wiki/Changes/GNUToolchainF35

== Summary ==
Switch the Fedora 35 GNU Toolchain to gcc 11 (lastest point release),
binutils 2.37, and glibc 2.34.

The gcc 11 is already included in Fedora 34, but the release will be
updated to the latest point release. The glibc 2.34 change will be
tracked in this top-level GNU Toolchain system-wide update. Likewise
the binutils 2.37 release will be tracked in this top-level GNU
Toolchain system-wide update.
The gdb 10.2 is already in Fedora 34, but the release will be updated
to the latest point release.

== Owner ==
* Name: [[User:codonell|Carlos O'Donell]]
* Email: car...@redhat.com


== Detailed Description ==


The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities
make up the core part of the GNU Toolchain and it is useful to
transition these components as a complete implementation when making a
new release of Fedora.

The GNU Compiler Collection has already released version 11 containing
many new features documented here:
https://gcc.gnu.org/gcc-11/changes.html. The latest point release for
gcc 11 will be included in Fedora 35, this will be either 11.1
(already released in April) or 11.2 (released later).

The GNU C Library version 2.34 will be released at the beginning of
August 2021; we have started closely tracking the glibc 2.34
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 35 will branch after the
glibc 2.34 upstream release. However, the mass rebuild schedule means
Fedora 35 will mass rebuild (if required) after glibc 2.34 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.

The GNU Binutils version 2.37 will be released near the end of July 2021;

The GNU Debugger verion 10.2 is already released.

== Benefit to Fedora ==
Stays up to date with latest features, improvements security and bug
fixes from gcc, binutils and glibc upstream.

The goal is to track and transition to the latest components of the
GNU Toolchain.

== Scope ==
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, ...)
The gcc and glibc teams will need to move their respective upstream
projects to a releasable state.  For GCC this includes correctly
building Fedora rawhide.

* Other developers: Developers need to ensure that gcc, binutils, and
glibc in rawhide are stable and ready for the Fedora 35 branch. Given
that glibc is backwards compatible and we have been testing the new
glibc in rawhide it should make very little impact when updated,
except for the occasional deprecation warnings and removal of legacy
interfaces from public header files.  An update to GCC 11.2 would be a
minimal change with bug fixes. The binutils 2.37 update has the
broadest scope for change and generated object files should be
reviewed and failures to build analyzed.



A mass rebuild is strongly encouraged. The glibc 2.34 release merges
libpthread.so into libc.so and it would be important to remove
DT_NEEDED on libpthread.so from all distribution binaries.

* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
The compiler, the static linker and the the library are backwards
compatible with the previous version of Fedora.

Some packaging changes may be required for the glibc 2.34 rebase:
https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes

Some source changes may be required for gcc 11 rebase:
https://gcc.gnu.org/gcc-11/changes.html
All changes for gcc 11 will have been included in Fedora 34 alraedy.

There should be no need for any changes to accommodate the new GNU
Binutils release.

We fully expect to fix all packaging changes in Fedora Rawhide without
impact to the release.

== How To Test ==
The GNU C compiler collection has its own testsuite which is run
during the package build and examined by the gcc developers before
being uploaded.

The GNU Binary Utilities has its own testsuite which is run during the
package build and examined by the binutils developers before being
uploaded.

The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.

== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc.

== Dependencies ==
All packages do not need to be rebuilt due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 35 cycle. In particular the glibc merge of libpthread into libc
will remove the dependency in ELF binaries on libpthread, and that
cleanup is valuable for consistency.

== Contingency Plan ==
*

Re: [Test-Announce] 2021-06-28 @ 15:00 UTC - Fedora QA Meeting

2021-06-29 Thread Adam Williamson

On Mon, 2021-06-28 at 16:11 +0200, Luna Jernberg wrote:
> Hello!
> 
> is this meeting on Libera or Freenode, the email says Freenode but i think
> thats a copy paste error right?

Sorry I didn't spot the error or the replies in time; of course the
meeting was on libera.chat. I again forgot to update the announcement.
Sorry! (It's not a template exactly, I just copy and paste it from my
sent mail folder every week, so I have to remember to change it when
I'm about to send it, which I obviously didn't...)

I'll try and get it right next time.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Intent to retire python2-setuptools


On 24. 06. 21 18:37, Miro Hrončok wrote:

On 23. 06. 21 19:52, Miro Hrončok wrote:

To compensate a rather ugly scriptlet is needed. The changes were proposed:

https://src.fedoraproject.org/rpms/python-psutil/pull-request/10
https://src.fedoraproject.org/rpms/python2-cairo/pull-request/1


The pull requests were adapted to include a less ugly workaround. The egg-info 
directory is artificially re-created during build.


The pull requests were merged and python2-setuptools was retired.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Intent to retire python2-setuptools


On 24. 06. 21 18:37, Miro Hrončok wrote:

On 23. 06. 21 19:52, Miro Hrončok wrote:

To compensate a rather ugly scriptlet is needed. The changes were proposed:

https://src.fedoraproject.org/rpms/python-psutil/pull-request/10
https://src.fedoraproject.org/rpms/python2-cairo/pull-request/1


The pull requests were adapted to include a less ugly workaround. The egg-info 
directory is artificially re-created during build.


The pull requests were merged and python2-setuptools was retired.

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support

2021-06-29 Thread Kevin Fenzi

On Tue, Jun 29, 2021 at 08:36:36AM -0400, Stephen Gallagher wrote:
> On Mon, Jun 28, 2021 at 3:00 PM Kevin Fenzi  wrote:
> >
> > On Mon, Jun 28, 2021 at 11:55:21AM -0400, Stephen Gallagher wrote:
> > > Summary: I think we can fix the ELN side-tag rebuild problems and make
> > > the composes more reliable if we change the mechanism for kicking off
> > > rebuilds. I'm soliciting feedback to help identify potential issues
> > > with this proposed approach.
> >
> > I wonder if it would be better/possible to take builds in the order in
> > which they were built in the side tag with wait-repos between?
> >
> > ie, chain build the builds from the side tag based on when they were
> > tagged into it? Unless maintainers make some mistake they would do
> > things in the order they need to build, no?
> >
> > I guess the downside is that this would be linear, and that could take a
> > long time on a large sidetag, but it should work without having to tag
> > in the f34 build?
> 
> This was the original idea I was pursuing, but it has some significant
> drawbacks, not least of which is that it would take a very long time
> (and therefore be vulnerable to race-condition issues where other
> packages are built in ELN in the meantime).
> 
> Tagging in the F34 builds is actually desirable here, rather than a
> drawback; it means that even if the ELN build fails, the compose will
> maintain installability and dependency validity until the issue is
> corrected. This in turn means that Content Resolver will be able to
> continue functioning. Speaking of Content Resolver, this will also
> solve the issue we have today where adding a new dependency on a
> package can cause Content Resolver to fail due to the dependent
> package not yet being in the ELN compose. With this approach, we will
> still have the Rawhide version available.

Would these rawhide builds go out in ELN composes?
Or would you block composes until you had only eln rpms in it?

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 6/199 (x86_64), 2/138 (aarch64)

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

ID: 918876  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/918876
ID: 91  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/91
ID: 918893  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/918893
ID: 918919  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/918919
ID: 918995  Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/918995
ID: 919071  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/919071

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

ID: 918943  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/918943
ID: 919175  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/919175

Soft failed openQA tests: 3/199 (x86_64), 3/138 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 918969  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/918969
ID: 918971  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/918971
ID: 919028  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/919028
ID: 919058  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/919058
ID: 919097  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/919097
ID: 919135  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/919135

Passed openQA tests: 190/199 (x86_64), 133/138 (aarch64)

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

ID: 918873  Test: x86_64 Server-dvd-iso install_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/918873
ID: 918879  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/918879
ID: 918882  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/918882
ID: 918890  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/918890
ID: 918891  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/918891
ID: 918933  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/918933
ID: 919006  Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/919006
ID: 919010  Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi
URL: https://openqa.fedoraproject.org/tests/919010
ID: 919013  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/919013
ID: 919019  Test: aarch64 Server-dvd-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/919019
ID: 919024  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/919024
ID: 919026  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/919026
ID: 919037  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/919037
ID: 919038  Test: aarch64 Workstation-raw_xz-raw.xz base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/919038
ID: 919039  Test: aarch64 Workstation-raw_xz-raw.xz base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/919039
ID: 919040  Test: aarch64 Workstation-raw_xz-raw.xz base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/919040
ID: 919041  Test: aarch64 Workstation-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/919041
ID: 919042  Test: aarch64 Workstation-raw_xz-raw.xz 
release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/919042
ID: 919043  Test: aarch64 Workstation-raw_xz-raw.xz unwanted_packages@uefi
URL: https://openqa.fedoraproject.org/tests/919043
ID: 919044  Test: aarch64 Workstation-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/919044
ID: 919045  Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi
URL:

Fedora-IoT-35-20210629.0 compose check report

No missing expected images.

Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64)

Old failures (same test failed in Fedora-IoT-35-20210628.0):

ID: 919197  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/919197
ID: 919201  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/919201
ID: 919202  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/919202
ID: 919211  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/919211
ID: 919216  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/919216

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

Old soft failures (same test soft failed in Fedora-IoT-35-20210628.0):

ID: 919186  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/919186
ID: 919187  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/919187
ID: 919188  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/919188
ID: 919203  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/919203

Passed openQA tests: 11/15 (aarch64), 11/16 (x86_64)

New passes (same test not passed in Fedora-IoT-35-20210628.0):

ID: 919204  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/919204
ID: 919205  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/919205
ID: 919208  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/919208
ID: 919209  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/919209
ID: 919214  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/919214

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 187 MiB to 166 MiB
System load changed from 0.28 to 0.16
Previous test data: https://openqa.fedoraproject.org/tests/918549#downloads
Current test data: https://openqa.fedoraproject.org/tests/919187#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 188 MiB to 167 MiB
Previous test data: https://openqa.fedoraproject.org/tests/918548#downloads
Current test data: https://openqa.fedoraproject.org/tests/919188#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
Used mem changed from 204 MiB to 181 MiB
System load changed from 1.07 to 0.49
Previous test data: https://openqa.fedoraproject.org/tests/918564#downloads
Current test data: https://openqa.fedoraproject.org/tests/919203#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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2021-06-29 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2021-06-30 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.net

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




Source: https://calendar.fedoraproject.org//meeting/9854/

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20210629.n.0 changes

2021-06-29 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20210628.n.0
NEW: Fedora-Rawhide-20210629.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  36
Dropped packages:2
Upgraded packages:   95
Downgraded packages: 0

Size of added packages:  37.12 MiB
Size of dropped packages:147.23 KiB
Size of upgraded packages:   6.28 GiB
Size of downgraded packages: 0 B

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

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

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: buttermanager-2.4.1-1.fc35
Summary: Tool for managing Btrfs snapshots, balancing filesystems and more
RPMs:buttermanager
Size:916.52 KiB

Package: ghc-GLURaw-2.0.0.4-1.fc35
Summary: A raw binding for the OpenGL graphics system
RPMs:ghc-GLURaw ghc-GLURaw-devel ghc-GLURaw-doc ghc-GLURaw-prof
Size:1.36 MiB

Package: git-autofixup-0.003001-1.fc35
Summary: Autofixup - create fixup commits for topic branches
RPMs:git-autofixup
Size:25.62 KiB

Package: gnome-shell-frippery-40.2-2.fc35
Summary: Extensions to provide a user experience more like that of GNOME 2
RPMs:gnome-shell-extension-frippery-applications-menu 
gnome-shell-extension-frippery-bottom-panel 
gnome-shell-extension-frippery-move-clock 
gnome-shell-extension-frippery-panel-favorites
Size:226.59 KiB

Package: golang-github-facebookincubator-ptp-0-0.1.20210628git895384e.fc35
Summary: Facebook's PTP libraries
RPMs:golang-github-facebookincubator-ptp-devel pshark ptp4u ptpcheck
Size:22.54 MiB

Package: golang-github-rjeczalik-notify-0.9.2-2.20210628gite2a77dc.fc35
Summary: File system event notification library on steroids
RPMs:golang-github-rjeczalik-notify-devel
Size:63.55 KiB

Package: golang-github-x-cray-logrus-prefixed-formatter-0.5.2-1.fc35
Summary: Logrus Prefixed Log Formatter
RPMs:golang-github-x-cray-logrus-prefixed-formatter-devel
Size:15.21 KiB

Package: golang-sr-spc-log-0.1.0-1.fc35
Summary: None
RPMs:golang-sr-spc-log-devel
Size:12.22 KiB

Package: python-boutdata-0.1.3-0.1.fc35
Summary: Python package for collecting BOUT++ data
RPMs:python3-boutdata
Size:88.96 KiB

Package: python-boututils-0.1.7-1.fc35
Summary: Python package containing BOUT++ utils
RPMs:python3-boututils python3-boututils+mayavi
Size:127.49 KiB

Package: python-build-0.5.1-1.fc35
Summary: A simple, correct PEP517 package builder
RPMs:python3-build
Size:33.33 KiB

Package: python-jupyter-packaging-0.10.3-1.fc35
Summary: Tools to help build and install Jupyter Python packages
RPMs:python3-jupyter-packaging
Size:32.66 KiB

Package: rust-ambient-authority-0.0.0-1.fc35
Summary: Ambient Authority
RPMs:rust-ambient-authority+default-devel rust-ambient-authority-devel
Size:30.20 KiB

Package: rust-ar-0.8.0-1.fc35
Summary: Library for encoding/decoding Unix archive files
RPMs:rust-ar+default-devel rust-ar-devel
Size:29.14 KiB

Package: rust-beef-0.5.0-1.fc35
Summary: More compact Cow
RPMs:rust-beef+const_fn-devel rust-beef+default-devel 
rust-beef+impl_serde-devel rust-beef+serde-devel rust-beef-devel
Size:49.98 KiB

Package: rust-below-0.2.0-1.fc35
Summary: Interactive tool to view and record historical system data
RPMs:below
Size:10.64 MiB

Package: rust-below-common-0.2.0-1.fc35
Summary: Common below code
RPMs:rust-below-common+default-devel rust-below-common-devel
Size:30.34 KiB

Package: rust-below-dump-0.2.0-1.fc35
Summary: Dump crate for below
RPMs:rust-below-dump+default-devel rust-below-dump-devel
Size:33.57 KiB

Package: rust-below-model-0.2.0-1.fc35
Summary: Model crate for below
RPMs:rust-below-model+default-devel rust-below-model-devel
Size:36.85 KiB

Package: rust-below-render-0.2.0-1.fc35
Summary: Render crate for below
RPMs:rust-below-render+default-devel rust-below-render-devel
Size:24.64 KiB

Package: rust-below-store-0.2.0-1.fc35
Summary: Store crate for below
RPMs:rust-below-store+default-devel rust-below-store-devel
Size:36.85 KiB

Package: rust-below-view-0.2.0-1.fc35
Summary: View crate for below
RPMs:rust-below-view+default-devel rust-below-view-devel
Size:51.06 KiB

Package: rust-below_derive-0.2.0-1.fc35
Summary: Proc macros for below
RPMs:rust-below_derive+default-devel rust-below_derive-devel
Size:25.70 KiB

Package: rust-boxfnonce-0.1.1-1.fc35
Summary: Safe FnOnce boxing for rust stable
RPMs:rust-boxfnonce+default-devel rust-boxfnonce-devel
Size:20.21 KiB

Package: rust-cgroupfs-0.2.0-1.fc35
Summary: Crate for reading cgroupv2 data
RPMs:rust-cgroupfs+default-devel rust-cgroupfs-devel
Size:25.59 KiB

Package: rust-constant_time_eq-0.1.5-1.fc35
Summary: Compares two equal-sized byte strings in constant time
RPMs:rust-constant_time_eq+default-devel rust-constant_time_eq-devel
Size:20.14 KiB

Heads-up: python-pyrsistent 0.18.0 coming to Rawhide with a minor API change

2021-06-29 Thread Ben Beasley

In one week, or slightly later, I will update python-pyrsistent to 
0.18.0 in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1977038). 
This includes one minor API change; please see the release notes at 
https://raw.githubusercontent.com/tobgu/pyrsistent/1b8e85ed0164a8f9908bee0524f9a9850c21c0b1/CHANGES.txt 
for the full list of changes. The breaking change is as follows:


> Fix #209 Update freeze recurse into pyrsistent data structures and 
thaw to recurse into lists and dicts,

> Thanks @phil-arh for this!
> NB! This is a backwards incompatible change! To keep the old 
behaviour pass `strict=False` to freeze and thaw.


The following packages depend directly on this package (maintainers in 
parentheses):


• python-jsonschema (apevec, @openstack-sig)

• python-poetry-core (thrnciar, churchyard, @python-sig)

Maintainers of potentially-affected packages should have received this 
email directly.


I have performed test rebuilds of both directly-dependent packages in a 
COPR (https://copr.fedorainfracloud.org/coprs/music/pyrsistent-0.18/) 
without incident, so I hope no changes to dependent packages will be 
required.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Heads-up: python-pyrsistent 0.18.0 coming to Rawhide with a minor API change

2021-06-29 Thread Ben Beasley

In one week, or slightly later, I will update python-pyrsistent to 
0.18.0 in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1977038). 
This includes one minor API change; please see the release notes at 
https://raw.githubusercontent.com/tobgu/pyrsistent/1b8e85ed0164a8f9908bee0524f9a9850c21c0b1/CHANGES.txt 
for the full list of changes. The breaking change is as follows:


> Fix #209 Update freeze recurse into pyrsistent data structures and 
thaw to recurse into lists and dicts,

> Thanks @phil-arh for this!
> NB! This is a backwards incompatible change! To keep the old 
behaviour pass `strict=False` to freeze and thaw.


The following packages depend directly on this package (maintainers in 
parentheses):


• python-jsonschema (apevec, @openstack-sig)

• python-poetry-core (thrnciar, churchyard, @python-sig)

Maintainers of potentially-affected packages should have received this 
email directly.


I have performed test rebuilds of both directly-dependent packages in a 
COPR (https://copr.fedorainfracloud.org/coprs/music/pyrsistent-0.18/) 
without incident, so I hope no changes to dependent packages will be 
required.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Source-git SIG report #1 (June 2021)

2021-06-29 Thread Justin Forbes

On Fri, Jun 25, 2021 at 7:52 AM Neal Gompa  wrote:
>
> On Fri, Jun 25, 2021 at 3:43 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Jun 25, 2021 at 03:49:23AM +, Dan Čermák wrote:
> > >
> > >
> > > On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok"  
> > > wrote:
> > > >On 24. 06. 21 23:07, Miroslav Suchý wrote:
> > > >> Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a):
> > >  One thing to consider is that the upstream tarballs might be
> > > >cryptographically
> > >  signed and packages should verify the signature in %prep.
> > > >>> This is a very good point - in such a case, we should always pull
> > > >the
> > > >>> official upstream tarball instead of generating a new one downstream
> > > >>
> > > >> Does it matter? If you are able to generate byte2byte identical
> > > >tarball then
> > > >> you can choose any of them.
> > > >
> > > >AFAIK git does not grantee to produce byte2byte identical archives
> > > >across
> > > >different versions of git, zlib, gzip etc. So even if upstream signs
> > > >the git
> > > >generated archive, generating a byte2byte identical one might be
> > > >tricky.
> > >
> > > Especially with xz, which iirc has reproducibility issues in parallel 
> > > mode.
> >
> > I think we should try to push upstream to sign git tags, instead or in
> > addition to tarballs. For upstreams, this is actually much easier
> > (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing
> > a tarball on github which requires some interaction with the web service.
> >
>
> As an upstream, I would literally *never* GPG sign git tags. If you
> ask me to do that, I won't. It's far too annoying to deal with for me
> to be willing to suffer through that.
>
> I'm not going to ask people to do something I would be unwilling to do myself.

I am not sure what method you are using to sign things, but git GPG
integration is easy, and generally gets out of the way.

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora 35 Rawhide 20210629.n.0 nightly compose nominated for testing

2021-06-29 Thread rawhide

Announcing the creation of a new nightly release validation test event
for Fedora 35 Rawhide 20210629.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20210615.n.1: anaconda-35.17-1.fc35.src, 20210629.n.0: 
anaconda-35.18-1.fc35.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/35

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210629.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210629.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210629.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210629.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210629.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210629.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210629.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Source-git SIG report #1 (June 2021)

2021-06-29 Thread Tomas Tomecek

On Tue, Jun 29, 2021 at 12:48 AM Colin Walters  wrote:
>
>
>
> On Thu, Jun 24, 2021, at 5:16 AM, Tomas Tomecek wrote:
> > Greetings from the Fedora source-git SIG! We are planning to start
> > publishing reports of what we are working on so everyone can easily
> > pay attention and get involved if interested. If you have any ideas,
> > comments or requests, don’t be shy and let us know :)
>
> I really appreciate your efforts here.  I think most of us know
> that the current RPM workflow is very antiquated.
>
> However, two things:
>
> - The representation for how we maintain source code is a
>   very long-term commitment.  It's hard to maintain multiple
>   of them.  Related to that, the details of how this works
>   will quickly become "frozen" and hard to change, so
>   it's important to get it right from the start.  Related
>   to that:

Yes, we can see that happening right now: doing some fundamental
changes to the current development process takes months/years/Ø.

> - I think this proposal only benefits very few packages,
>   mainly kernel/grub where the upstream is large
>   and we carry nontrivial deltas.  For most others,
>   it will either be neutral or worse.  So...my counter
>   proposal is to iterate closer to a NixOS/OpenEmbedded style "uni-repo"
>   model, leaving these special cases to basically become
>   forked upstream repositories.  Instead of carrying 208+
>   patches to grub, we'd have a separate git repo that gets rebased.
>   Which...is how it already works at 
> https://github.com/rhboot/grub2/tree/fedora-35
>   it looks like.
>
> On the "uni-repo" counter proposal: there's a bunch of real-world examples 
> here of distributions using this successfully:
> https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow

This is a nice write-up and the idea is definitely appealing but I
can't personally imagine how would this scale in Fedora:

* Can you imagine maintaining Fedora's 30k+ packages in a single repo?
Without some git-fetch magic it would be unbearable to perform a
git-pull.

* Git history would be immensely bloated (though `git log $path` would
work well).

* On the other hand, I like that changes could be done "atomically" in
a single commit, even for multiple packages.

* How would CI function?

* Where and how would tests be stored?

* As Neal pointed out, ACL mechanics would need to be thought through.

* src.fp.o and koji would need to be updated, significantly.

* How would contributions be handled? It would be hard to detect
stalled PRs, maintainers would be swarmed with changes not related to
their packages.

Would be awesome to get a PoC of this uni-repo approach.

Tomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Source-git SIG report #1 (June 2021)

2021-06-29 Thread Tomas Tomecek

On Thu, Jun 24, 2021 at 8:09 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Jun 24, 2021 at 03:48:54PM +0200, Tomas Tomecek wrote:
> > On Thu, Jun 24, 2021 at 12:41 PM Miro Hrončok  wrote:
> > >
> > > On 24. 06. 21 11:16, Tomas Tomecek wrote:
> > > > ## Choosing git forge to host source-git repositories
> > > > We need to find a home for all the source-git repositories. This is
> > > > actually a really hard task because we have many options (github.com,
> > > > gitlab.com, pagure.io, src.fedoraproject.org, something custom or
> > > > on-premise) and different expectations: some projects already have
> > > > repos set up on different platforms while Pagure is the primary forge
> > > > now. Since the CPE team is investigating GitLab as a forge, it's even
> > > > harder for us to figure out the primary forge. We may end up
> > > > supporting both actually: pagure.io and gitlab.com. What are your
> > > > thoughts on this topic? Would you prefer pagure.io or gitlab.com
> > > > More info:
> > > > * https://pagure.io/fedora-source-git/sig/issue/1
> > > > * https://pagure.io/fedora-source-git/sig/issue/7
> > >
> > > I would expect that since the soruce git is just an intermediate thing,
> > > supporting "any forge" is nice to have, but hard. I'd start with some 
> > > common
> > > options (Pagure + 1 other) and see where you'll get.
> >
> > Yep, that's exactly what I'd like us to do. As soon as we have the
> > service which accepts processes events up and running, it shouldn't be
> > that hard to teach it new fedora-messaging messages or webhook
> > payloads.
> >
> > > > ## High-level workflow proposal up for review
> > > > Hunor proposed a high-level workflow linked below and I strongly
> > > > recommend reading it. We have also started discussing many details in
> > > > the process, such as getting archives: should we generate one from the
> > > > source-git repo or use the official release archive from upstream?
> > >
> > > One thing to consider is that the upstream tarballs might be 
> > > cryptographically
> > > signed and packages should verify the signature in %prep.
> >
> > This is a very good point - in such a case, we should always pull the
> > official upstream tarball instead of generating a new one downstream.
>
> Hmm, but how would that work? I thought that the whole point of
> source-git is to build from a commit that contains some upstream
> version + downstream patches + downstream distro config like the spec file,
> and that the build step of applying downstream patches just doesn't exist.
> If you reuse the upstream tarball, then by necessity those downstream
> patches need to be serialized and applied on top like in dist-git. So
> you lose the property that the checkout from version control is *the*
> source you build, but you also lose the property that the source you
> build is what was signed (since patches are applied).

What you just described I understand as an (upstream) maintenance
branch and is not what we call source-git.

Our definition of source-git is:
* upstream release tarball
* downstream code changes applied as patches during %prep
* additional configs for sake of building and testing

It's not that one workflow is better than the other: teams tend to
pick one and use it to maintain their project based on their
preference and ease of use.

I hope we'd be able to support both workflows but right now we focus
on the source-git part.


HTH,

Tomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support

2021-06-29 Thread Stephen Gallagher

On Tue, Jun 29, 2021 at 4:09 AM Dan Horák  wrote:
>
> On Mon, 28 Jun 2021 15:43:48 -0400
> Mohan Boddu  wrote:
>
> > On Mon, Jun 28, 2021 at 3:33 PM Dan Horák  wrote:
> > >
> > > On Mon, 28 Jun 2021 11:55:21 -0400
> > > Stephen Gallagher  wrote:
> > >
> > > > Summary: I think we can fix the ELN side-tag rebuild problems and make
> > > > the composes more reliable if we change the mechanism for kicking off
> > > > rebuilds. I'm soliciting feedback to help identify potential issues
> > > > with this proposed approach.
> > >
> > > have you considered re-using koji-shadow? It might already know
> > > everything you need ...

Yes, I enquired about koji-shadow and was told (rather vociferously)
to avoid using it if at all possible.

> >
> > But it requires another koji instance that needs maintenance.
>

We don't have the available resources (both physical and human) to support this.

> that's the default use case from the past (same tag, different koji
> instances), but probably with a little effort it could use different
> tags, but same koji instance, which is what ELN needs.
>

We don't have the resources to rewrite it either.

> But in any case, what will happen if a rebuild in ELN fails? For proper
> handling of side tags / soname bumps / bootstrapped packages someone
> must decide what is right action. Can I safely use an older build? Do I
> need to fix the failure first? Can I safely rebuild a newer build? This
> was the kind of baby-sitting we have to do to keep the shadowed arches
> up-to-date and as-close-possible. Oh, the memories :-)

Thank you for succinctly listing all the reasons why we consigned
koji-shadow to the Void.

Dealing with the results if an ELN build failed is one of the strong
points to the approach I proposed. If the ELN rebuild fails, we fall
back to leaving the Rawhide version tagged into ELN. This will keep us
from ending up with broken dependency chains as well as not having ELN
fall behind Rawhide in terms of functionality. Our current situation
is that sometimes a failed build (for example: a rebase) goes
unnoticed for some time, since not everyone is monitoring their
packages for ELN.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support

2021-06-29 Thread Stephen Gallagher

On Mon, Jun 28, 2021 at 3:14 PM Till Maas  wrote:
>
> Hi,
>
> On Mon, Jun 28, 2021 at 11:55:21AM -0400, Stephen Gallagher wrote:
> > Summary: I think we can fix the ELN side-tag rebuild problems and make
> > the composes more reliable if we change the mechanism for kicking off
> > rebuilds. I'm soliciting feedback to help identify potential issues
> > with this proposed approach.
>
> did you consider mirroring the rawhide side-tag for eln directly from
> the beginning, so that a build for the rawhide side-tag triggers a
> rebuild for the eln side-tag and then the eln side-tag can be merged at
> a similar time as the rawhide side-tag. This way the build order would
> be the same (except if there are wait-repo delays that are not visible
> for the eln automation) and the build load would be distributed.

Yes, and that was the prevailing implementation idea until we came up
with the proposal above. As I noted in the original message, one of
the major benefits is that we don't have to have special handling for
side-tags; they'll behave the same way as non-side-tag builds.

The real issue there is that the wait-repo delays are impossible to
know, so the only option is as Kevin Fenzi noted up-thread: we'd have
to do a wait-repo between all builds. For side-tags with many
packages, this could take days or more to complete.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support

2021-06-29 Thread Stephen Gallagher

On Mon, Jun 28, 2021 at 3:00 PM Kevin Fenzi  wrote:
>
> On Mon, Jun 28, 2021 at 11:55:21AM -0400, Stephen Gallagher wrote:
> > Summary: I think we can fix the ELN side-tag rebuild problems and make
> > the composes more reliable if we change the mechanism for kicking off
> > rebuilds. I'm soliciting feedback to help identify potential issues
> > with this proposed approach.
>
> I wonder if it would be better/possible to take builds in the order in
> which they were built in the side tag with wait-repos between?
>
> ie, chain build the builds from the side tag based on when they were
> tagged into it? Unless maintainers make some mistake they would do
> things in the order they need to build, no?
>
> I guess the downside is that this would be linear, and that could take a
> long time on a large sidetag, but it should work without having to tag
> in the f34 build?

This was the original idea I was pursuing, but it has some significant
drawbacks, not least of which is that it would take a very long time
(and therefore be vulnerable to race-condition issues where other
packages are built in ELN in the meantime).

Tagging in the F34 builds is actually desirable here, rather than a
drawback; it means that even if the ELN build fails, the compose will
maintain installability and dependency validity until the issue is
corrected. This in turn means that Content Resolver will be able to
continue functioning. Speaking of Content Resolver, this will also
solve the issue we have today where adding a new dependency on a
package can cause Content Resolver to fail due to the dependent
package not yet being in the ELN compose. With this approach, we will
still have the Rawhide version available.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Fedocal] Reminder meeting : Prioritized bugs and issues

On Tue, Jun 29, 2021 at 7:00 AM  wrote:
>
> You are kindly invited to the meeting:
>Prioritized bugs and issues on 2021-06-30 from 11:00:00 to 12:00:00 
> America/Indiana/Indianapolis
>At fedora-meetin...@libera.chat
>
There are no nominated bugs and the two open bugs are being actively
nudged by yours truly. I'll cancel this meeting and we'll meet again
on 14 July.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1977103] perl-Pod-Simple-3.43 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Pod-Simple-3.43-1.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-06-29 11:26:54




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1977273] New: perl-XML-TreeBuilder for EPEL8

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

Bug ID: 1977273
   Summary: perl-XML-TreeBuilder for EPEL8
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-XML-TreeBuilder
  Assignee: rland...@redhat.com
  Reporter: emman...@seyman.fr
QA Contact: extras...@fedoraproject.org
CC: jfe...@redhat.com, perl-devel@lists.fedoraproject.org,
rland...@redhat.com
  Target Milestone: ---
Classification: Fedora



Could you please build perl-XML-TreeBuilder for EL8 ?
It is in the dependency chain of mythtv over in the rpmfusion repos.

The code in master builds on the epel8 branch without issue. I will happily
maintain or co-maintain if needed.


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

[rpms/perl-HTTP-Message] PR #7: 6.33 bump


mspacek merged a pull-request against the project: `perl-HTTP-Message` that you 
are following.

Merged pull-request:

``
6.33 bump
``

https://src.fedoraproject.org/rpms/perl-HTTP-Message/pull-request/7
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-HTTP-Message] PR #7: 6.33 bump


mspacek opened a new pull-request against the project: `perl-HTTP-Message` that 
you are following:
``
6.33 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Message/pull-request/7
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New RPM submission

2021-06-29 Thread Sérgio Basto

On Sat, 2021-06-26 at 22:34 +0200, Emmanuel Seyman wrote:
> * Joan Moreau via devel [26/06/2021 19:36] :
> > 
> > What is next ?
> 


> The answer is the same one you were given two months ago.
> 
> You need to seek out a sponsor:
>  
> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
> 

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
https://fedoraproject.org/wiki/Package_maintenance_guide


> Emmanuel
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:  
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:  
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:  
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:  
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20210629.0 compose check report

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-34-20210628.0):

ID: 918812  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/918812
ID: 918820  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/918820

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: use unit names in systemd output by default?

2021-06-29 Thread Paweł Marciniak

> I submitted a pull request that mashes your patch, Colin Walter's
> earlier pull reuqest, and some stuff I had worked on before into
> https://github.com/systemd/systemd/pull/20047.

Ok. Thanks, but you meant https://github.com/systemd/systemd/pull/20058 :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1976544] perl-Finance-Quote-1.50 is available

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

Paul Howarth  changed:

   What|Removed |Added

   Assignee|nott...@splat.cc|p...@city-fan.org




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-HTTP-Message] PR #6: 6.33 bump


mspacek merged a pull-request against the project: `perl-HTTP-Message` that you 
are following.

Merged pull-request:

``
6.33 bump
``

https://src.fedoraproject.org/rpms/perl-HTTP-Message/pull-request/6
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1976544] perl-Finance-Quote-1.50 is available

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Depends On||1977229
   Doc Type|--- |If docs needed, set a value



--- Comment #2 from Paul Howarth  ---
Updated version needs new package perl-Date-Range (Bug #1977229).



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1977229
[Bug 1977229] Review Request: perl-Date-Range - Work with a range of dates
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Pod-Simple] PR #1: Tests

2021-06-29 Thread Jitka Plesnikova


jplesnik merged a pull-request against the project: `perl-Pod-Simple` that you 
are following.

Merged pull-request:

``
Tests
``

https://src.fedoraproject.org/rpms/perl-Pod-Simple/pull-request/1
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-HTTP-Message] PR #6: 6.33 bump


mspacek opened a new pull-request against the project: `perl-HTTP-Message` that 
you are following:
``
6.33 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Message/pull-request/6
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1977021] perl-HTTP-Message-6.33 is available

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



--- Comment #1 from Michal Josef Spacek  ---
Changes in new version: Allow `can` method to respond to delegated methods


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1977021] perl-HTTP-Message-6.33 is available

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New RPM submission

2021-06-29 Thread Vít Ondruch



Dne 26. 06. 21 v 19:16 Stephen John Smoogen napsal(a):

The process is complicated for multiple reasons:
1. There are a lot of steps to deal with corner cases which have come
up over the years which need to be dealt with.
2. There are some steps to make sure that the package is going to be
maintained versus just dropped and forgotten as a lot of packages have
been.
3. There are a lot of warts/headaches/problems which have been there
but people who have packaged for 20 years no longer see (or in a
Stockholm syndrome feel they NEED to be there.)

In packaging software there are a set of steps you need to ask yourself:

1. Why are you wanting to do this task?
2. What do you expect to get out of this?
3. How committed are you to continually packaging this software?
4. What does this software bring to a complete operating system?
5. Why this operating system?



Shouldn't we have these bullets in the "Join the package collection 
maintainers" wiki?



Vít



The first three questions are mostly about personal motivations but it
is something that I see people not answering and then burning
themselves out on finding out how complicated packaging is. Packaging
up software is a long term commitment. It is saying 'I think this
software is useful and will be maintained for years at a time.' If the
software is more of a short term project or you really don't think
that you (or others) want to keep fixing/maintaining it for years..
then the software doesn't really need to be in a distribution but in
some sort of PPA or COPR.

The fourth and fifth are to deal with marketing the software. Just
having it in a distribution isn't going to get it to be used. [In most
distribution early years, they don't take this part seriously and then
end up with hundreds or thousands of ghost packages which end up being
a pain. A distribution then starts adding more 'does anyone need this
really???' type roadblocks which may go into overkill. Or it may be
that putting it in the operating system is going to be a headache the
entire time because the way the operating system deals with the
language set is more work than you care for.

For Fedora/RHEL, programs written in newer languages like Java, Go,
Rust are going to have a lot of rules which seem completely
antithetical to how the language is set up elsewhere. Getting software
written in these is going to need a LOT of extra work which requires
even more dedication. [I am not saying that they shouldn't be done,
but it is more like the 'packaging game' is set to Instadeath/Torment
X mode.

On Sat, 26 Jun 2021 at 06:38, Joan Moreau via devel
 wrote:

Honeslt y , process is so complicated

Now, I am again getting errors about "unaotirzed url"

How to make things happens intesaod of all thisnightmare ?

Thank you



On Wed, 2021-06-23 at 19:58 +0200, Arthur Bols wrote:

On 23/06/2021 19:34, Joan Moreau via devel wrote:

Hello

How can I move forward on this ?

Thank you

Hi Joan,

Could you elaborate please?

As Emmanuel said, you have two options:

a) use a COPR repository and publish instructions on enabling the repo
b) find an existing maintainer to do the heavy lifting and sign on as
a co-maintainer to deal with upstream-related issues. The primary
maintainer will then only have to deal with Fedora-related issues.


Arthur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: use unit names in systemd output by default?

2021-06-29 Thread Zbigniew Jędrzejewski-Szmek

On Sat, Jun 26, 2021 at 04:39:16PM -, Paweł Marciniak wrote:
> I've written a code heavily based on the above-mentioned PR:15957 but I've 
> added some missing code (new option StatusUnitFormat=combined).
> 
> Now you can set  StatusUnitFormat=combined in the configuration file or  as a 
> kernel command line argument systemd.status_unit_format=combined
> The output format is unit_name (unit description)
> 
> Live system examples:
> 
> combined:
> Jun 26 18:24:19 fedora systemd[1]: Starting firewalld.service (firewalld - 
> dynamic firewall daemon)...
> Jun 26 18:24:20 fedora systemd[1]: Started firewalld.service (firewalld - 
> dynamic firewall daemon).
> 
> name:
> Jun 26 18:31:06 fedora systemd[1]: Starting firewalld.service...
> Jun 26 18:31:06 fedora systemd[1]: Started firewalld.service.
> 
> description:
> Jun 26 18:32:04 fedora systemd[1]: Starting firewalld - dynamic firewall 
> daemon...
> Jun 26 18:32:04 fedora systemd[1]: Started firewalld - dynamic firewall 
> daemon.
> 
> The code:
> https://github.com/sunwire/systemd/commit/07cd929872c1cd6809e2e17085d703ea2eeb6ea0
> https://github.com/sunwire/systemd/commit/07cd929872c1cd6809e2e17085d703ea2eeb6ea0.diff
> https://github.com/sunwire/systemd/commit/07cd929872c1cd6809e2e17085d703ea2eeb6ea0.patch

Thanks!

I submitted a pull request that mashes your patch, Colin Walter's
earlier pull reuqest, and some stuff I had worked on before into
https://github.com/systemd/systemd/pull/20047.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1853802] font selection is broken on perl-Tk-804.035-1.fc32.x86_64

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-639b8bfb6e has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-639b8bfb6e

--- Comment #5 from Fedora Update System  ---
FEDORA-2021-49127bd223 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-49127bd223


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1853802] font selection is broken on perl-Tk-804.035-1.fc32.x86_64

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-639b8bfb6e has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-639b8bfb6e


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #17 from Fedora Update System  ---
FEDORA-2021-49127bd223 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-49127bd223


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Rebuild ordering and side-tag support

2021-06-29 Thread Dan Horák

On Mon, 28 Jun 2021 15:43:48 -0400
Mohan Boddu  wrote:

> On Mon, Jun 28, 2021 at 3:33 PM Dan Horák  wrote:
> >
> > On Mon, 28 Jun 2021 11:55:21 -0400
> > Stephen Gallagher  wrote:
> >
> > > Summary: I think we can fix the ELN side-tag rebuild problems and make
> > > the composes more reliable if we change the mechanism for kicking off
> > > rebuilds. I'm soliciting feedback to help identify potential issues
> > > with this proposed approach.
> >
> > have you considered re-using koji-shadow? It might already know
> > everything you need ...
> 
> But it requires another koji instance that needs maintenance.

that's the default use case from the past (same tag, different koji
instances), but probably with a little effort it could use different
tags, but same koji instance, which is what ELN needs.

But in any case, what will happen if a rebuild in ELN fails? For proper
handling of side tags / soname bumps / bootstrapped packages someone
must decide what is right action. Can I safely use an older build? Do I
need to fix the failure first? Can I safely rebuild a newer build? This
was the kind of baby-sitting we have to do to keep the shadowed arches
up-to-date and as-close-possible. Oh, the memories :-)

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Pod-Simple] PR #1: Tests

2021-06-29 Thread Jitka Plesnikova


jplesnik opened a new pull-request against the project: `perl-Pod-Simple` that 
you are following:
``
Tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Pod-Simple/pull-request/1
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20210629.0 compose check report

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-33-20210628.0):

ID: 918796  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/918796
ID: 918804  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/918804

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Macro to smoke-test-import a Python module in %check

2021-06-29 Thread Felix Schwarz



Am 28.06.21 um 21:44 schrieb Miro Hrončok:

The semantics is quite simple:


     %check
     %py3_check_import mymodule mymodule.submodule


Looks great! Thank you.

Please let us know when we should start adding that to our Python packages. :-)

Felix
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Macro to smoke-test-import a Python module in %check

2021-06-29 Thread Felix Schwarz



Am 28.06.21 um 21:44 schrieb Miro Hrončok:

The semantics is quite simple:


     %check
     %py3_check_import mymodule mymodule.submodule


Looks great! Thank you.

Please let us know when we should start adding that to our Python packages. :-)

Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1977103] perl-Pod-Simple-3.43 is available