Re: koji buildsystem changes

[Panu Matilainen]

On 12/16/20 12:18 AM, Miroslav Suchý wrote:

Dne 15. 12. 20 v 11:39 Panu Matilainen napsal(a):

BTW, I'm not aware of the details how the images are built these days, but of 
course *something* will still need to
build those images,


That is normal podman image of Fedora.

Strictly speaking you will still need to have compatibility with latest 
released Fedora (I guess we do not have rawhide
podman images, right?). But once you have that image you can run the Mock on 
anything archaic. As long as the thing is
capable of running podman.



I'm actually talking about the other extreme, the "archaic" use-case 
isn't interesting to me personally.


To allow rpm and its dependencies to use features only in rawhide would 
require a rolling rawhide image to be used for the build of the next 
image, and as things can and will go wrong, it'd need to be possible to 
back down to a known good image.


Besides other issues and complexities, rpm utilizing this to maximum 
would mean that you can't distro-upgrade from an N-1 version anymore 
(you'd need to boot into an image of the new distro first), and I don't 
think Fedora's upgrade-tooling is ready for that. Would've worked with 
the anaconda upgrade method of the old, but what's gone is gone...


So with these caveats in mind, I think the current situation is about as 
good as it's going to get. Which is by no means a small thing, like said 
it's HUGE for me!


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

Re: What is the most time consuming task for you as packager?

[Vít Ondruch]

Dne 16. 12. 20 v 21:56 Neal Gompa napsal(a):

On Wed, Dec 16, 2020 at 3:34 PM Kevin Fenzi  wrote:

On Wed, Dec 16, 2020 at 07:15:21PM +, Jonathan Wakely wrote:

On 15/12/20 23:46 +0100, Miro Hrončok wrote:

On 12/15/20 11:29 PM, Miroslav Suchý wrote:

I am looking for challenges for upcoming year - what I and my team should 
enhance. I have some ideas, but I want to hear
yours.

Thanks for doing this!


What you - as Fedora packager - find most time consuming on packaging?

Coordination and communication ;)


Where you will welcome more simplicity or automation?

In testing an impact of a change. E.g. a simple "upgrade to newer
version" change might be a problem if it breaks other packages. I
usually spin up a copr repo and try to rebuild every dependent package

^ This.

The individual steps of doing a single package are insignificant
compared to the days or WEEKS it takes for a systemwide change that
requires rebuilding hundreds of dependencies. I know not many of us
actually have this problem, but for those who do, it's very, very time
consuming.

Since we're apparently not allowed to use a side tag to do a test
rebuild for this kind of thing, I end up doing it locally on my own
machines. Copr is another option, but I don't think it would be any
quicker or simpler.

You actually can use a side tag, but it's not very streamlined.
1. make side-tag
2. push your changes to a whatever branch on the package that you are
changing.
3. build package from that branch into the sidetag
4. scratch build all the dependent packages in the sidetag and they will
use the changed package. Get them all working.
5. merge your branch back on the package, bump release again
5. actually bump and officially rebuild all the packages in the side tag
6. merge sidetag
7. ask releng to delete the branch you made (or not if you don't care)

But I agree thats not great. ;(


What I'd really like would be a "test mass rebuild" process, where a
prospective package is uploaded and everything that depends on it is
automatically rebuilt (ideally after creating the dependency graph so
each individual package doesn't get rebuilt until its dependencies are
finished building).

Creating the dependency graph by hand is fairly tedious, but maybe I'm
missing an automated way. The point of creating that graph is to avoid
wasting time and power doing and redoing builds that will fail until
something else has been built (which is the problem with mock's
--chain command, if I understand correctly).

Once I have that graph, I use Make to control the process, because it
handles the dependency graph, as well as parallelism, and not
rebuilding things unnecessarily.

Yeah, all this ^


So I've written tools for doing this, and Igor has written tools for
doing this, but it seems like people think that this is "impossible"
and so the effort goes nowhere despite several PoCs.

If we're interested in this again for real this time, I could try to
dig out my old code for it, but we might be better off just pulling
out Koschei's code and turning it into something that Koji's
chain-build command and Mock's --chain option use to sort through
package sets and build them correctly.


in it. However, there are time consuming challenges with this:

1) False failures. Sometimes, the copr build fails for random reason
(Koji repo is not available, etc.). I need to read the logs and figure
it out, resubmit the build.

2) Unrelated failures. Many packages FTBFS for unrelated reasons. I need
to spin up another (control) copr and rebuild all failures there as well
to make sure it's indeed unrelated.

Yes, that's a real pain. Can we just add everything to Koschei instead
of having it opt-in?

Thats worth considering in the new year. I would like that. :)



I would appreciate if Koschei kept more results. It is almost unuseful 
these days if one does not have time to check the issue right after it 
appears :(



Vít



Yes please!




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


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


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

Re: koji buildsystem changes

[Pavel Raiskup]

On Wednesday, December 16, 2020 8:25:50 PM CET Kevin Fenzi wrote:
> On Tue, Dec 15, 2020 at 10:54:07AM +0100, Miroslav Suchý wrote:
> >   
> > https://github.com/rpm-software-management/mock/wiki/Feature-container-for-bootstrap
> > which is still fresh feature - just one year old :) And so far not enabled 
> > in Koji.
> > 
> > When *this* will be enabled in Koji, we can finally boost the RPM
> > development to levels previously unimaginable. :)
> 
> Yeah, we should discuss how to manage and land this. Ideally there would
> be a lot of CI/QA/Gating on the image, and we would have easy ways to
> roll back to a known good one in case. 

Sounds good!  Likely we'd need an image for each chroot and arch.  Where
can we start? :)

Anyone can be experiment with this in Copr now (see the
chroot/project/build "bootstrap" configuration options).  Any publicly
available podman image can be used to initialize the bootstrap.

> I wonder how much slower it is? 

With --use-bootstrap-image, the host's package manager isn't involved in
preparing the bootstrap at all.  E.g. for the fedora-33-x86_64 chroot

1. 'fedora:33' container image is downloaded (this can be cached on builder)
2. container is executed from the image to install 'dnf-plugins-core'
   (needed by mock, we could skip this step if we had a complete image).
3. the container content is exported to 
/var/lib/mock/-bootstrap/root
   and from now on it is normal "bootstrap" (pkg management tools from there
   are used to install normal chroot).

So we could make the bootstrap image feature overhead almost instant (equivalent
to extraction of several-tens-of-MB image/tarball extraction), if we maintained
the special image you talked about.

IOW, bootstrap image is even now slightly faster than normal bootstrap, but we
could make it almost as fast as mock without bootstrap.

Pavel


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

Fedora-Cloud-32-20201217.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

Passed openQA tests: 6/7 (x86_64), 6/7 (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

Re: koji buildsystem changes

[Pavel Raiskup]

On Sunday, December 13, 2020 11:02:53 PM CET Kevin Fenzi wrote:
> * Finally releng is looking at establishing a sidetag cleanup policy. 
> A reminder that sidetags should be short lived and only created when
> needed. koji must generate buildroot repos for every single sidetag.
> ( You can list all your sidetags with 'fedpkg list-side-tags --mine' )

I'm just curious what's the most expensive thing for Koji to implement
side-tags, I'd expect something like:

- the repositories are cloned (recursively hardlinked/symlinked?)
- the override package is added
- then createrepo_c is run

In Copr we don't have to clone the repositories, but we have to run the
createrepo_c after each build.  In the past the bottleneck used to be
the createrepo_c run (recursive walk through all the packages in larger
repositories).

If Koji suffers from the same problem, perhaps you could take a look at
the new createrepo_c option `--recycle-pkglist` - the createrepo_c costs
almost nothing then (matter of just reading and later writing the xml
metadata).

Pavel


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

Re: End of CentOS Linux: What about Fedora?

[Robin Opletal]

I think this wouldn't be that much of a problem - what I think is bad is
that CentOS Stream security updates aren't going to come before RHEL's
will, and they will essentially be backported, at least as I understood
it.

Correct me if I am wrong

On Wed Dec 9, 2020 at 5:52 PM CET, Adam Williamson wrote:
> It's a rolling release *of a stable RHEL branch*. You're not getting
> radical new changes if you run CentOS Stream; you're just getting the
> changes you'd usually get in RHEL stable point releases (e.g. 8.1, 8.2
> etc) but getting them early and as they are produced, rather than in
> periodic lumps).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

What to do about ELN-related "spam"?

[Fabio Valentini]

Hi everybody,

I'm unsure how to deal with this, so I'm asking here if anybody has ideas.

- I'm getting serious spam from fedora-notif on IRC about successful -
and a lot more failed - ELN builds for my packages (triggered either
by ELN developers or automatically by their CI)
- bodhi is spamming bugzilla by changing the "Fixed in Version" field
every time a new ELN build succeds with a new %dist value (one
bugzilla email each for eln106, eln107, eln108, etc.)

At this point, almost half of the bugzilla mail I get and a majority
of the IRC notifications are "ELN spam" that I do not know how to deal
with / is not actionable for me. It's now so bad that I'd like to get
the packages that are failing to build (multiple times a day) in ELN
fixed just so I don't get spammed with "failed to build" notifications
anymore ...

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

Re: What is the most time consuming task for you as packager?

[Miroslav Suchý]

Dne 17. 12. 20 v 8:02 Luya Tshimbalanga napsal(a):
> Frontend for spec file

??? Can you elaborate it?

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What is the most time consuming task for you as packager?

[Fabio Valentini]

On Thu, Dec 17, 2020 at 1:02 AM Chuck Anderson  wrote:
>
> On Tue, Dec 15, 2020 at 11:29:27PM +0100, Miroslav Suchý wrote:
> > I am looking for challenges for upcoming year - what I and my team should 
> > enhance. I have some ideas, but I want to hear
> > yours.
> >
> > What you - as Fedora packager - find most time consuming on packaging?
> > Where you will welcome more simplicity or automation?
>
> Looking up the latest guidelines and recommendations for packaging.
> It seems to be spread between the Wiki and "docs" site and it isn't
> always clear which one is correct.  Google searches may still find old
> or "draft" guidelines.  Not all are ported over to docs.fp.org, so you
> have to use the Wiki site for some content.  Wiki documents link to
> themselves, even when in some cases the Wiki version is out of date,
> replaced by docs.fp.org version.  There isn't always a warning or
> reminder that links to the correct version on docs.fp.org.  Or there
> is a redirect to the new site, but it doesn't link to the right
> content.
>
> https://fedoraproject.org/wiki/Packaging:Guidelines
>
> "The packaging guidelines have been moved out of the wiki. The current
> version of this document is located at
> https://docs.fedoraproject.org/en-US/packaging-guidelines/ . Please
> update your bookmarks."
>
> But say I search Google for "fedora perl packaging guidelines" I find this:
>
> https://fedoraproject.org/wiki/Packaging:Perl
>
> Then there is a link on there to:
>
> https://fedoraproject.org/wiki/Category:Packaging_guidelines
>
> Or search Google for "fedora packaging systemctl" finds this:
>
> https://fedoraproject.org/wiki/Packaging:Systemd
>
> which has:
>
> Unit files in spec file scriptlets
>
> Information on proper handling of unit files in spec file scriptlets can be 
> found here: Packaging:Scriptlets#Systemd
>
> but that links to:
>
> https://fedoraproject.org/wiki/Packaging:Scriptlets#Systemd
>
> which redirects to:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#Systemd
>
> which doesn't have a #Systemd anchor.  So you are dumped at the top of
> that page rather than at the section about Systemd which has an anchor
> of #_systemd instead.
>
> It would be nice if this could all be cleaned up, because right now it
> makes navigating the documentation a nightmare.

We (the Packaging Committee) know about this problem, and we've been
slowly working to get the migrated pages "verified" and to add
redirects from the old Wiki pages to the corresponding new docs.
However, this is a very time-consuming process (checking that all the
content has been migrated correctly, checking links, checking
formatting, etc), and it has somewhat stalled recently, because, ya
know, 2020.

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

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

Re: What is the most time consuming task for you as packager?

[Fabio Valentini]

On Thu, Dec 17, 2020 at 10:14 AM Vít Ondruch  wrote:
>
>
> Dne 16. 12. 20 v 21:56 Neal Gompa napsal(a):
> > On Wed, Dec 16, 2020 at 3:34 PM Kevin Fenzi  wrote:
> >> On Wed, Dec 16, 2020 at 07:15:21PM +, Jonathan Wakely wrote:
> >>> On 15/12/20 23:46 +0100, Miro Hrončok wrote:
>  On 12/15/20 11:29 PM, Miroslav Suchý wrote:
> > I am looking for challenges for upcoming year - what I and my team 
> > should enhance. I have some ideas, but I want to hear
> > yours.
>  Thanks for doing this!
> 
> > What you - as Fedora packager - find most time consuming on packaging?
>  Coordination and communication ;)
> 
> > Where you will welcome more simplicity or automation?
>  In testing an impact of a change. E.g. a simple "upgrade to newer
>  version" change might be a problem if it breaks other packages. I
>  usually spin up a copr repo and try to rebuild every dependent package
> >>> ^ This.
> >>>
> >>> The individual steps of doing a single package are insignificant
> >>> compared to the days or WEEKS it takes for a systemwide change that
> >>> requires rebuilding hundreds of dependencies. I know not many of us
> >>> actually have this problem, but for those who do, it's very, very time
> >>> consuming.
> >>>
> >>> Since we're apparently not allowed to use a side tag to do a test
> >>> rebuild for this kind of thing, I end up doing it locally on my own
> >>> machines. Copr is another option, but I don't think it would be any
> >>> quicker or simpler.
> >> You actually can use a side tag, but it's not very streamlined.
> >> 1. make side-tag
> >> 2. push your changes to a whatever branch on the package that you are
> >> changing.
> >> 3. build package from that branch into the sidetag
> >> 4. scratch build all the dependent packages in the sidetag and they will
> >> use the changed package. Get them all working.
> >> 5. merge your branch back on the package, bump release again
> >> 5. actually bump and officially rebuild all the packages in the side tag
> >> 6. merge sidetag
> >> 7. ask releng to delete the branch you made (or not if you don't care)
> >>
> >> But I agree thats not great. ;(
> >>
> >>> What I'd really like would be a "test mass rebuild" process, where a
> >>> prospective package is uploaded and everything that depends on it is
> >>> automatically rebuilt (ideally after creating the dependency graph so
> >>> each individual package doesn't get rebuilt until its dependencies are
> >>> finished building).
> >>>
> >>> Creating the dependency graph by hand is fairly tedious, but maybe I'm
> >>> missing an automated way. The point of creating that graph is to avoid
> >>> wasting time and power doing and redoing builds that will fail until
> >>> something else has been built (which is the problem with mock's
> >>> --chain command, if I understand correctly).
> >>>
> >>> Once I have that graph, I use Make to control the process, because it
> >>> handles the dependency graph, as well as parallelism, and not
> >>> rebuilding things unnecessarily.
> >> Yeah, all this ^
> >>
> > So I've written tools for doing this, and Igor has written tools for
> > doing this, but it seems like people think that this is "impossible"
> > and so the effort goes nowhere despite several PoCs.
> >
> > If we're interested in this again for real this time, I could try to
> > dig out my old code for it, but we might be better off just pulling
> > out Koschei's code and turning it into something that Koji's
> > chain-build command and Mock's --chain option use to sort through
> > package sets and build them correctly.
> >
>  in it. However, there are time consuming challenges with this:
> 
>  1) False failures. Sometimes, the copr build fails for random reason
>  (Koji repo is not available, etc.). I need to read the logs and figure
>  it out, resubmit the build.
> 
>  2) Unrelated failures. Many packages FTBFS for unrelated reasons. I need
>  to spin up another (control) copr and rebuild all failures there as well
>  to make sure it's indeed unrelated.
> >>> Yes, that's a real pain. Can we just add everything to Koschei instead
> >>> of having it opt-in?
> >> Thats worth considering in the new year. I would like that. :)
> >>
>
> I would appreciate if Koschei kept more results. It is almost unuseful
> these days if one does not have time to check the issue right after it
> appears :(

I think this is caused by koji garbage collection?
I assume the retention time it's set very short for scratch builds,
which makes koschei less useful, but keeps storage use in check ...

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

Re: Summary/Minutes for today's FESCo meeting (2020-12-16)

[Miroslav Suchý]

Dne 16. 12. 20 v 16:47 Fabio Valentini napsal(a):
> * #2519 F34 Change: GitRepos-master-to-main  (decathorpe, 15:09:57)
>   * AGREED: APPROVED (+6, 0, -0)  (decathorpe, 15:27:51)


/me saving you time to read the log for **what** was actually approved:

15:19:05  Proposal: Approve proposal to rename branch names from 
"master" to "main" except in dist-git-like
repositories with branches matching fedora releases, where "rawhide" is 
preferred.
15:19:43  Where the new default branch will be "rawhide", create 
symbolic refs from "main" to "rawhide".


-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about ELN-related "spam"?

[Petr Šabata]

On Thu, Dec 17, 2020 at 12:27 PM Fabio Valentini  wrote:
>
> Hi everybody,
>
> I'm unsure how to deal with this, so I'm asking here if anybody has ideas.
>
> - I'm getting serious spam from fedora-notif on IRC about successful -
> and a lot more failed - ELN builds for my packages (triggered either
> by ELN developers or automatically by their CI)

I hope successful builds aren't too much of a pain; failed builds
should preferably be addressed, ideally by you. Unless it's clearly
not a problem in your package.

> - bodhi is spamming bugzilla by changing the "Fixed in Version" field
> every time a new ELN build succeds with a new %dist value (one
> bugzilla email each for eln106, eln107, eln108, etc.)

This sounds wrong to me but maybe it's relevant for potential ELN
consumers to know if a bug was also addressed in ELN. Is that an
issue?

> At this point, almost half of the bugzilla mail I get and a majority
> of the IRC notifications are "ELN spam" that I do not know how to deal
> with / is not actionable for me. It's now so bad that I'd like to get
> the packages that are failing to build (multiple times a day) in ELN
> fixed just so I don't get spammed with "failed to build" notifications
> anymore ...

I wonder why you're getting so many build notifications. These should
only be triggered when you update your package in Rawhide. But again,
fixing build failures would generally be a good thing.

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

Re: koji buildsystem changes

[Miroslav Suchý]

Dne 17. 12. 20 v 10:17 Pavel Raiskup napsal(a):
>> I wonder how much slower it is? 
> IOW, bootstrap image is even now slightly faster than normal bootstrap, but we
> could make it almost as fast as mock without bootstrap.

1) the difference is mostly in first run (till the cache is populated).

2) Definitely faster. Want hard data?

$ mock --scrub=all
$ time mock --config-opts=use_bootstrap_image=False --shell 'echo ahoy'
...
real3m9,534s
user2m34,950s
sys 0m10,617s

$ mock --scrub=all
$ time mock --config-opts=use_bootstrap_image=True --shell 'echo ahoy'
...
real2m28,183s
user1m34,371s
sys 0m9,316s

In data-center this can be different, but I am sitting on fat 100Mbit line. So 
not much different

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do about ELN-related "spam"?

[Tom Hughes via devel]

On 17/12/2020 11:23, Fabio Valentini wrote:


- I'm getting serious spam from fedora-notif on IRC about successful -
and a lot more failed - ELN builds for my packages (triggered either
by ELN developers or automatically by their CI)


I use email notification rather than IRC so I just have an
exim filter rule that drops anything matching:

  $h_x-fedmsg-category is "buildsys" and $h_subject contains ".eln"

Along with a similar rule for modularity builds.

You should be able to do something similar upstream in the
notifications app I guess - the downside of customising things
there is that you stop getting any changes to the default rules.


- bodhi is spamming bugzilla by changing the "Fixed in Version" field
every time a new ELN build succeds with a new %dist value (one
bugzilla email each for eln106, eln107, eln108, etc.)


I haven't noticed this one happening.

Tom

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

Re: What to do about ELN-related "spam"?

[Dan Čermák]

Petr Šabata  writes:

> On Thu, Dec 17, 2020 at 12:27 PM Fabio Valentini  wrote:
>>
>> Hi everybody,
>>
>> I'm unsure how to deal with this, so I'm asking here if anybody has ideas.
>>
>> - I'm getting serious spam from fedora-notif on IRC about successful -
>> and a lot more failed - ELN builds for my packages (triggered either
>> by ELN developers or automatically by their CI)
>
> I hope successful builds aren't too much of a pain; failed builds
> should preferably be addressed, ideally by you. Unless it's clearly
> not a problem in your package.

Wasn't there an agreement that I, as an average packager, don't have to
care about ELN at all?


Cheers,

Dan


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

Re: What to do about ELN-related "spam"?

[Fabio Valentini]

On Thu, Dec 17, 2020 at 12:37 PM Petr Šabata  wrote:
>
> On Thu, Dec 17, 2020 at 12:27 PM Fabio Valentini  wrote:
> >
> > Hi everybody,
> >
> > I'm unsure how to deal with this, so I'm asking here if anybody has ideas.
> >
> > - I'm getting serious spam from fedora-notif on IRC about successful -
> > and a lot more failed - ELN builds for my packages (triggered either
> > by ELN developers or automatically by their CI)
>
> I hope successful builds aren't too much of a pain; failed builds
> should preferably be addressed, ideally by you. Unless it's clearly
> not a problem in your package.
>
> > - bodhi is spamming bugzilla by changing the "Fixed in Version" field
> > every time a new ELN build succeds with a new %dist value (one
> > bugzilla email each for eln106, eln107, eln108, etc.)
>
> This sounds wrong to me but maybe it's relevant for potential ELN
> consumers to know if a bug was also addressed in ELN. Is that an
> issue?
>
> > At this point, almost half of the bugzilla mail I get and a majority
> > of the IRC notifications are "ELN spam" that I do not know how to deal
> > with / is not actionable for me. It's now so bad that I'd like to get
> > the packages that are failing to build (multiple times a day) in ELN
> > fixed just so I don't get spammed with "failed to build" notifications
> > anymore ...
>
> I wonder why you're getting so many build notifications. These should
> only be triggered when you update your package in Rawhide. But again,
> fixing build failures would generally be a good thing.

I maintain 400 (co-maintain 1600) packages and have submitted almost
300 package updates in the past month alone. That's probably the
reason for the amount.

The build failures are certainly not my problem, because the packages
built (and still build) fine in rawhide.

I assume they fail because they're getting built in the wrong order in
ELN (I use side tags for order-sensitive builds), or they're missing
new dependencies that are not in ELN yet.
I can do nothing about either of those things, only wait until the CI
submits the failed builds often enough until they land in the correct
order, which takes n! tries in the "random" order the CI submits the
builds, resulting in a large number of failed koji builds.

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

Review request: mingw-openexr

[Sandro Mani]

Hi

Similarly to the native package, I've reworked the mingw-ilmbase and 
mingw-OpenEXR packages to a single mingw-openexr package. Review request 
is here:


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

Happy to review in exchange.

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

Announcing the Pantheon SIG

[Fabio Valentini]

Good day everybody,

With ever-increasing interest in running the Pantheon DE on fedora, we
decided to create a SIG for Pantheon!

There's the obligatory Wiki page:
https://fedoraproject.org/wiki/SIGs/Pantheon

We have created a dedicated IRC channel: #fedora-pantheon

There's also tracking project on pagure:
https://pagure.io/pantheon-fedora/pantheon-sig

And the pantheon-fedora namespace on pagure for
Pantheon-on-Fedora-related projects:
https://pagure.io/group/pantheon-fedora

Reminder that there's also kinda-supported COPR builds for staging
updates and nightly "CI" builds (giving you a preview of what's coming
with elementary OS 6!):
https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-staging/
https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/

If there is enough interest (and more people willing to help with
packaging and testing), we will request a FAS group for the SIG and an
official mailing list as well.

A goal for the future would be a Pantheon Spin of Fedora, but there's
still some missing pieces before that can happen, and we need your
help (yes, I'm talking to *you*)!

Thanks to Christopher "amz" for getting the ball rolling wrt. launching the SIG.

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

Re: What to do about ELN-related "spam"?

[Aleksandra Fedorova]

Hi, Fabio,

On Thu, Dec 17, 2020 at 1:22 PM Fabio Valentini  wrote:
>
> On Thu, Dec 17, 2020 at 12:37 PM Petr Šabata  wrote:
> >
> > On Thu, Dec 17, 2020 at 12:27 PM Fabio Valentini  
> > wrote:
> > >
> > > Hi everybody,
> > >
> > > I'm unsure how to deal with this, so I'm asking here if anybody has ideas.
> > >
> > > - I'm getting serious spam from fedora-notif on IRC about successful -
> > > and a lot more failed - ELN builds for my packages (triggered either
> > > by ELN developers or automatically by their CI)
> >
> > I hope successful builds aren't too much of a pain; failed builds
> > should preferably be addressed, ideally by you. Unless it's clearly
> > not a problem in your package.
> >
> > > - bodhi is spamming bugzilla by changing the "Fixed in Version" field
> > > every time a new ELN build succeds with a new %dist value (one
> > > bugzilla email each for eln106, eln107, eln108, etc.)
> >
> > This sounds wrong to me but maybe it's relevant for potential ELN
> > consumers to know if a bug was also addressed in ELN. Is that an
> > issue?
> >
> > > At this point, almost half of the bugzilla mail I get and a majority
> > > of the IRC notifications are "ELN spam" that I do not know how to deal
> > > with / is not actionable for me. It's now so bad that I'd like to get
> > > the packages that are failing to build (multiple times a day) in ELN
> > > fixed just so I don't get spammed with "failed to build" notifications
> > > anymore ...
> >
> > I wonder why you're getting so many build notifications. These should
> > only be triggered when you update your package in Rawhide. But again,
> > fixing build failures would generally be a good thing.
>
> I maintain 400 (co-maintain 1600) packages and have submitted almost
> 300 package updates in the past month alone. That's probably the
> reason for the amount.
>
> The build failures are certainly not my problem, because the packages
> built (and still build) fine in rawhide.
>
> I assume they fail because they're getting built in the wrong order in
> ELN (I use side tags for order-sensitive builds), or they're missing
> new dependencies that are not in ELN yet.
> I can do nothing about either of those things, only wait until the CI
> submits the failed builds often enough until they land in the correct
> order, which takes n! tries in the "random" order the CI submits the
> builds, resulting in a large number of failed koji builds.

Unfortunately there is no way to manage these notifications from the
ELN SIG side. The ELN automation doesn't send any messages on its own.
(We do file BZ's for ELN FTBFS issues for RHEL developers under RHEL
Product umbrella in bugzilla, but this is done on agreement with RHEL
Engineering)

The notifications you get are sent by Koji and Bodhi.

The issue was reported for Bodhi some time ago[1]

The IRC notifications can be controlled via Notifications App.
Afaik, by default they are configured so that you get notified about
all builds for packages you maintain, no matter the target or owner of
the build. But it can be changed in the app interface.

We welcome contributors to the ELN SIG, but we have no intent to push
any responsibility regarding ELN builds on people who have no interest
in them. It is only the limitation of the current messaging
infrastructure, which creates the inconvenience.

[1] https://github.com/fedora-infra/bodhi/issues/4094
[2] https://apps.fedoraproject.org/notifications


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

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

Re: What to do about ELN-related "spam"?

[Vít Ondruch]

Dne 17. 12. 20 v 12:37 Petr Šabata napsal(a):

On Thu, Dec 17, 2020 at 12:27 PM Fabio Valentini  wrote:

Hi everybody,

I'm unsure how to deal with this, so I'm asking here if anybody has ideas.

- I'm getting serious spam from fedora-notif on IRC about successful -
and a lot more failed - ELN builds for my packages (triggered either
by ELN developers or automatically by their CI)

I hope successful builds aren't too much of a pain; failed builds
should preferably be addressed, ideally by you. Unless it's clearly
not a problem in your package.



Addressing FTBFS is indeed good idea, but what I don't understand is why 
in the times rubygem-shoulda-matchers was broken in Fedora for months, 
ELN tried rebuild every two hours. There is certainly space for 
improvement. Once packages is FTBFS in Fedora, it probably won't start 
magically build in ELN.



Vít




OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


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

Re: What is the most time consuming task for you as packager?

[Vít Ondruch]

Dne 17. 12. 20 v 12:30 Fabio Valentini napsal(a):

On Thu, Dec 17, 2020 at 10:14 AM Vít Ondruch  wrote:


Dne 16. 12. 20 v 21:56 Neal Gompa napsal(a):

On Wed, Dec 16, 2020 at 3:34 PM Kevin Fenzi  wrote:

On Wed, Dec 16, 2020 at 07:15:21PM +, Jonathan Wakely wrote:

On 15/12/20 23:46 +0100, Miro Hrončok wrote:

On 12/15/20 11:29 PM, Miroslav Suchý wrote:

I am looking for challenges for upcoming year - what I and my team should 
enhance. I have some ideas, but I want to hear
yours.

Thanks for doing this!


What you - as Fedora packager - find most time consuming on packaging?

Coordination and communication ;)


Where you will welcome more simplicity or automation?

In testing an impact of a change. E.g. a simple "upgrade to newer
version" change might be a problem if it breaks other packages. I
usually spin up a copr repo and try to rebuild every dependent package

^ This.

The individual steps of doing a single package are insignificant
compared to the days or WEEKS it takes for a systemwide change that
requires rebuilding hundreds of dependencies. I know not many of us
actually have this problem, but for those who do, it's very, very time
consuming.

Since we're apparently not allowed to use a side tag to do a test
rebuild for this kind of thing, I end up doing it locally on my own
machines. Copr is another option, but I don't think it would be any
quicker or simpler.

You actually can use a side tag, but it's not very streamlined.
1. make side-tag
2. push your changes to a whatever branch on the package that you are
changing.
3. build package from that branch into the sidetag
4. scratch build all the dependent packages in the sidetag and they will
use the changed package. Get them all working.
5. merge your branch back on the package, bump release again
5. actually bump and officially rebuild all the packages in the side tag
6. merge sidetag
7. ask releng to delete the branch you made (or not if you don't care)

But I agree thats not great. ;(


What I'd really like would be a "test mass rebuild" process, where a
prospective package is uploaded and everything that depends on it is
automatically rebuilt (ideally after creating the dependency graph so
each individual package doesn't get rebuilt until its dependencies are
finished building).

Creating the dependency graph by hand is fairly tedious, but maybe I'm
missing an automated way. The point of creating that graph is to avoid
wasting time and power doing and redoing builds that will fail until
something else has been built (which is the problem with mock's
--chain command, if I understand correctly).

Once I have that graph, I use Make to control the process, because it
handles the dependency graph, as well as parallelism, and not
rebuilding things unnecessarily.

Yeah, all this ^


So I've written tools for doing this, and Igor has written tools for
doing this, but it seems like people think that this is "impossible"
and so the effort goes nowhere despite several PoCs.

If we're interested in this again for real this time, I could try to
dig out my old code for it, but we might be better off just pulling
out Koschei's code and turning it into something that Koji's
chain-build command and Mock's --chain option use to sort through
package sets and build them correctly.


in it. However, there are time consuming challenges with this:

1) False failures. Sometimes, the copr build fails for random reason
(Koji repo is not available, etc.). I need to read the logs and figure
it out, resubmit the build.

2) Unrelated failures. Many packages FTBFS for unrelated reasons. I need
to spin up another (control) copr and rebuild all failures there as well
to make sure it's indeed unrelated.

Yes, that's a real pain. Can we just add everything to Koschei instead
of having it opt-in?

Thats worth considering in the new year. I would like that. :)


I would appreciate if Koschei kept more results. It is almost unuseful
these days if one does not have time to check the issue right after it
appears :(

I think this is caused by koji garbage collection?
I assume the retention time it's set very short for scratch builds,
which makes koschei less useful, but keeps storage use in check ...



The root cause is lack of storage :/

Actually I made a RFE to keep copies on Koschei side, but it has not 
materialized:


https://github.com/fedora-infra/koschei/issues/123

(and it might just shift the issue elsewhere, while the 
root.log/build.log would be probably enough and would not consume so 
much space as every build artefact).



V.




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


OpenPGP_0x

Re: What is the most time consuming task for you as packager?

[Vitaly Zaitsev via devel]

On 16.12.2020 20:15, Jonathan Wakely wrote:

What I'd really like would be a "test mass rebuild" process, where a
prospective package is uploaded and everything that depends on it is
automatically rebuilt (ideally after creating the dependency graph so
each individual package doesn't get rebuilt until its dependencies are
finished building).


OBS supports this feature.

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

How to troubleshoot aarch64 and s390x?

[Richard Shaw]

I'm working on building the new openexr package but the unit tests are
failing but just on aarch64 and s390x.

The aarch64 test instances are down due to the infra move and there are
none for s390x.

What's the best way to work around this? An emulated aarch64 install of
Fedora?

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

Re: Proposal: drop "Test installation media" from live media

[Stephen John Smoogen]

On Thu, 17 Dec 2020 at 00:29, przemek klosowski via devel <
devel@lists.fedoraproject.org> wrote:

>
> On 12/16/20 5:38 PM, Kevin Fenzi wrote:
>
> On Wed, Dec 16, 2020 at 04:28:49PM -0500, przemek klosowski via devel wrote:
>
> I was trying to make a point that we don't have a way to check the initial
> image: it could be altered to falsely claim to be signed by fedoraproject.
>
> well, we do: https://getfedora.org/security/
>
> Right, but it's not automatic, and requires an existing known-good system,
> which is the actual 'root of trust' here. This cannot be assumed about a
> flash drive, which is why the automatic image check is hard.
>
> I guess it would involve a secure boot into a fedora signed shim that
>
>- retrieves the checksum over a verified TLS network connection
>- checks the image against that.
>
>
This problem comes up every couple of years and people start trying to work
out how to make it so it is 'trustable'. After about 8 to 12
countermeasures piled on because you found a hole in the last layer.. you
end up with something which might prove it but is as fragile as a house of
cards (which blows over when someone comes up with the 13th whole in the
chain).

The problem with a chain is it is only as strong as its weakest link.. as
soon as you fix that one.. it is only as strong as its next weakest link
which turns out to be as weak as the first one.

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

Re: How to troubleshoot aarch64 and s390x?

[Richard Shaw]

I tried qemu using this link but it's wildly out of date...

https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU

I updated the url for Fedora 33 but it still fails...

sudo virt-install --name f33-aarch64-urlinst --ram 4096 --arch aarch64
--boot uefi --disk size=8 --location
https://download.fedoraproject.org/pub/fedora/linux/releases/33/Server/x86_64/os

Starting install...
Retrieving file vmlinuz...

 |  11 MB
 00:00:00
Retrieving file initrd.img...

|  75 MB
 00:00:01
Allocating 'f33-aarch64-urlinst.qcow2'

 | 8.0 GB
 00:00:00
Removing disk 'f33-aarch64-urlinst.qcow2'

|0 B
 00:00:00
ERRORRemote peer disconnected
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect qemu:///system start f33-aarch64-urlinst
otherwise, please restart your installation.

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

Fedora rawhide compose report: 20201217.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20201216.n.0
NEW: Fedora-Rawhide-20201217.n.0

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

Size of added packages:  975.66 KiB
Size of dropped packages:1.09 MiB
Size of upgraded packages:   2.28 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20201216.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: golang-github-acme-lego-3-3.9.0-1.fc34
Summary: Let's Encrypt client and ACME library written in Go
RPMs:golang-github-acme-lego-3-devel
Size:359.65 KiB

Package: golang-github-libdns-0.1.0-1.fc34
Summary: Core interfaces for universal DNS record manipulation across providers
RPMs:golang-github-libdns-devel
Size:12.13 KiB

Package: golang-github-mholt-acmez-0.1.1-1.fc34
Summary: Premier ACME client library for Go
RPMs:golang-github-mholt-acmez-devel
Size:51.29 KiB

Package: nsca-ng-1.6-1.fc34
Summary: Add-on for transferring check results (and other commands) to Nagios 
or Icinga
RPMs:nsca-ng-client nsca-ng-server
Size:463.28 KiB

Package: python-pypck-0.7.7-1.fc34
Summary: Python LCN-PCK library
RPMs:python3-pypck
Size:89.30 KiB


= DROPPED PACKAGES =
Package: php-pecl-couchbase2-2.6.2-2.fc33
Summary: Couchbase Server PHP extension
RPMs:php-pecl-couchbase2
Size:1.09 MiB


= UPGRADED PACKAGES =
Package:  android-file-transfer-4.1-1.fc34
Old package:  android-file-transfer-4.0-1.fc34
Summary:  Reliable Android MTP client with minimalist UI
RPMs: android-file-transfer
Size: 2.26 MiB
Size change:  5.87 KiB
Changelog:
  * Wed Dec 16 2020 Marek Blaha  - 4.1-1
  - New upstream release 4.1


Package:  arpwatch-14:3.1-2.fc34
Old package:  arpwatch-14:3.1-1.fc34
Summary:  Network monitoring tools for tracking IP addresses on a network
RPMs: arpwatch
Size: 1.50 MiB
Size change:  5.08 KiB
Changelog:
  * Wed Dec 16 2020 Benjamin A. Beasley  - 14:3.1-2
  - Add BR on make for
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot
  - generate ethercodes.dat from latest oui.csv


Package:  audit-3.0-1.fc34
Old package:  audit-3.0-0.21.20191104git1c2f876.fc33
Summary:  User space tools for kernel auditing
RPMs: audispd-plugins audispd-plugins-zos audit audit-libs 
audit-libs-devel python3-audit
Size: 3.07 MiB
Size change:  -25.72 KiB
Changelog:
  * Wed Dec 16 2020 Steve Grubb  3.0-1
  - New upstream feature and bugfix release


Package:  awscli-1.18.197-1.fc34
Old package:  awscli-1.18.196-1.fc34
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.95 MiB
Size change:  294 B
Changelog:
  * Wed Dec 16 2020 Gwyn Ciesla  - 1.18.197-1
  - 1.18.197


Package:  bcm283x-firmware-20201216-1.8a5549c.fc34
Old package:  bcm283x-firmware-20201215-1.ce59305.fc34
Summary:  Firmware for the Broadcom bcm283x/bcm2711 used in the Raspberry Pi
RPMs: bcm2711-firmware bcm2835-firmware bcm283x-firmware 
bcm283x-overlays
Size: 13.62 MiB
Size change:  1.46 KiB
Changelog:
  * Tue Dec 15 2020 Peter Robinson  
20201216-1.8a5549c
  - Updates to device tree overlays


Package:  cjdns-21.1-2.fc34
Old package:  cjdns-21-3.fc34
Summary:  The privacy-friendly network without borders
RPMs: cjdns cjdns-graph cjdns-selinux cjdns-tools python3-cjdns
Size: 2.80 MiB
Size change:  -50.61 KiB
Changelog:
  * Wed Dec 16 2020 Stuart Gathman  - 21-4
  - Support gcc-11, drop el6 support.

  * Wed Dec 16 2020 Stuart Gathman  - 21.1-1
  - New upstream release

  * Wed Dec 16 2020 Stuart Gathman  - 21.1-2
  - Reenable seccomp for armv7hl


Package:  clementine-1.4.0-5.rc1.20201216gitccba649.fc34.1
Old package:  clementine-1.4.0-4.rc1.20200617gitedb8c3b.fc34.1
Summary:  A music player and library organizer
RPMs: clementine
Size: 26.78 MiB
Size change:  -7.87 KiB
Changelog:
  * Wed Dec 16 2020 Robert-Andr?? Mauchin  - 
1.4.0-5.rc1.20201216gitccba649
  - Bump to commit ccba649f622497b8463930b9ad5b7a1cafe6c976
  - Fix: rhbz#1907789


Package:  dnscrypt-proxy-2.0.44-5.fc34
Old package:  dnscrypt-proxy-2.0.44-4.fc34
Summary:  Flexible DNS proxy, with support for encrypted DNS protocols
RPMs: dnscrypt-proxy
Size: 14.94 MiB
Size change:  4.21 KiB
Changelog:
  * Wed Dec 16 2020 Robert-Andr?? Mauchin  - 2.0.44-5
  - Fallback to recommended installation


Package:  doctest-2.4.3-1.fc34
Old package:  doctest-2.4.1-1.fc34
Summary:  Feature-rich header-only C++ testing framework
RPMs: doctest-devel
Size: 436.96 KiB
Size change:  6.47 KiB
Changelog:
  * Wed Dec 16 2020 Nick Black  - 2.4.3-1
  - New upstream release


Pa

Re: End of CentOS Linux: What about Fedora?

[Stephen John Smoogen]

On Thu, 17 Dec 2020 at 04:45, Robin Opletal  wrote:

> I think this wouldn't be that much of a problem - what I think is bad is
> that CentOS Stream security updates aren't going to come before RHEL's
> will, and they will essentially be backported, at least as I understood
> it.
>
>
a) CentOS regular security updates don't come before RHEL's so there is no
change here.

Here is what happens currently for regular CentOS.

RHEL engineers do all their work internally and push their changes to a
CDN. Customers then get those binaries.
The team which does these pushes then pushes the source code into the
centos look-aside cache and the specs+patches into the git repo.
That team then sends an email to the CentOS admins who then start building
the code. Then this loop begins

for (code is not built){
 build code
if code builds and passes t_functional then break
else { check chain of rebuilds to see if order changed. if yes {break} if
no check to see if more code was needed to be pushed.. get that pushed..
break}
endfor
push the updates to the mirrors for people.


If updates are a long time then the complaints go to the CentOS devels who
will say 'it is ready when it is ready'.

Here is what happens differently with CentOS Stream... not much except that
CentOS Stream is supposed to work and every failed compose, delay, etc is
going to get a lot more media attention.. so no pressure folks (he says to
himself as he goes to make sure that it keeps working).


Correct me if I am wrong
>
> On Wed Dec 9, 2020 at 5:52 PM CET, Adam Williamson wrote:
> > It's a rolling release *of a stable RHEL branch*. You're not getting
> > radical new changes if you run CentOS Stream; you're just getting the
> > changes you'd usually get in RHEL stable point releases (e.g. 8.1, 8.2
> > etc) but getting them early and as they are produced, rather than in
> > periodic lumps).
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


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

Re: End of CentOS Linux: What about Fedora?

[Kevin Kofler via devel]

Robin Opletal wrote:
> I think this wouldn't be that much of a problem - what I think is bad is
> that CentOS Stream security updates aren't going to come before RHEL's
> will, and they will essentially be backported, at least as I understood
> it.

That would be a forward-port then, not a backport.

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

Re: What is the most time consuming task for you as packager?

[Stephen John Smoogen]

On Thu, 17 Dec 2020 at 04:14, Vít Ondruch  wrote:

>
> Dne 16. 12. 20 v 21:56 Neal Gompa napsal(a):
>
> >>> Yes, that's a real pain. Can we just add everything to Koschei instead
> >>> of having it opt-in?
> >> Thats worth considering in the new year. I would like that. :)
> >>
>
> I would appreciate if Koschei kept more results. It is almost unuseful
> these days if one does not have time to check the issue right after it
> appears :(
>
>
>
Sadly we do not have the amount of disk space needed for that. Koschei
fills up our koji partition regularly. The partition has a 100TB HARD limit
and between koschei, ELN and regular update rebuilds we bounce off it
multiple times a release. Then when we try to garbage collect all those we
regularly end up with koji outages.. which then pile up a whole bunch of
new ones which have to be garbage collected.

For longer koschei builds we would need to do this in a different resources
than what we have.


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


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

Re: What is the most time consuming task for you as packager?

[Vít Ondruch]

Dne 17. 12. 20 v 15:06 Stephen John Smoogen napsal(a):



On Thu, 17 Dec 2020 at 04:14, Vít Ondruch > wrote:



Dne 16. 12. 20 v 21:56 Neal Gompa napsal(a):

>>> Yes, that's a real pain. Can we just add everything to Koschei
instead
>>> of having it opt-in?
>> Thats worth considering in the new year. I would like that. :)
>>

I would appreciate if Koschei kept more results. It is almost
unuseful
these days if one does not have time to check the issue right
after it
appears :(



Sadly we do not have the amount of disk space needed for that. Koschei 
fills up our koji partition regularly. The partition has a 100TB HARD 
limit and between koschei, ELN and regular update rebuilds we bounce 
off it multiple times a release. Then when we try to garbage collect 
all those we regularly end up with koji outages.. which then pile up a 
whole bunch of new ones which have to be garbage collected.


For longer koschei builds we would need to do this in a different 
resources than what we have.



I understand, but if the garbage collection initially removed everything 
except logs, that would help tremendously.



Vít



Vít


> Yes please!
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org

> To unsubscribe send an email to
devel-le...@lists.fedoraproject.org

> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines

> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org

To unsubscribe send an email to
devel-le...@lists.fedoraproject.org

Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org





--
Stephen J Smoogen.


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


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


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

Re: Proposal: drop "Test installation media" from live media

[Marius Schwarz]

Am 17.12.20 um 14:35 schrieb Stephen John Smoogen:
Right, but it's not automatic, and requires an existing known-good 
system, which is the actual 'root of trust' here. This cannot be 
assumed about a flash drive, which is why the automatic image check is 
hard. 


Speaking from Security pov, it's not hard, it's impossible. The attacker 
can sign everything with it's own cert and putting that into the image 
itself. Way easier is it to remove the check for a valid sig and always 
return "true" is asked for a match, as any root kit will do.


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

Fedora-IoT-34-20201217.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

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

New failures (same test not failed in Fedora-IoT-34-20201216.0):

ID: 742805  Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_rebase
URL: https://openqa.fedoraproject.org/tests/742805

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

ID: 742802  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/742802
ID: 742811  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/742811
ID: 742813  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/742813
ID: 742814  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/742814
ID: 742816  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/742816
ID: 742820  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/742820

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

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

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

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

New passes (same test not passed in Fedora-IoT-34-20201216.0):

ID: 742822  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/742822
ID: 742825  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/742825

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.46 to 0.23
Previous test data: https://openqa.fedoraproject.org/tests/741937#downloads
Current test data: https://openqa.fedoraproject.org/tests/742796#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.30 to 0.17
Previous test data: https://openqa.fedoraproject.org/tests/741938#downloads
Current test data: https://openqa.fedoraproject.org/tests/742797#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

Orphaning yad

[Elder Marco]

Hi all,

I've just orphaned yad[1], as I do not use it for a long time. It would be
great if someone could give it more care. The package needs an update.

Feel free to take it

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

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

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

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

Failed openQA tests: 16/180 (x86_64), 16/122 (aarch64)

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

ID: 742421  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/742421
ID: 742429  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/742429
ID: 742459  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/742459
ID: 742522  Test: aarch64 Server-dvd-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/742522
ID: 742569  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/742569
ID: 742644  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/742644
ID: 742684  Test: aarch64 universal install_serial_console@uefi
URL: https://openqa.fedoraproject.org/tests/742684

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

ID: 742408  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/742408
ID: 742418  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/742418
ID: 742419  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/742419
ID: 742420  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/742420
ID: 742426  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/742426
ID: 742432  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/742432
ID: 742433  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/742433
ID: 742444  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/742444
ID: 742451  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/742451
ID: 742484  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/742484
ID: 742521  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/742521
ID: 742532  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/742532
ID: 742533  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/742533
ID: 742535  Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/742535
ID: 742538  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/742538
ID: 742539  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/742539
ID: 742549  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/742549
ID: 742624  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/742624
ID: 742651  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/742651
ID: 742655  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/742655
ID: 742662  Test: aarch64 universal install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/742662
ID: 742678  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/742678
ID: 742683  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/742683
ID: 742687  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/742687
ID: 742690  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/742690

Soft failed openQA tests: 17/180 (x86_64), 11/122 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 742390  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/742390
ID: 742391  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/742391
ID: 742398  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/742398
ID: 742402  Test: x86_64 Server-dvd-i

Re: How to troubleshoot aarch64 and s390x?

[Qiyu Yan]

Richard Shaw  于2020年12月17日周四 下午9:34写道：
>
> I'm working on building the new openexr package but the unit tests are 
> failing but just on aarch64 and s390x.
>
> The aarch64 test instances are down due to the infra move and there are none 
> for s390x.
>
> What's the best way to work around this? An emulated aarch64 install of 
> Fedora?
I may use a raspberry pi for testing aarch64 applications, or if
downloading fails for some reason, maybe it could be possible to
download those files in advance and specify a local path?
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Chromium built in rawhide does not render most strings

[Tom Callaway]

Okay, this one has me stumped. Any chromium package I build through rawhide
refuses to render most of the strings.

At first, I thought this was gcc 11, but then I noticed that the first
build with this problem was built before GCC 11 landed in rawhide (the
compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
must be due to a newer system component that Chromium uses dynamically, but
I was able to disprove that by installing the Fedora 33 build (same
version-release) into a Rawhide VM, and it works fine. Google Chrome also
works fine in rawhide.

It seems that this must be something that is contained within chromium,
that when built in rawhide, builds broken.

Here's a screenshot of what it looks like:
https://twitter.com/spotfoss/status/1338918235719299072/photo/1

Note that some text strings are rendering (in the UI, in the "search box"),
but most of them are not (the "HTML5Test" text below the icon, all of the
strings in the developer console).

Chromium has a lot of bundled components, so it is usually fairly resistant
to system changes. There are no differences between how Chromium builds
(within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
%{optflags}, so the compiler flags are equivalent.

Could this be due to some quirk of binutils in the way chromium gets linked
in rawhide? Is there something else unique to how packages are built in
rawhide right now? Are any other rawhide packages having similar string
issues?

Here are some builds for comparison:

Fedora 34: Chromium 87.0.4280.88 (built against GCC 11):
  https://koji.fedoraproject.org/koji/taskinfo?taskID=57595738
Fedora 34: Chromium 87.0.4280.88 (built against GCC 10, same as Fedora 33):
  https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 33: Chromium 87.0.4280.88 (build against GCC 10, but actually works
in rawhide):
  https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 34: Chromium 88.0.4324.27 (beta version of chromium, also broken)
  https://koji.fedoraproject.org/koji/taskinfo?taskID=56977476

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

Re: How to troubleshoot aarch64 and s390x?

[Qiyu Yan]

Richard Shaw  于2020年12月17日周四 下午9:34写道：
>
> I'm working on building the new openexr package but the unit tests are 
> failing but just on aarch64 and s390x.
And if having problems with s390x, https://linuxone.cloud.marist.edu/
provides a free s390x vps (at least last time I used its service)
>
> The aarch64 test instances are down due to the infra move and there are none 
> for s390x.
>
> What's the best way to work around this? An emulated aarch64 install of 
> Fedora?
>
> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Chromium built in rawhide does not render most strings

[Kalev Lember]

On Thu, Dec 17, 2020 at 5:12 PM Tom Callaway  wrote:

> Okay, this one has me stumped. Any chromium package I build through
> rawhide refuses to render most of the strings.
>
> At first, I thought this was gcc 11, but then I noticed that the first
> build with this problem was built before GCC 11 landed in rawhide (the
> compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
> must be due to a newer system component that Chromium uses dynamically, but
> I was able to disprove that by installing the Fedora 33 build (same
> version-release) into a Rawhide VM, and it works fine. Google Chrome also
> works fine in rawhide.
>
> It seems that this must be something that is contained within chromium,
> that when built in rawhide, builds broken.
>
> Here's a screenshot of what it looks like:
> https://twitter.com/spotfoss/status/1338918235719299072/photo/1
>
> Note that some text strings are rendering (in the UI, in the "search
> box"), but most of them are not (the "HTML5Test" text below the icon, all
> of the strings in the developer console).
>

Can you try downgrading cairo to the f33 version (1.16.0), just to rule
that out? We updated it to the 1.17.4 development version in rawhide and I
think we're the first distro to ship it, so it could possibly have issues.

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

Re: Chromium built in rawhide does not render most strings

[Robbie Harwood]

Tom Callaway  writes:

> Okay, this one has me stumped. Any chromium package I build through rawhide
> refuses to render most of the strings.
>
> At first, I thought this was gcc 11, but then I noticed that the first
> build with this problem was built before GCC 11 landed in rawhide (the
> compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
> must be due to a newer system component that Chromium uses dynamically, but
> I was able to disprove that by installing the Fedora 33 build (same
> version-release) into a Rawhide VM, and it works fine. Google Chrome also
> works fine in rawhide.
>
> Chromium has a lot of bundled components, so it is usually fairly resistant
> to system changes. There are no differences between how Chromium builds
> (within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
> %{optflags}, so the compiler flags are equivalent.
>
> Could this be due to some quirk of binutils in the way chromium gets linked
> in rawhide? Is there something else unique to how packages are built in
> rawhide right now? Are any other rawhide packages having similar string
> issues?

Have you tried the reverse?  rawhide-built chromium into fc33?

Thanks,
--Robbie


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

Re: Chromium built in rawhide does not render most strings

[Tom Callaway]

I cannot install the rawhide-built chromium into F33 without bringing glibc
from rawhide with me:

[spot@localhost ~]$ sudo rpm -Uvh
chromium-common-87.0.4280.88-1.fc34.x86_64.rpm
chromium-87.0.4280.88-1.fc34.x86_64.rpm
error: Failed dependencies:
libc.so.6(GLIBC_2.33)(64bit) is needed by
chromium-common-87.0.4280.88-1.fc34.x86_64
libc.so.6(GLIBC_2.33)(64bit) is needed by
chromium-87.0.4280.88-1.fc34.x86_64

When I _just_ update glibc from rawhide on an otherwise Fedora 33 instance
(glibc, glibc-all-langpacks, glibc-common, glibc-devel, glibc-headers-x86,
glibc-langpack-en), then install the rawhide built chromium, it exhibits
the same missing strings bug.

~spot



On Thu, Dec 17, 2020 at 11:29 AM Robbie Harwood  wrote:

> Tom Callaway  writes:
>
> > Okay, this one has me stumped. Any chromium package I build through
> rawhide
> > refuses to render most of the strings.
> >
> > At first, I thought this was gcc 11, but then I noticed that the first
> > build with this problem was built before GCC 11 landed in rawhide (the
> > compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
> > must be due to a newer system component that Chromium uses dynamically,
> but
> > I was able to disprove that by installing the Fedora 33 build (same
> > version-release) into a Rawhide VM, and it works fine. Google Chrome also
> > works fine in rawhide.
> >
> > Chromium has a lot of bundled components, so it is usually fairly
> resistant
> > to system changes. There are no differences between how Chromium builds
> > (within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
> > %{optflags}, so the compiler flags are equivalent.
> >
> > Could this be due to some quirk of binutils in the way chromium gets
> linked
> > in rawhide? Is there something else unique to how packages are built in
> > rawhide right now? Are any other rawhide packages having similar string
> > issues?
>
> Have you tried the reverse?  rawhide-built chromium into fc33?
>
> Thanks,
> --Robbie
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

FedoraRespin-33-updates-20201215.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 6/37 (x86_64)

ID: 742843  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/742843
ID: 742846  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/742846
ID: 742848  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/742848
ID: 742853  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/742853
ID: 742855  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/742855
ID: 742856  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/742856

Passed openQA tests: 16/37 (x86_64)

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

Re: Orphaning yad

[Dmitry Butskoy]

Elder Marco wrote:

Hi all,

I've just orphaned yad[1], as I do not use it for a long time. It 
would be great if someone could give it more care. The package needs 
an update.



I've taken it.

I am already involved with upstream a bit, anyway.

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

Re: Chromium built in rawhide does not render most strings

[Mattia Verga via devel]

Il 17/12/20 17:12, Tom Callaway ha scritto:
> Okay, this one has me stumped. Any chromium package I build through 
> rawhide refuses to render most of the strings.

Seems similar to what I reported for Falkon:

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

Does Chromium uses qt5-qtwebengine?

Mattia

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

Re: Chromium built in rawhide does not render most strings

[Neal Gompa]

On Thu, Dec 17, 2020 at 12:02 PM Mattia Verga via devel
 wrote:
>
> Il 17/12/20 17:12, Tom Callaway ha scritto:
> > Okay, this one has me stumped. Any chromium package I build through
> > rawhide refuses to render most of the strings.
>
> Seems similar to what I reported for Falkon:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1904652
>
> Does Chromium uses qt5-qtwebengine?
>

QtWebEngine *is* Chromium, so it would make sense that it exhibits the
same problem.


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

Re: Chromium built in rawhide does not render most strings

[Robbie Harwood]

Tom Callaway  writes:

> I cannot install the rawhide-built chromium into F33 without bringing glibc
> from rawhide with me:
>
> [spot@localhost ~]$ sudo rpm -Uvh
> chromium-common-87.0.4280.88-1.fc34.x86_64.rpm
> chromium-87.0.4280.88-1.fc34.x86_64.rpm
> error: Failed dependencies:
> libc.so.6(GLIBC_2.33)(64bit) is needed by
> chromium-common-87.0.4280.88-1.fc34.x86_64
> libc.so.6(GLIBC_2.33)(64bit) is needed by
> chromium-87.0.4280.88-1.fc34.x86_64
>
> When I _just_ update glibc from rawhide on an otherwise Fedora 33 instance
> (glibc, glibc-all-langpacks, glibc-common, glibc-devel, glibc-headers-x86,
> glibc-langpack-en), then install the rawhide built chromium, it exhibits
> the same missing strings bug.

Interesting.  Seems like that points at the problem being
glibc-adjacent, no?  That's still really wide though...

Thanks,
--Robbie


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

Re: Chromium built in rawhide does not render most strings

[Tom Callaway]

Certainly not ruling out glibc as the problem here, but if it was glibc, I
would think the problem would arise when I install the Fedora 33 build in
rawhide, and it does not...

~spot

On Thu, Dec 17, 2020 at 12:10 PM Robbie Harwood  wrote:

> Tom Callaway  writes:
>
> > I cannot install the rawhide-built chromium into F33 without bringing
> glibc
> > from rawhide with me:
> >
> > [spot@localhost ~]$ sudo rpm -Uvh
> > chromium-common-87.0.4280.88-1.fc34.x86_64.rpm
> > chromium-87.0.4280.88-1.fc34.x86_64.rpm
> > error: Failed dependencies:
> > libc.so.6(GLIBC_2.33)(64bit) is needed by
> > chromium-common-87.0.4280.88-1.fc34.x86_64
> > libc.so.6(GLIBC_2.33)(64bit) is needed by
> > chromium-87.0.4280.88-1.fc34.x86_64
> >
> > When I _just_ update glibc from rawhide on an otherwise Fedora 33
> instance
> > (glibc, glibc-all-langpacks, glibc-common, glibc-devel,
> glibc-headers-x86,
> > glibc-langpack-en), then install the rawhide built chromium, it exhibits
> > the same missing strings bug.
>
> Interesting.  Seems like that points at the problem being
> glibc-adjacent, no?  That's still really wide though...
>
> Thanks,
> --Robbie
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Chromium built in rawhide does not render most strings

[Tom Callaway]

I downgraded cairo to 1.16.0-9.fc33 and it had no effect, the bug remained.

Thanks,
~spot

On Thu, Dec 17, 2020 at 11:19 AM Kalev Lember  wrote:

> On Thu, Dec 17, 2020 at 5:12 PM Tom Callaway  wrote:
>
>> Okay, this one has me stumped. Any chromium package I build through
>> rawhide refuses to render most of the strings.
>>
>> At first, I thought this was gcc 11, but then I noticed that the first
>> build with this problem was built before GCC 11 landed in rawhide (the
>> compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
>> must be due to a newer system component that Chromium uses dynamically, but
>> I was able to disprove that by installing the Fedora 33 build (same
>> version-release) into a Rawhide VM, and it works fine. Google Chrome also
>> works fine in rawhide.
>>
>> It seems that this must be something that is contained within chromium,
>> that when built in rawhide, builds broken.
>>
>> Here's a screenshot of what it looks like:
>> https://twitter.com/spotfoss/status/1338918235719299072/photo/1
>>
>> Note that some text strings are rendering (in the UI, in the "search
>> box"), but most of them are not (the "HTML5Test" text below the icon, all
>> of the strings in the developer console).
>>
>
> Can you try downgrading cairo to the f33 version (1.16.0), just to rule
> that out? We updated it to the 1.17.4 development version in rawhide and I
> think we're the first distro to ship it, so it could possibly have issues.
>
> --
> Kalev
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Summary/Minutes for today's FESCo meeting (2020-12-16)

[James Cassell]

On Thu, Dec 17, 2020, at 6:32 AM, Miroslav Suchý wrote:
> Dne 16. 12. 20 v 16:47 Fabio Valentini napsal(a):
> > * #2519 F34 Change: GitRepos-master-to-main  (decathorpe, 15:09:57)
> >   * AGREED: APPROVED (+6, 0, -0)  (decathorpe, 15:27:51)
> 
> 
> /me saving you time to read the log for **what** was actually approved:
> 
> 15:19:05  Proposal: Approve proposal to rename branch names 
> from "master" to "main" except in dist-git-like
> repositories with branches matching fedora releases, where "rawhide" is 
> preferred.
> 15:19:43  Where the new default branch will be "rawhide", 
> create symbolic refs from "main" to "rawhide".
> 

Thanks for clarifying!

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

Re: Summary/Minutes for today's FESCo meeting (2020-12-16)

[Fabio Valentini]

On Thu, Dec 17, 2020 at 6:22 PM James Cassell
 wrote:
>
>
>
> On Thu, Dec 17, 2020, at 6:32 AM, Miroslav Suchý wrote:
> > Dne 16. 12. 20 v 16:47 Fabio Valentini napsal(a):
> > > * #2519 F34 Change: GitRepos-master-to-main  (decathorpe, 15:09:57)
> > >   * AGREED: APPROVED (+6, 0, -0)  (decathorpe, 15:27:51)
> >
> >
> > /me saving you time to read the log for **what** was actually approved:
> >
> > 15:19:05  Proposal: Approve proposal to rename branch names
> > from "master" to "main" except in dist-git-like
> > repositories with branches matching fedora releases, where "rawhide" is
> > preferred.
> > 15:19:43  Where the new default branch will be "rawhide",
> > create symbolic refs from "main" to "rawhide".
> >
>
> Thanks for clarifying!

I apologize for not copying my final (slightly modified) proposal into
the meeting minutes, I didn't want to cause confusion.
I copied the text into the corresponding ticket, but forgot to paste
it into the email as well. Thank you for clarifying.

I made this proposal hoping that it reflects most concerns and
opinions that were raised during the discussion on this list and in
the FESCo ticket, and it was approved unanimously by all present FESCo
members, so I hope this way forward is acceptable for most Fedoreans.
(Fedorons? Fedorans?)

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

Re: Summary/Minutes for today's FESCo meeting (2020-12-16)

[Neal Gompa]

On Thu, Dec 17, 2020 at 12:33 PM Fabio Valentini  wrote:
>
> On Thu, Dec 17, 2020 at 6:22 PM James Cassell
>  wrote:
> >
> >
> >
> > On Thu, Dec 17, 2020, at 6:32 AM, Miroslav Suchý wrote:
> > > Dne 16. 12. 20 v 16:47 Fabio Valentini napsal(a):
> > > > * #2519 F34 Change: GitRepos-master-to-main  (decathorpe, 15:09:57)
> > > >   * AGREED: APPROVED (+6, 0, -0)  (decathorpe, 15:27:51)
> > >
> > >
> > > /me saving you time to read the log for **what** was actually approved:
> > >
> > > 15:19:05  Proposal: Approve proposal to rename branch names
> > > from "master" to "main" except in dist-git-like
> > > repositories with branches matching fedora releases, where "rawhide" is
> > > preferred.
> > > 15:19:43  Where the new default branch will be "rawhide",
> > > create symbolic refs from "main" to "rawhide".
> > >
> >
> > Thanks for clarifying!
>
> I apologize for not copying my final (slightly modified) proposal into
> the meeting minutes, I didn't want to cause confusion.
> I copied the text into the corresponding ticket, but forgot to paste
> it into the email as well. Thank you for clarifying.
>
> I made this proposal hoping that it reflects most concerns and
> opinions that were raised during the discussion on this list and in
> the FESCo ticket, and it was approved unanimously by all present FESCo
> members, so I hope this way forward is acceptable for most Fedoreans.
> (Fedorons? Fedorans?)
>

It's "Fedorans". :)



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

Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Ben Cotton]

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


== Summary ==
This change should enable an opt-in spec file preprocessor in Fedora
infrastructure for the benefit of packagers. The preprocessor allows
some very neat tricks that were impossible before, for example
generate changelog and release automatically from git metadata or pack
the entire dist-git repository into an rpm-source tarball (effectively
allowing unpacked repos to live in DistGit).

== Owner ==
* Name: [[User:clime| Michal Novotný]]
* Email: cl...@fedoraproject.org


== Detailed Description ==

There is a recently added feature into mock:
[https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocessor
the rpkg preprocessor] which, if enabled, introduces an intermediate
step just before srpm building. This step consists of running the spec
file through a text preprocessing engine that includes an already
present library of macros designed specifically for rpm spec file
generation from git metadata. This library is called
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros]. The macros there allow packagers to have their
`%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
automatically generated from dist-git repository data and metadata.
The library can be easily extended in future to support more packager
use-cases or even a completely new library can be developed that
doesn't look at git metadata at all and instead, for example, analyses
already present tarball content to render spec file based on upstream
information. This doesn't mean it will happen but the framework is
generic enough to support that. There is also support for user-defined
macros that are loaded on-demand from a file placed alongside the
package sources, maintained by packager. This feature wouldn't be
enabled by this change from start but it's an example of freedom that
the preprocessing framework is able to provide. Enabling this change
should be very easy, basically adding:


config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True


into mock configuration of Koji builders and using at least mock 2.7.
Some very minor change may be also needed in Koji regarding the spec
file lookup.

Even if the change is enabled on the infrastructure level like this,
the packager will still need to opt-in to use the preprocessor. The
opting-in is done by placing `rpkg.conf` file into the package
top-level directory with the following content:


[rpkg]
preprocess_spec = True


When this is done by a packager, the preprocessor will be finally
enabled for the given package.

Alongside, there is an ongoing work to add the preprocessor support
into the `rpkg` python library so that a packager can easily work with
the spec files containing the preprocessor (rpkg) macros:
https://pagure.io/rpkg/pull-request/530

The macros are supported since epel6 until the most latest Fedora
(preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The
spec preprocessing step in mock happens in a target chroot just before
the srpm build.


== Benefit to Fedora ==

This change offers solution to some long-standing issues in Fedora
around packaging (i.e. automatic release and changelog generation)
while also offering some interesting future options (for example
unpacked dist-git repos). The big advantage of this approach is that
it is explicit. Spec file stays the source of truth and by looking
inside one, you will be able to determine how the text will expand for
a certain git repository state.

== Scope ==
* Proposal owners:
For the very basic support, probably a small patch in Koji is needed
to be able to lookup not only `.spec` files but also `.spec.rpkg`
files (the `.spec.rpkg` extension explicitly states that the spec file
is a template). Also the `rpmdevtools/rpmdev-bumpspec` script should
be tweaked to be compatible with spec files using the macros.

* Other developers:
Some optional help with `rpmdevtools/rpmdev-bumpspec` changes would be welcome.

* Release engineering: [https://pagure.io/releng/issue/9910 #9910] (a
check of an impact with Release Engineering is needed)
Enabling the rpkg_preprocessor plugin in mock config for Koji builders.

* Policies and guidelines:
The new macro support should be mentioned or even described in the
packaging guidelines. We should decide if the full power of the
rpkg-macros library should be allowed from start (i.e. even unpacked
repos).

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

* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
Because of the opt-in nature on packager side, there should be no
compatibility issues.

== How To Test ==
Once the feature is enabled, one can test it by providing the
`rpkg.conf` file with the required content in a package repository and
use some rpkg macro in the spec file: e.g.


Name: {{{ git_dir_name }}}


to generate the name of the package from the repository name (this
should actually produce the original text 

Fedora 34 Change: Ruby on Rails 6.1 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_6.1


== Summary ==
Ruby on Rails 6.1 is the latest version of well known web framework
written in Ruby.

== Owner ==
* Name: [[User:pvalena| Pavel Valena]], [[User:vondruch| Vít
Ondruch]], [[User:jaruga| Jun Aruga]]
* Email: pval...@redhat.com, vondr...@redhat.com, jar...@redhat.com,
ruby-...@lists.fedoraproject.org


== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 6.0 in Fedora 33 to 6.1 (latest version) in Fedora 34.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.

== Benefit to Fedora ==
This update will keep Fedora up-to-date and will ensure that the
current Ruby on Rails developers stay with us as they will get support
for system-packaged Ruby on Rails of the latest version. Apart from
that, update to Rails 6.1 will bring Horizontal Sharding, Multi-DB
Improvements, Strict Loading, Destroy Associations in Background,
Error Objects and more. Update to Rails 6.1 contains hundreds of other
fixes and improvements across all the frameworks.

== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated.
** Some dependencies of the Rails stack will need update.

=== Packages need to be created/updated ===

{|
! Package name
! Task
! Bug
! Pull Request
|-
|rubygem-actioncable
|Update to 6.1.x
|[https://bugzilla.redhat.com/show_bug.cgi?id=1906179 #1906179]
|[https://src.fedoraproject.org/rpms/rubygem-actioncable/pull-request/2 PR]
|-
|rubygem-actionmailbox
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actionmailbox/pull-request/1 PR]
|-
|rubygem-actionmailer
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actionmailer/pull-request/2 PR]
|-
|rubygem-actionpack
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actionpack/pull-request/2 PR]
|-
|rubygem-actiontext
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actiontext/pull-request/1 PR]
|-
|rubygem-actionview
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-actionview/pull-request/2 PR]
|-
|rubygem-activejob
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-activejob/pull-request/2 PR]
|-
|rubygem-activemodel
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-activemodel/pull-request/2 PR]
|-
|rubygem-activerecord
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-activerecord/pull-request/3 PR]
|-
|rubygem-activestorage
|Update to 6.1.x
|[https://bugzilla.redhat.com/show_bug.cgi?id=1906180 #1906180]
|[https://src.fedoraproject.org/rpms/rubygem-activestorage/pull-request/3 PR]
|-
|rubygem-activesupport
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-activesupport/pull-request/3 PR]
|-
|rubygem-rails
|Update to 6.1.x
|[https://bugzilla.redhat.com/show_bug.cgi?id=1906183 #1906183]
|[https://src.fedoraproject.org/rpms/rubygem-rails/pull-request/2 PR]
|-
|rubygem-railties
|Update to 6.1.x
|N/A
|[https://src.fedoraproject.org/rpms/rubygem-railties/pull-request/2 PR]
|}
Current development state can be observed in
[https://copr.fedorainfracloud.org/coprs/pvalena/ruby-on-rails/
pvalena/ruby-on-rails] COPR repository.
* Other developers: Update Rails dependent packages to be working with
Ruby on Rails 6.1

* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Web applications build above Ruby on Rails framework might need to be
updated. Official upstream upgrade guide might come handy:
http://guides.rubyonrails.org/upgrading_ruby_on_rails.html

== How To Test ==
* No special hardware is needed.

=== To test Rails 6.1 from upstream ===

gem install rails -v 6.1.x
rails new app
cd app && rails s

* Go to http://127.0.0.1:3000/ and make sure you are running Rails 6.1.x

=== To test only Rails itself ===

dnf install rubygem-rails
rails new app
cd app && rails s

* Go to http://127.0.0.1:3000/ and make sure you are running Rails 6.1.x

=== To test the complete feature including generating a new Rails app
using RPM ===

dnf group install 'Ruby on Rails'
rails new app --skip-bundle && cd app
rails s

* Go to http://127.0.0.1:3000/ and make sure you are running Rails 6.1.x

== User Experience ==
* New version of Ruby on Rails (6.1) available
* The most significant Rails 6.1 features:
** Multi-DB Improvements
** Horizontal Sharding
** Strict Loading Associations
** Delegated Types
** Destroy Associations Async
** Error Objects
** Active Storage Improvements
** Disallowed Deprecation Support
* Please also note:
** The classic Autoloader is Deprecated

== Dependencies ==
* There are several packages, which depends on Ruby on Rails framework.
* These needs to be surely updated:
** (none)
* Following gems don't support Rails 6.1 right now and would be broken
by the update:
** (none)
* As Rails requir

Re: koji buildsystem changes

[Kevin Fenzi]

On Thu, Dec 17, 2020 at 10:40:24AM +0100, Pavel Raiskup wrote:
> On Sunday, December 13, 2020 11:02:53 PM CET Kevin Fenzi wrote:
> > * Finally releng is looking at establishing a sidetag cleanup policy. 
> > A reminder that sidetags should be short lived and only created when
> > needed. koji must generate buildroot repos for every single sidetag.
> > ( You can list all your sidetags with 'fedpkg list-side-tags --mine' )
> 
> I'm just curious what's the most expensive thing for Koji to implement
> side-tags, I'd expect something like:
> 
> - the repositories are cloned (recursively hardlinked/symlinked?)
> - the override package is added
> - then createrepo_c is run

I haven't closely looked, but I am pretty sure it's the createrepo_c
calls. Not that they take that long, but that there has to be one for
every single buildroot change. ie, if I build foo in rawhide, as soon as
it lands in the f34 tag, the ~90 f34 side tags all have to run newrepo
tasks. Repeat many many many times a day. 

> In Copr we don't have to clone the repositories, but we have to run the
> createrepo_c after each build.  In the past the bottleneck used to be
> the createrepo_c run (recursive walk through all the packages in larger
> repositories).
> 
> If Koji suffers from the same problem, perhaps you could take a look at
> the new createrepo_c option `--recycle-pkglist` - the createrepo_c costs
> almost nothing then (matter of just reading and later writing the xml
> metadata).

That would work for the simple case of an updated package, but it
wouldn't work for new packages added would it? I suppose we could tell
people if they need to use a new package in their sidetag to delete and
recreate it? Not sure how much hassle that would be.

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

Re: koji buildsystem changes

[Kevin Fenzi]

On Thu, Dec 17, 2020 at 10:17:45AM +0100, Pavel Raiskup wrote:
> On Wednesday, December 16, 2020 8:25:50 PM CET Kevin Fenzi wrote:
> > On Tue, Dec 15, 2020 at 10:54:07AM +0100, Miroslav Suchý wrote:
> > >   
> > > https://github.com/rpm-software-management/mock/wiki/Feature-container-for-bootstrap
> > > which is still fresh feature - just one year old :) And so far not 
> > > enabled in Koji.
> > > 
> > > When *this* will be enabled in Koji, we can finally boost the RPM
> > > development to levels previously unimaginable. :)
> > 
> > Yeah, we should discuss how to manage and land this. Ideally there would
> > be a lot of CI/QA/Gating on the image, and we would have easy ways to
> > roll back to a known good one in case. 
> 
> Sounds good!  Likely we'd need an image for each chroot and arch.  Where
> can we start? :)

Still a lot of things to ponder here... 

I think it would be important to maintain the ability for users to build
things locally with mock and have them 'close' to what it is in koji.
That would I guess involve publishing all the bootstrap images and
getting mock to be able to download the right ones for the branch/arch.

CI/Gating/testing on the container(s).

Way for releng to go back to older container(s). 

Way for releng to go to newer/force regeneration of container(s). 

koji adjustments: way to record whats in the container/what container it
was. What does it mean for koji's srpm groups? 

What does this mean for reproducability? Do we keep all containers ever
used for bootstrap so we can duplucate builds? Do we just keep a way to
recreate them?

Could we just re-use the fedora minimal container? I guess not, but it
would be nice if we could. 

Also, I am guessing this all works with nspawn, we are (still) using old
chroot, we would have to move to nspawn first right? (which we need to
do anyhow). 

I'm sure I'll think of more. :) 

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

Re: What is the most time consuming task for you as packager?

[Kevin Fenzi]

On Wed, Dec 16, 2020 at 03:56:25PM -0500, Neal Gompa wrote:
...snip...
> > > What I'd really like would be a "test mass rebuild" process, where a
> > > prospective package is uploaded and everything that depends on it is
> > > automatically rebuilt (ideally after creating the dependency graph so
> > > each individual package doesn't get rebuilt until its dependencies are
> > > finished building).
> > >
> > > Creating the dependency graph by hand is fairly tedious, but maybe I'm
> > > missing an automated way. The point of creating that graph is to avoid
> > > wasting time and power doing and redoing builds that will fail until
> > > something else has been built (which is the problem with mock's
> > > --chain command, if I understand correctly).
> > >
> > > Once I have that graph, I use Make to control the process, because it
> > > handles the dependency graph, as well as parallelism, and not
> > > rebuilding things unnecessarily.
> >
> > Yeah, all this ^
> >
> 
> So I've written tools for doing this, and Igor has written tools for
> doing this, but it seems like people think that this is "impossible"
> and so the effort goes nowhere despite several PoCs.
> 
> If we're interested in this again for real this time, I could try to
> dig out my old code for it, but we might be better off just pulling
> out Koschei's code and turning it into something that Koji's
> chain-build command and Mock's --chain option use to sort through
> package sets and build them correctly.

Can you expand on which 'this' you mean? Getting the build
order/dependency graph? Or a tool to use that to rebuild everything and
tell you what failed? or ?

I don't think you can ever be 100% on dependency graph/build order,
because there's sometimes bootstraps or loops in there. :(

Anyhow I would love to be able to locally build a new library and run
'fedpkg does-it-blend foo.src.rpm' and have it tell me exaclty what
other packages that breaks. 

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Fabio Valentini]

On Thu, Dec 17, 2020 at 8:06 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
>
>
> == Summary ==
> This change should enable an opt-in spec file preprocessor in Fedora
> infrastructure for the benefit of packagers. The preprocessor allows
> some very neat tricks that were impossible before, for example
> generate changelog and release automatically from git metadata or pack
> the entire dist-git repository into an rpm-source tarball (effectively
> allowing unpacked repos to live in DistGit).

As far as I can tell, this is the third implementation of generated
changelogs ... did the autorelease / autochangelog work that was even
already deployed in staging not go anywhere?

> == Owner ==
> * Name: [[User:clime| Michal Novotný]]
> * Email: cl...@fedoraproject.org
>
>
> == Detailed Description ==
>
> There is a recently added feature into mock:
> [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocessor
> the rpkg preprocessor] which, if enabled, introduces an intermediate
> step just before srpm building. This step consists of running the spec
> file through a text preprocessing engine that includes an already
> present library of macros designed specifically for rpm spec file
> generation from git metadata. This library is called
> [https://docs.pagure.org/rpkg-util/v3/macro_reference.html
> rpkg-macros]. The macros there allow packagers to have their
> `%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
> automatically generated from dist-git repository data and metadata.
> The library can be easily extended in future to support more packager
> use-cases or even a completely new library can be developed that
> doesn't look at git metadata at all and instead, for example, analyses
> already present tarball content to render spec file based on upstream
> information. This doesn't mean it will happen but the framework is
> generic enough to support that. There is also support for user-defined
> macros that are loaded on-demand from a file placed alongside the
> package sources, maintained by packager. This feature wouldn't be
> enabled by this change from start but it's an example of freedom that
> the preprocessing framework is able to provide. Enabling this change
> should be very easy, basically adding:
>
> 
> config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
> 
>
> into mock configuration of Koji builders and using at least mock 2.7.
> Some very minor change may be also needed in Koji regarding the spec
> file lookup.
>
> Even if the change is enabled on the infrastructure level like this,
> the packager will still need to opt-in to use the preprocessor. The
> opting-in is done by placing `rpkg.conf` file into the package
> top-level directory with the following content:
>
> 
> [rpkg]
> preprocess_spec = True
> 
>
> When this is done by a packager, the preprocessor will be finally
> enabled for the given package.
>
> Alongside, there is an ongoing work to add the preprocessor support
> into the `rpkg` python library so that a packager can easily work with
> the spec files containing the preprocessor (rpkg) macros:
> https://pagure.io/rpkg/pull-request/530
>
> The macros are supported since epel6 until the most latest Fedora
> (preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The
> spec preprocessing step in mock happens in a target chroot just before
> the srpm build.
>
>
> == Benefit to Fedora ==
>
> This change offers solution to some long-standing issues in Fedora
> around packaging (i.e. automatic release and changelog generation)
> while also offering some interesting future options (for example
> unpacked dist-git repos). The big advantage of this approach is that
> it is explicit. Spec file stays the source of truth and by looking
> inside one, you will be able to determine how the text will expand for
> a certain git repository state.

What does "unpacked dist-git repos" mean? Is this a euphemism for source-git?

> == Scope ==
> * Proposal owners:
> For the very basic support, probably a small patch in Koji is needed
> to be able to lookup not only `.spec` files but also `.spec.rpkg`
> files (the `.spec.rpkg` extension explicitly states that the spec file
> is a template). Also the `rpmdevtools/rpmdev-bumpspec` script should
> be tweaked to be compatible with spec files using the macros.

Is the Change owner going to submit patches for fedpkg and rpmdevtools?

> * Other developers:
> Some optional help with `rpmdevtools/rpmdev-bumpspec` changes would be 
> welcome.

rpmdev-bumpspec is a tangled mess of spaghetti code and I'd rather not
touch it or make it even more complicated.
I also think this can't be optional. releng uses rpmdev-bumpspec as
part of scripted mass rebuilds, so it must work with all packages.

> * Release engineering: [https://pagure.io/releng/issue/9910 #9910] (a
> check of an impact with Release Engineering is needed)
> Enabling the rpkg_preprocessor plugin in moc

Re: What is the most time consuming task for you as packager?

[Kevin Fenzi]

On Thu, Dec 17, 2020 at 03:26:47PM +0100, Vít Ondruch wrote:
> > Sadly we do not have the amount of disk space needed for that. Koschei
> > fills up our koji partition regularly. The partition has a 100TB HARD
> > limit and between koschei, ELN and regular update rebuilds we bounce off
> > it multiple times a release. Then when we try to garbage collect all
> > those we regularly end up with koji outages.. which then pile up a whole
> > bunch of new ones which have to be garbage collected.
> > 
> > For longer koschei builds we would need to do this in a different
> > resources than what we have.
> 
> 
> I understand, but if the garbage collection initially removed everything
> except logs, that would help tremendously.

Huh. It's supposed to be working this way now. 

After 1 day the rpms are removed. 
After 7 days the logs are removed. 

Non koschei scratch builds (both logs and rpms) are kept for 14 days. 

Would keeping the logs for 14 days help?
Or is it not somehow doing that?

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Neal Gompa]

On Thu, Dec 17, 2020 at 3:15 PM Fabio Valentini  wrote:
>
> On Thu, Dec 17, 2020 at 8:06 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> > infrastructure for the benefit of packagers. The preprocessor allows
> > some very neat tricks that were impossible before, for example
> > generate changelog and release automatically from git metadata or pack
> > the entire dist-git repository into an rpm-source tarball (effectively
> > allowing unpacked repos to live in DistGit).
>
> As far as I can tell, this is the third implementation of generated
> changelogs ... did the autorelease / autochangelog work that was even
> already deployed in staging not go anywhere?
>

That effort, as far as I'm aware, was waiting for the staging Koji to
be restored to finish the work, which it was recently. I believe those
developers are interested in getting this in place in production Koji.

> > == Owner ==
> > * Name: [[User:clime| Michal Novotný]]
> > * Email: cl...@fedoraproject.org
> >
> >
> > == Detailed Description ==
> >
> > There is a recently added feature into mock:
> > [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocessor
> > the rpkg preprocessor] which, if enabled, introduces an intermediate
> > step just before srpm building. This step consists of running the spec
> > file through a text preprocessing engine that includes an already
> > present library of macros designed specifically for rpm spec file
> > generation from git metadata. This library is called
> > [https://docs.pagure.org/rpkg-util/v3/macro_reference.html
> > rpkg-macros]. The macros there allow packagers to have their
> > `%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
> > automatically generated from dist-git repository data and metadata.
> > The library can be easily extended in future to support more packager
> > use-cases or even a completely new library can be developed that
> > doesn't look at git metadata at all and instead, for example, analyses
> > already present tarball content to render spec file based on upstream
> > information. This doesn't mean it will happen but the framework is
> > generic enough to support that. There is also support for user-defined
> > macros that are loaded on-demand from a file placed alongside the
> > package sources, maintained by packager. This feature wouldn't be
> > enabled by this change from start but it's an example of freedom that
> > the preprocessing framework is able to provide. Enabling this change
> > should be very easy, basically adding:
> >
> > 
> > config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
> > 
> >
> > into mock configuration of Koji builders and using at least mock 2.7.
> > Some very minor change may be also needed in Koji regarding the spec
> > file lookup.
> >
> > Even if the change is enabled on the infrastructure level like this,
> > the packager will still need to opt-in to use the preprocessor. The
> > opting-in is done by placing `rpkg.conf` file into the package
> > top-level directory with the following content:
> >
> > 
> > [rpkg]
> > preprocess_spec = True
> > 
> >
> > When this is done by a packager, the preprocessor will be finally
> > enabled for the given package.
> >
> > Alongside, there is an ongoing work to add the preprocessor support
> > into the `rpkg` python library so that a packager can easily work with
> > the spec files containing the preprocessor (rpkg) macros:
> > https://pagure.io/rpkg/pull-request/530
> >
> > The macros are supported since epel6 until the most latest Fedora
> > (preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The
> > spec preprocessing step in mock happens in a target chroot just before
> > the srpm build.
> >
> >
> > == Benefit to Fedora ==
> >
> > This change offers solution to some long-standing issues in Fedora
> > around packaging (i.e. automatic release and changelog generation)
> > while also offering some interesting future options (for example
> > unpacked dist-git repos). The big advantage of this approach is that
> > it is explicit. Spec file stays the source of truth and by looking
> > inside one, you will be able to determine how the text will expand for
> > a certain git repository state.
>
> What does "unpacked dist-git repos" mean? Is this a euphemism for source-git?
>
> > == Scope ==
> > * Proposal owners:
> > For the very basic support, probably a small patch in Koji is needed
> > to be able to lookup not only `.spec` files but also `.spec.rpkg`
> > files (the `.spec.rpkg` extension explicitly states that the spec file
> > is a template). Also the `rpmdevtools/rpmdev-bumpspec` script should
> > be tweaked to be compatible with spec files using the macros.
>
> Is the Change owner going to submit patches for fedpkg and rpmdevtools?
>
> > * Other developers:
> > Some optional help with `rpmdevtools/

Re: What is the most time consuming task for you as packager?

[Fabio Valentini]

On Thu, Dec 17, 2020 at 9:08 PM Kevin Fenzi  wrote:
>
> On Wed, Dec 16, 2020 at 03:56:25PM -0500, Neal Gompa wrote:
> ...snip...
> > So I've written tools for doing this, and Igor has written tools for
> > doing this, but it seems like people think that this is "impossible"
> > and so the effort goes nowhere despite several PoCs.
> >
> > If we're interested in this again for real this time, I could try to
> > dig out my old code for it, but we might be better off just pulling
> > out Koschei's code and turning it into something that Koji's
> > chain-build command and Mock's --chain option use to sort through
> > package sets and build them correctly.
>
> Can you expand on which 'this' you mean? Getting the build
> order/dependency graph? Or a tool to use that to rebuild everything and
> tell you what failed? or ?
>
> I don't think you can ever be 100% on dependency graph/build order,
> because there's sometimes bootstraps or loops in there. :(
>
> Anyhow I would love to be able to locally build a new library and run
> 'fedpkg does-it-blend foo.src.rpm' and have it tell me exaclty what
> other packages that breaks.

As Miro mentioned, I've also developed scripts to handle this "does
this update break anything" for the Stewardship / Java SIG, because -
at least at first - we didn't have big enough egos / enough confidence
to just push updates to rawhide without testing excessively them
first:
https://github.com/fedora-stewardship/fedora-stewardship.github.io/blob/master/scripts/review_pr.py

This first builds (one or more) packages from src.fpo dist-git forks
that were prepared for PRs in COPR, recursively or non-recursively
queries dependent packages for all of them, and rebuilds them in COPR.
Assuming that there's a copr-cli command for querying build successes,
they could be compared with the latest status of those packages in
koschei, and have it print new build failures. Right now, I compare
the results manually.

Would something like this fit your definition of "does-it-blend" script?

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Miro Hrončok]

On 12/17/20 8:05 PM, Ben Cotton wrote:

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


== Summary ==
This change should enable an opt-in spec file preprocessor in Fedora
infrastructure for the benefit of packagers. The preprocessor allows
some very neat tricks that were impossible before, for example
generate changelog and release automatically from git metadata or pack
the entire dist-git repository into an rpm-source tarball (effectively
allowing unpacked repos to live in DistGit).

...

I'd very much like to understand the impact of this on the following:


1) Provenpackagers doing mass spec changes/updates.

2) Provenpackagers and/or RelEngs doing (targeted) mass rebuilds.

3) Packagers doing `fedpkg local` builds.

5) Our downstreams rebuilding from dist-git.

4) Packages needed to be installed in buildSRPMFromSCM mock and/or Koji host.


I'd also like to know, where exactly is the spec file pre-processed. Is it in 
the buildSRPMFromSCM mock, or on the Koji host?



It feels like this will open a can of worms and I don't think the benefits are 
worth it. IMHO we should strive to make RPM specs more flexible instead of 
adding another layer on top of it. But I admit that I don't have all the 
information yet.


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

Re: How to troubleshoot aarch64 and s390x?

[Kevin Fenzi]

On Thu, Dec 17, 2020 at 07:32:59AM -0600, Richard Shaw wrote:
> I'm working on building the new openexr package but the unit tests are
> failing but just on aarch64 and s390x.
> 
> The aarch64 test instances are down due to the infra move and there are
> none for s390x.

Yeah, sorry about that. ;( 

> What's the best way to work around this? An emulated aarch64 install of
> Fedora?

So for aarch64, perhaps we can (at least until we get our machines back
online) spin up some amazon instances as test machines. 
Filed a ticket for that: https://pagure.io/fedora-infrastructure/issue/9541

s390x is harder. ;( I see downthread someone pointed to a ibm place that
can provide them. I wish we could.

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[James Cassell]

On Thu, Dec 17, 2020, at 2:05 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> 
> 
> == Summary ==
> This change should enable an opt-in spec file preprocessor in Fedora
> infrastructure for the benefit of packagers. The preprocessor allows
> some very neat tricks that were impossible before, for example
> generate changelog and release automatically from git metadata or pack
> the entire dist-git repository into an rpm-source tarball (effectively
> allowing unpacked repos to live in DistGit).
> 

I'm skeptical. If it does pass, I'd insist on having the non-processed spec and 
any required supporting files in the SRPM.

Does this relate in any way to the magic done by rdopkg dist-git <-> source-git 
translation? Their approach seems very good to me, but might not exactly 
overlap here.

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

Re: How to troubleshoot aarch64 and s390x?

[Dan Horák]

On Thu, 17 Dec 2020 12:23:27 -0800
Kevin Fenzi  wrote:

> On Thu, Dec 17, 2020 at 07:32:59AM -0600, Richard Shaw wrote:
> > I'm working on building the new openexr package but the unit tests are
> > failing but just on aarch64 and s390x.
> > 
> > The aarch64 test instances are down due to the infra move and there are
> > none for s390x.
> 
> Yeah, sorry about that. ;( 
> 
> > What's the best way to work around this? An emulated aarch64 install of
> > Fedora?
> 
> So for aarch64, perhaps we can (at least until we get our machines back
> online) spin up some amazon instances as test machines. 
> Filed a ticket for that: https://pagure.io/fedora-infrastructure/issue/9541
> 
> s390x is harder. ;( I see downthread someone pointed to a ibm place that
> can provide them. I wish we could.

I believe we can get a dedicated VM for Fedora, so it could be listed at
the "test resources" wiki page. It's on my to-do list. For individual
needs please contact me.


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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[James Szinger]

On Thu, 17 Dec 2020 14:05:40 -0500
Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> 
> == Summary ==
> This change should enable an opt-in spec file preprocessor in Fedora
> infrastructure for the benefit of packagers. The preprocessor allows
> some very neat tricks that were impossible before, for example
> generate changelog and release automatically from git metadata or pack
> the entire dist-git repository into an rpm-source tarball (effectively
> allowing unpacked repos to live in DistGit).
> 
> == User Experience ==
> This change is intended for packagers. It should help to make a bit of
> their work easier and offer them some new interesting options.

This change proposal does affect users.  The User Experience section
needs to answer the following:

1. How does this affect users who download, maybe modify, and rebuild
the SRPM?  Can they continue to use rpmbuid and mock as they have
been?  Does the SRPM contain the pre-processed or post-processed spec
file?

2. How does this affect users who download the spec file from
src.fedoraproject.org?  Do they have the tools to build the RPM?  How
much harder is it?

Please remember that this is Free Software and the spec files are
useful for a broader audience than just the Fedora packagers.

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

Re: koji buildsystem changes

[Pavel Raiskup]

On Thursday, December 17, 2020 8:55:48 PM CET Kevin Fenzi wrote:
> On Thu, Dec 17, 2020 at 10:40:24AM +0100, Pavel Raiskup wrote:
> > On Sunday, December 13, 2020 11:02:53 PM CET Kevin Fenzi wrote:
> > > * Finally releng is looking at establishing a sidetag cleanup policy. 
> > > A reminder that sidetags should be short lived and only created when
> > > needed. koji must generate buildroot repos for every single sidetag.
> > > ( You can list all your sidetags with 'fedpkg list-side-tags --mine' )
> > 
> > I'm just curious what's the most expensive thing for Koji to implement
> > side-tags, I'd expect something like:
> > 
> > - the repositories are cloned (recursively hardlinked/symlinked?)
> > - the override package is added
> > - then createrepo_c is run
> 
> I haven't closely looked, but I am pretty sure it's the createrepo_c
> calls. Not that they take that long, but that there has to be one for
> every single buildroot change. ie, if I build foo in rawhide, as soon as
> it lands in the f34 tag, the ~90 f34 side tags all have to run newrepo
> tasks. Repeat many many many times a day. 

We'd have to check the createrepo arguments, but according to that ^^^
most probably there's some other useful optimization used in
Koji+createrepo.  Otherwise Koji wouldn't be able to run createrepo
hundreds of times per day (subsequent, serial runs?) on such a large repo
like rawhide is.

> > In Copr we don't have to clone the repositories, but we have to run the
> > createrepo_c after each build.  In the past the bottleneck used to be
> > the createrepo_c run (recursive walk through all the packages in larger
> > repositories).
> > 
> > If Koji suffers from the same problem, perhaps you could take a look at
> > the new createrepo_c option `--recycle-pkglist` - the createrepo_c costs
> > almost nothing then (matter of just reading and later writing the xml
> > metadata).
> 
> That would work for the simple case of an updated package, but it
> wouldn't work for new packages added would it? I suppose we could tell
> people if they need to use a new package in their sidetag to delete and
> recreate it? Not sure how much hassle that would be.

It shouldn't matter (i think) if the package is updated, or newly added.
Createrepo needs still to be explicitly told what metadata for which concrete
RPMs must be added (--pkglist), and what removed (--exclude).

Anyway, based on the numbers above it looks like e.g. `--skip-stat --update` is
used in Koji, and the --pkglist is carefully maintained by Koji.  I guess that
--recycle-pkglist wouldn't help here.

Side note, before I was really curious why parsing and then writing of
medium sized (~20MB) repodata [1] takes about ~20s [2] with '--workers 8'
[3] (mostly no I/O).  But I forgot that the repo is compressed, so it's
about 155MB of XML metadata.  Considering that only decompression and
compression takes together ~3 seconds on my laptop, and that we still
generate the sqlite database files in Copr (I don't know the overhead of
this), it's likely there's not much space for performance optimizations.
Certainly not some low hanging fruit..

[1] 
https://copr-be.cloud.fedoraproject.org/results/iucar/cran/fedora-32-x86_64/repodata/
[2] 
https://download.copr.fedorainfracloud.org/results/iucar/cran/fedora-32-x86_64/01839153-R-CRAN-yotover/build.log.gz
[3] 
https://pagure.io/copr/copr/blob/4e6881371075c37bf1eddc4b09bd7e29162c4d89/f/backend/run/copr-repo#_133-134

Pavel



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

Re: How to troubleshoot aarch64 and s390x?

[Paul Whalen]

- Original Message -
> I tried qemu using this link but it's wildly out of date...
> 
> https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU
> 

Updated for Fedora 33. 

> I updated the url for Fedora 33 but it still fails...
> 
> sudo virt-install --name f33-aarch64-urlinst --ram 4096 --arch aarch64 --boot
> uefi --disk size=8 --location
> https://download.fedoraproject.org/pub/fedora/linux/releases/33/Server/x86_64/os
> 

Updating the url to aarch64 should work. 

sudo virt-install --name f33-aarch64-urlinst --ram 4096 --arch aarch64 --boot 
uefi --disk size=8 --location 
https://download.fedoraproject.org/pub/fedora/linux/releases/33/Server/aarch64/os/

> Starting install...
> Retrieving file vmlinuz... | 11 MB 00:00:00
> Retrieving file initrd.img... | 75 MB 00:00:01
> Allocating 'f33-aarch64-urlinst.qcow2' | 8.0 GB 00:00:00
> Removing disk 'f33-aarch64-urlinst.qcow2' | 0 B 00:00:00
> ERROR Remote peer disconnected
> Domain installation does not appear to have been successful.
> If it was, you can restart your domain by running:
> virsh --connect qemu:///system start f33-aarch64-urlinst
> otherwise, please restart your installation.
> 
> Thanks,
> Richard
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Miro Hrončok]

On 12/17/20 9:21 PM, Miro Hrončok wrote:

On 12/17/20 8:05 PM, Ben Cotton wrote:

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


== Summary ==
This change should enable an opt-in spec file preprocessor in Fedora
infrastructure for the benefit of packagers. The preprocessor allows
some very neat tricks that were impossible before, for example
generate changelog and release automatically from git metadata or pack
the entire dist-git repository into an rpm-source tarball (effectively
allowing unpacked repos to live in DistGit).

...

3) Packagers doing `fedpkg local` builds.


Also, generally, fedpkg parses the NEVR from the spec when performing various 
operations. How would that work here?


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

Re: koji buildsystem changes

[Pavel Raiskup]

On Thursday, December 17, 2020 9:04:42 PM CET Kevin Fenzi wrote:
> On Thu, Dec 17, 2020 at 10:17:45AM +0100, Pavel Raiskup wrote:
> > On Wednesday, December 16, 2020 8:25:50 PM CET Kevin Fenzi wrote:
> > > On Tue, Dec 15, 2020 at 10:54:07AM +0100, Miroslav Suchý wrote:
> > > >   
> > > > https://github.com/rpm-software-management/mock/wiki/Feature-container-for-bootstrap
> > > > which is still fresh feature - just one year old :) And so far not 
> > > > enabled in Koji.
> > > > 
> > > > When *this* will be enabled in Koji, we can finally boost the RPM
> > > > development to levels previously unimaginable. :)
> > > 
> > > Yeah, we should discuss how to manage and land this. Ideally there would
> > > be a lot of CI/QA/Gating on the image, and we would have easy ways to
> > > roll back to a known good one in case. 
> > 
> > Sounds good!  Likely we'd need an image for each chroot and arch.  Where
> > can we start? :)
> 
> Still a lot of things to ponder here... 
> 
> I think it would be important to maintain the ability for users to build
> things locally with mock and have them 'close' to what it is in koji.
> That would I guess involve publishing all the bootstrap images and
> getting mock to be able to download the right ones for the branch/arch.

Having it published would be nice.  OTOH even now the local mock build is
far from what is done in Koji (as far as --enablerepo=local isn't used).
And bootstrap can "only" affect the target buildroot installation
transactions.

> CI/Gating/testing on the container(s).

Dnf/RPM should be tested, since that's the only thing used there.

> Way for releng to go back to older container(s). 
> 
> Way for releng to go to newer/force regeneration of container(s). 

Sure, as symlink to the latest build repo exists, there could be the 'latest'
image tag?

> koji adjustments: way to record whats in the container/what container it was.
> What does it mean for koji's srpm groups? 

I guess not much?  The groups should be installed to build chroot from bootstrap
chroot.

> What does this mean for reproducability? Do we keep all containers ever used
> for bootstrap so we can duplucate builds? Do we just keep a way to recreate
> them?

This should normally bring a really low amount of non-determinism, because mock
only uses the DNF and RPM (and it's deps) from the bootstrap.

How long back could we get if we wanted to restore some random Koji builder
state from the past, namely to get the installed host dnf/rpm stack that was
used for a concrete build?

> Could we just re-use the fedora minimal container? I guess not, but it
> would be nice if we could. 

I'm not sure, is the 'fedora:33' the minimal one?  That is used now.
But it would be good if 'dnf-plugins-core' was present ... so we could build a
thin layer on top of that.

> Also, I am guessing this all works with nspawn, we are (still) using old
> chroot, we would have to move to nspawn first right? (which we need to do
> anyhow). 

No, fortunately this has nothing to do with nspawn.  The --use-bootstrap-image
is yet another way to prepopulate bootstrap chroot contents -- and mock can both
do chroot() or call systemd-nspawn instead to execute 'dnf' command inside the
bootstrap.

> I'm sure I'll think of more. :) 

Yeah, not a trivial thing.

Pavel

> kevin
> 



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

Re: How to troubleshoot aarch64 and s390x?

[Sérgio Basto]

On Thu, 2020-12-17 at 07:32 -0600, Richard Shaw wrote:
> I'm working on building the new openexr package but the unit tests
> are failing but just on aarch64 and s390x.

Since is testing building, wh not mock with forcearch [1]  ? 

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/CFJOJP7B5RPSSRSY7B5DITO4N2FBNB55/


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

Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)

[Troy Dawson]

On Wed, Dec 9, 2020 at 3:52 PM Miro Hrončok  wrote:
>
> On 12/9/20 7:44 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault
> >
> > ...
> > * Policies and guidelines: N/A (not a System Wide Change)
>
> Should there be an update of:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/
>
> ?
>
Working on the Node.js documentation right now.
I currently haven't tested any of the bundling with javascript
(js-...) packages.  So I am not confident in writing documentation for
them.
It looks like there is only 20 left in Fedora.  I am thinking of
putting them in on our exceptions list, along with binary nodejs
libraries.  So we would get to them at a future time.

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

Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)

[Troy Dawson]

On Wed, Dec 9, 2020 at 3:42 PM Miro Hrončok  wrote:
>
> On 12/9/20 9:56 PM, Troy Dawson wrote:
> > On Wed, Dec 9, 2020 at 11:21 AM Miro Hrončok  wrote:
> >>
> >> On 12/9/20 7:44 PM, Ben Cotton wrote:
> >>> == How To Test ==
> >>>
> >>> * Install all nodejs libraries in Fedora 33.  Try to update to Fedora 34.
> >>
> >> What is the plan wrt Obsoletes of the removed packages?
> >>
> >> --
> >> Miro Hrončok
> >> --
> >
> > We do not plan on obsoleting them.
> > Obsoleting them has the potential to break third party software.
> > dnf should also clean things up by seeing that the dependencies of an
> > upgraded package have gone away.
> > If dnf misses it, these are libraries, not binaries.  If nothing is
> > using them, they just take up some disk space.  If a user really wants
> > to clean them up, those types of users usually have their favorite
> > ways of doing so.
>
> I worry about this specific case: There are several JS libraries unbundled in
> python-notebook. Due to RPM/DNF limitations, they can onyl be unbondled if the
> JS packages are obsoleted:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1787079#c8
>
> I can definitively make sure the relevant packages are obsoleted by
> fedora-obsolete-packages but that opens a can of worm, because if only some
> removed packages are obsoleted, other removed packages will block the upgrade
> path to Fedora 34/35. And they will need to be obsoleted as well.
>
> I rutinelly spend several hours each release to figure out and fix upgrade 
> path
> issues by obsoleting packages via fedora-obsolete-packages. I'd like some help
> with this by the change owners / NodeJS SIG. Can I count on that?
>
The js- (javascript) packages are something I haven't tested with my
bundling scripts and thus do not feel confident in documenting and
removing them at this time.   There are currently only 20 of them, and
I think we will add them to our exceptions list, along with the binary
nodejs libraries.  Hopefully by F35 or F36 we will be able to get to
them.

But other than those, yes, I believe the Nodejs sig can help with
upgrade path issues and obsoleting packages that need to be obsoleted.

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

Re: How to troubleshoot aarch64 and s390x?

[Richard Shaw]

Just to (not quite) wrap up this thread...

Someone reached out to me privately to provide some hardware that can run
Fedora aarch64, so once I receive that my immediate need should be
satisfied assuming the same problem is plaguing it and s390x which is an
assumption at this point.

I'll take a look at the IBM community stuff while I'm on holiday after this
week which may also be a stop gap.

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

Re: How to troubleshoot aarch64 and s390x?

[Richard Shaw]

On Thu, Dec 17, 2020 at 4:07 PM Sérgio Basto  wrote:

> On Thu, 2020-12-17 at 07:32 -0600, Richard Shaw wrote:
>
> I'm working on building the new openexr package but the unit tests are
> failing but just on aarch64 and s390x.
>
>
> Since is testing building, wh not mock with forcearch [1]  ?
>

Because I completely forgot about that thread. We should
definitely document it somewhere easy to find.

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

On Thu, 17 Dec 2020 at 21:15, Fabio Valentini  wrote:
>
> On Thu, Dec 17, 2020 at 8:06 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> > infrastructure for the benefit of packagers. The preprocessor allows
> > some very neat tricks that were impossible before, for example
> > generate changelog and release automatically from git metadata or pack
> > the entire dist-git repository into an rpm-source tarball (effectively
> > allowing unpacked repos to live in DistGit).
>
> As far as I can tell, this is the third implementation of generated
> changelogs ... did the autorelease / autochangelog work that was even
> already deployed in staging not go anywhere?

I know about it but I don't have much information about its current state.

>
> > == Owner ==
> > * Name: [[User:clime| Michal Novotný]]
> > * Email: cl...@fedoraproject.org
> >
> >
> > == Detailed Description ==
> >
> > There is a recently added feature into mock:
> > [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocessor
> > the rpkg preprocessor] which, if enabled, introduces an intermediate
> > step just before srpm building. This step consists of running the spec
> > file through a text preprocessing engine that includes an already
> > present library of macros designed specifically for rpm spec file
> > generation from git metadata. This library is called
> > [https://docs.pagure.org/rpkg-util/v3/macro_reference.html
> > rpkg-macros]. The macros there allow packagers to have their
> > `%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
> > automatically generated from dist-git repository data and metadata.
> > The library can be easily extended in future to support more packager
> > use-cases or even a completely new library can be developed that
> > doesn't look at git metadata at all and instead, for example, analyses
> > already present tarball content to render spec file based on upstream
> > information. This doesn't mean it will happen but the framework is
> > generic enough to support that. There is also support for user-defined
> > macros that are loaded on-demand from a file placed alongside the
> > package sources, maintained by packager. This feature wouldn't be
> > enabled by this change from start but it's an example of freedom that
> > the preprocessing framework is able to provide. Enabling this change
> > should be very easy, basically adding:
> >
> > 
> > config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
> > 
> >
> > into mock configuration of Koji builders and using at least mock 2.7.
> > Some very minor change may be also needed in Koji regarding the spec
> > file lookup.
> >
> > Even if the change is enabled on the infrastructure level like this,
> > the packager will still need to opt-in to use the preprocessor. The
> > opting-in is done by placing `rpkg.conf` file into the package
> > top-level directory with the following content:
> >
> > 
> > [rpkg]
> > preprocess_spec = True
> > 
> >
> > When this is done by a packager, the preprocessor will be finally
> > enabled for the given package.
> >
> > Alongside, there is an ongoing work to add the preprocessor support
> > into the `rpkg` python library so that a packager can easily work with
> > the spec files containing the preprocessor (rpkg) macros:
> > https://pagure.io/rpkg/pull-request/530
> >
> > The macros are supported since epel6 until the most latest Fedora
> > (preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The
> > spec preprocessing step in mock happens in a target chroot just before
> > the srpm build.
> >
> >
> > == Benefit to Fedora ==
> >
> > This change offers solution to some long-standing issues in Fedora
> > around packaging (i.e. automatic release and changelog generation)
> > while also offering some interesting future options (for example
> > unpacked dist-git repos). The big advantage of this approach is that
> > it is explicit. Spec file stays the source of truth and by looking
> > inside one, you will be able to determine how the text will expand for
> > a certain git repository state.
>
> What does "unpacked dist-git repos" mean? Is this a euphemism for source-git?

In this context, it means a dist-git repository with the original
upstream sources placed directly in it (i.e. the sources are not
packed in a tarball but they are directly present in a dist-git repo).
To remind us of our collective knowledge, there can be multiple
variants of this. One of them is that the spec file is placed next to
the unpacked upstream sources (the simplest one). Then there are
approaches that try to keep the upstream (unpacked) sources and the
spec file separate - i.e. they can be in different branches, different
repos, different subdirectories - each of these use-cases can be
supported by the preprocessing engine.

But I would say this is an advance

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

...snip...

>
> I'm generally not excited about this, as it adds a huge layer of
> indirection and a ton of extra magic that makes it harder to decipher
> what is happening.
>

I don't think there is any magic in it. Everything is clearly
documented and every expansion clearly defined and also intuitive.

If something changes spec files "behind my back" - that I would call
magic but If a packager explicitly states: "Here, in this place in the
spec file, I want this particular dynamic snippet to be expanded",
then I think that is very transparent. Especially, if some other
person looks at the spec file, he/she will know something will happen
with the spec file and also what it will be (perhaps after quickly
checking the docs).

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

On Thu, 17 Dec 2020 at 21:34, James Cassell  wrote:
>
>
> On Thu, Dec 17, 2020, at 2:05 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> > infrastructure for the benefit of packagers. The preprocessor allows
> > some very neat tricks that were impossible before, for example
> > generate changelog and release automatically from git metadata or pack
> > the entire dist-git repository into an rpm-source tarball (effectively
> > allowing unpacked repos to live in DistGit).
> >
>
> I'm skeptical. If it does pass, I'd insist on having the non-processed spec 
> and any required supporting files in the SRPM.

It would be possible to specify the spec template as an rpm Source so
it would get included into the resulting srpm as well.

>
> Does this relate in any way to the magic done by rdopkg dist-git <-> 
> source-git translation? Their approach seems very good to me, but might not 
> exactly overlap here.

There is some overlap in the goal (allow people to work with upstream
sources when convenient) but the method to achieve it is slightly
different. The approach suggested here is more declarative while the
rdopkg's approach is more imperative.

Basically, with rdopkg, you do the upstream<->downstream conversion on
the client and then just push the results to the server. With the
preprocessing engine, you define the conversion in a spec file and
then let the infrastructure (i.e. builders) do the work just before
srpm is built.

We can go into more details. There probably is some inaccuracy in what
I have just said (but tried my best to explain the difference as I see
it).

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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Gergely Gombos via devel]

Hi,

I'm the packager of pulseaudio-module-bluetooth-freeworld in rpmfusion. That 
library provides AAC, LDAC and aptX for Bluetooth users.

What seems to be the case is that pipewire can already be built with
aptX and ldac support: 
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/meson.build#L31-32

There's a lot of work going on to improve Bluetooth support, which is great!

We already have libldac in Fedora, and here's a review request for libopenaptx: 
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
(I appreciate if some of you could take a look)

This way, we could update the pipewire package to build with these in Fedora 
and have first-class support for these codecs.

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

Re: How to troubleshoot aarch64 and s390x?

[Michael Catanzaro]

On Thu, Dec 17, 2020 at 4:35 pm, Richard Shaw  
wrote:
I'll take a look at the IBM community stuff while I'm on holiday 
after this week which may also be a stop gap.


It's probably limited to a short trial period or something. You'll 
probably find it lot easier to work with Dan Horak instead. ;)


Michael

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

On Thu, 17 Dec 2020 at 22:04, James Szinger  wrote:
>
> On Thu, 17 Dec 2020 14:05:40 -0500
> Ben Cotton  wrote:
>
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> > infrastructure for the benefit of packagers. The preprocessor allows
> > some very neat tricks that were impossible before, for example
> > generate changelog and release automatically from git metadata or pack
> > the entire dist-git repository into an rpm-source tarball (effectively
> > allowing unpacked repos to live in DistGit).
> >
> > == User Experience ==
> > This change is intended for packagers. It should help to make a bit of
> > their work easier and offer them some new interesting options.
>
> This change proposal does affect users.  The User Experience section
> needs to answer the following:

Well, the users here are still packagers here no? I thought the "User"
in the title means "end user" who shouldn't be affected by it. Maybe
Ben can clarify this.

>
> 1. How does this affect users who download, maybe modify, and rebuild
> the SRPM?  Can they continue to use rpmbuid and mock as they have
> been?  Does the SRPM contain the pre-processed or post-processed spec
> file?

They can use mock if the preprocessing will be enabled for the
respective chroots where it is enabled in Koji/Fedora.
They can't directly use rpmbuild for those packages that contain the
macros. But they can use rpkg/fedpkg to do the work.
Or preprocess spec first and then use rpmbuild. I am aware this is a
negative point of this change.
While having an option to use rpmbuild directly to build srpm/rpm from
a dist-git repo is nice, I would say that fedpkg or mock are the main
interfaces to do this.
I know this answer won't satisfy everyone.

>
> 2. How does this affect users who download the spec file from
> src.fedoraproject.org?  Do they have the tools to build the RPM?  How
> much harder is it?

The tools will be available. It should be no-work if a person uses
fedpkg or mock. Otherwise, if they really use bare rpmbuild, they will
need to modify their scripts to use fedpkg/mock.

Or they can use preproc first to render the template and then pass it
to rpmbuild. I also planned to do a simple wrapper called
'"preproc-rpmbuild" which would do that while otherwise providing the
same command-line interface as rpmbuild does.

>
> Please remember that this is Free Software and the spec files are
> useful for a broader audience than just the Fedora packagers.

Right, we also use the (CentOS) spec files in a company where I
currently work at.

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Matthew Miller]

On Fri, Dec 18, 2020 at 12:24:10AM +0100, clime wrote:
> It would be possible to specify the spec template as an rpm Source so
> it would get included into the resulting srpm as well.

Yeah I was thinking the spec file templating system could automatically add
the original spec as Source where N is one higher than the highest
existing source file.


-- 
Matthew Miller

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Matthew Miller]

On Fri, Dec 18, 2020 at 12:51:49AM +0100, clime wrote:
> > This change proposal does affect users.  The User Experience section
> > needs to answer the following:
> Well, the users here are still packagers here no? I thought the "User"
> in the title means "end user" who shouldn't be affected by it. Maybe
> Ben can clarify this.

It _is_ meant to refer to end users, but we have a lot of highly technical
end users and sysadmins who might want to download and build source RPMs. So
the answers to these questions seem like reasonable things to add.


-- 
Matthew Miller

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

On Thu, 17 Dec 2020 at 21:23, Miro Hrončok  wrote:
>
> On 12/17/20 8:05 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
> >
> >
> > == Summary ==
> > This change should enable an opt-in spec file preprocessor in Fedora
> > infrastructure for the benefit of packagers. The preprocessor allows
> > some very neat tricks that were impossible before, for example
> > generate changelog and release automatically from git metadata or pack
> > the entire dist-git repository into an rpm-source tarball (effectively
> > allowing unpacked repos to live in DistGit).
> ...
>
> I'd very much like to understand the impact of this on the following:
>
>
> 1) Provenpackagers doing mass spec changes/updates.

If the mass spec change/update doesn't involve an rpkg macro, then
there is no difference.

If it does involve an rpkg macro, then we should directly change the
macro so that the spec file gets rendered correctly according to the
latest state-of-art.

That probably means notifying affected packagers first but for a
proven packager it is less work.

There is also an option that a packager would specify the macros
version with which to evaluate the spec file in `rpkg.conf` file. In
that case, he would need to bump that version first so that the
updated macro gets used. Not sure if something like this would be
needed but this would prevent any changes in spec file unless the
packager wants them on his/her own.

>
> 2) Provenpackagers and/or RelEngs doing (targeted) mass rebuilds.

There should be no impact here. If the source git repo stays the same,
then the same srpm as for a previous build will be produced.

>
> 3) Packagers doing `fedpkg local` builds.

This PR makes sure `fedpkg local` will work:
https://pagure.io/rpkg/pull-request/530 if preprocessing is enabled.

There is a bit of additional work to open a PR for fedpkg to parse
rpkg.conf file if it is present in a dist-git repo and enable
preprocessing if it is enabled there in the file. It's just a few
lines that I plan to write when I get feedback on the `rpkg` pull
request.

>
> 5) Our downstreams rebuilding from dist-git.

If they use mock or fedpkg, there should be no impact. If they use
bare rpmbuild, it will no longer work and some changes will be needed.

>
> 4) Packages needed to be installed in buildSRPMFromSCM mock and/or Koji host.

I am not sure if I understand correctly here so maybe this will need
some more explanation.

But the preprocessing needs some additional tooling to get installed
that I tried to minimize. Basically:
preproc, rpkg-macros, rpm-git-tag-sort, libgit2, git-core are the main
packages needed to run the preprocessing.

These packages get installed into the target chroot where the srpm is
also built afterwards. They are installed
only if preprocessing is enabled.

>
>
> I'd also like to know, where exactly is the spec file pre-processed. Is it in
> the buildSRPMFromSCM mock, or on the Koji host?

It is preprocessed in the target chroot, i.e. in the same environment
where rpmbuild -bs is called afterwards.

>
>
> It feels like this will open a can of worms and I don't think the benefits are
> worth it. IMHO we should strive to make RPM specs more flexible instead of
> adding another layer on top of it. But I admit that I don't have all the
> information yet.

I think something like this is needed whether it is in rpm or in
rpkg/mock. I think having implemented it on an upper layer than rpm is
not such a huge deal.

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

On Fri, 18 Dec 2020 at 00:58, Matthew Miller  wrote:
>
> On Fri, Dec 18, 2020 at 12:24:10AM +0100, clime wrote:
> > It would be possible to specify the spec template as an rpm Source so
> > it would get included into the resulting srpm as well.
>
> Yeah I was thinking the spec file templating system could automatically add
> the original spec as Source where N is one higher than the highest
> existing source file.

I mean something like that could be done but I need to avoid parsing
spec file from within the rpkg macros because when the rpkg macros are
being evaluated, there is not-yet a valid rpm spec file to be parsed.
That means I cannot get the highest  used Source number in the context
where I would like to get it...but I think this is just one line that
doesn't really need to be dynamically generated because it shouldn't
change.

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Japheth Cleaver]

On 12/17/2020 3:59 PM, Matthew Miller wrote:

On Fri, Dec 18, 2020 at 12:51:49AM +0100, clime wrote:

This change proposal does affect users.  The User Experience section
needs to answer the following:

Well, the users here are still packagers here no? I thought the "User"
in the title means "end user" who shouldn't be affected by it. Maybe
Ben can clarify this.

It _is_ meant to refer to end users, but we have a lot of highly technical
end users and sysadmins who might want to download and build source RPMs. So
the answers to these questions seem like reasonable things to add.



   They can use mock if the preprocessing will be enabled for the
   respective chroots where it is enabled in Koji/Fedora.
   They can't directly use rpmbuild for those packages that contain the
   macros. But they can use rpkg/fedpkg to do the work.
   Or preprocess spec first and then use rpmbuild. I am aware this is a
   negative point of this change.
   While having an option to use rpmbuild directly to build srpm/rpm from
   a dist-git repo is nice, I would say that fedpkg or mock are the main
   interfaces to do this.
   I know this answer won't satisfy everyone.


Not to mention the many folks who use Fedora .src.rpms as a starting 
point for EL-derivatives, or other RPM-based distros. Every time a 
Rawhide (or Fedora) SRPM fails to compile because of a 
non-backwards-compatible change, another frustrated sysadmin sheds a 
single tear.


Deprecating rpmbuild is a major change.

-jc

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[clime]

On Fri, 18 Dec 2020 at 02:27, Japheth Cleaver  wrote:
>
> On 12/17/2020 3:59 PM, Matthew Miller wrote:
>
> On Fri, Dec 18, 2020 at 12:51:49AM +0100, clime wrote:
>
> This change proposal does affect users.  The User Experience section
> needs to answer the following:
>
> Well, the users here are still packagers here no? I thought the "User"
> in the title means "end user" who shouldn't be affected by it. Maybe
> Ben can clarify this.
>
> It _is_ meant to refer to end users, but we have a lot of highly technical
> end users and sysadmins who might want to download and build source RPMs. So
> the answers to these questions seem like reasonable things to add.
>
>
> They can use mock if the preprocessing will be enabled for the
> respective chroots where it is enabled in Koji/Fedora.
> They can't directly use rpmbuild for those packages that contain the
> macros. But they can use rpkg/fedpkg to do the work.
> Or preprocess spec first and then use rpmbuild. I am aware this is a
> negative point of this change.
> While having an option to use rpmbuild directly to build srpm/rpm from
> a dist-git repo is nice, I would say that fedpkg or mock are the main
> interfaces to do this.
> I know this answer won't satisfy everyone.
>
>
> Not to mention the many folks who use Fedora .src.rpms as a starting point 
> for EL-derivatives, or other RPM-based distros. Every time a Rawhide (or 
> Fedora) SRPM fails to compile because of a non-backwards-compatible change, 
> another frustrated sysadmin sheds a single tear.
>
> Deprecating rpmbuild is a major change.

I wouldn't call it "deprecating rpmbuild". That's certainly not at all
my intention.

As a side-point, I think the cases where bare rpmbuild is used to
build an rpm/srpm from a dist-git repo are rather limited because you
probably need to first download sources from lookaside cache so you
probably need fedpkg/rpkg/centpkg/rfpkg or a similar dedicated tool.
These tools then offer the `srpm` and `local` commands so It would
make sense to rather use these commands or mock for subsequent
srpm/rpm building.

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

Re: Proposal: drop "Test installation media" from live media

[przemek klosowski via devel]

On 12/17/20 10:04 AM, Marius Schwarz wrote:

Am 17.12.20 um 14:35 schrieb Stephen John Smoogen:
Right, but it's not automatic, and requires an existing known-good 
system, which is the actual 'root of trust' here. This cannot be 
assumed about a flash drive, which is why the automatic image check 
is hard. 


Speaking from Security pov, it's not hard, it's impossible. The 
attacker can sign everything with it's own cert and putting that into 
the image itself. Way easier is it to remove the check for a valid sig 
and always return "true" is asked for a match, as any root kit will do.


In a secure boot environment, the root of trust is the motherboard 
firmware, which has the keys of the next boot step. In Fedora land, this 
next step is the shim, which was signed by Microsoft because their key 
is on practically all existing hardware. As I said, the shim would have 
to be smart enough to securely (TLS) retrieve the signature, and check 
the boot image.


https://docs.fedoraproject.org/en-US/Fedora/18/html-single/UEFI_Secure_Boot_Guide/index.html#sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Keys

In this scenario, the attacker cannot fake the key, because both UEFI 
and the shim will stop the boot if their measurements fail to check out,


I don't know if the UEFI/shim combo can be enhanced to do those things, 
though...

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

Re: Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)

[Tom Stellard]

On 12/17/20 11:05 AM, Ben Cotton wrote:

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


== Summary ==
This change should enable an opt-in spec file preprocessor in Fedora
infrastructure for the benefit of packagers. The preprocessor allows
some very neat tricks that were impossible before, for example
generate changelog and release automatically from git metadata or pack
the entire dist-git repository into an rpm-source tarball (effectively
allowing unpacked repos to live in DistGit).

== Owner ==
* Name: [[User:clime| Michal Novotný]]
* Email: cl...@fedoraproject.org


== Detailed Description ==

There is a recently added feature into mock:
[https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preprocessor
the rpkg preprocessor] which, if enabled, introduces an intermediate
step just before srpm building. This step consists of running the spec
file through a text preprocessing engine that includes an already
present library of macros designed specifically for rpm spec file
generation from git metadata. This library is called
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros]. The macros there allow packagers to have their
`%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
automatically generated from dist-git repository data and metadata.
The library can be easily extended in future to support more packager
use-cases or even a completely new library can be developed that
doesn't look at git metadata at all and instead, for example, analyses
already present tarball content to render spec file based on upstream
information. This doesn't mean it will happen but the framework is
generic enough to support that. There is also support for user-defined
macros that are loaded on-demand from a file placed alongside the
package sources, maintained by packager. This feature wouldn't be
enabled by this change from start but it's an example of freedom that
the preprocessing framework is able to provide. Enabling this change
should be very easy, basically adding:


config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True


into mock configuration of Koji builders and using at least mock 2.7.
Some very minor change may be also needed in Koji regarding the spec
file lookup.

Even if the change is enabled on the infrastructure level like this,
the packager will still need to opt-in to use the preprocessor. The
opting-in is done by placing `rpkg.conf` file into the package
top-level directory with the following content:


[rpkg]
preprocess_spec = True


When this is done by a packager, the preprocessor will be finally
enabled for the given package.

Alongside, there is an ongoing work to add the preprocessor support
into the `rpkg` python library so that a packager can easily work with
the spec files containing the preprocessor (rpkg) macros:
https://pagure.io/rpkg/pull-request/530



Is this pull request needed so that the preprocessor will run if I do 
`fedpkg mockbuild` or does fedpkg already do this if the preprocessor is 
enabled?


-Tom

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

Fedora-Cloud-33-20201218.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

Passed openQA tests: 6/7 (x86_64), 6/7 (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