Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)

[Matthew Almond via devel]

On Mon, 2021-04-12 at 23:10 +0200, Lennart Poettering wrote:
> Or in other words: packaging metadata are sources too. If they change
> (and a version bump constitutes a change) the output might change,
> and
> that's expected. What's key really is that the only things that can
> effect generated output are the build/packaging environment and the
> sources, but not parameters outside of that, such as the actual
> wallclock.

The main way that packaging "interferes" with the source is when
patches are applied - the original timestamp of a tarball (for example)
isn't complete enough to use for $SOURCE_DATE_EPOCH. That's fair.

> 
> > My concern centers around the Copy on Write (CoW) use case - when
> > packages are updated, some files changes, and some may stay the
> > same.
> > Where they are the same, we can save I/O and possibly download time
> > long term.
> 
> Reproducible builds the way they are defined do not address such
> file-level CoW optimization so much. They do address CoW optimization
> on a package level much more however: i.e. the same package build
> will
> have the same files in them, no matter what.
> 
> Or to say this differently: if you want reproducible to work the way
> ou think it should work, you'd have to start by convincing the
> uptream
> maintainers to kill $SOURCE_DATE_EPOCH and similar concepts, but good
> luck with that.

I think we should be careful to de-couple these two things. Just
because $SOURCE_DATE_EPOCH is likely to affect a lot of binaries is not
proof that all binaries will. I remain concerned that this proposal
forces the issue and for every single version of every single ELF
binary *must* be different, even if they really didn't change. The
pattern I see is more automation and faster, smaller release cycles,
and this forcing downloads and writes of binaries that really didn't
change their code.

I have just thought of an alternative proposition: for ELF objects (and
ELF objects only): rpm could automatically, and systematically record
the metadata in an xattr. This would work on images without rpmdb,
works on most filesystem types, be serialized in archives. Most
interestingly this could be implemented as an rpm plugin, and would
work retroactively for packages that were built before this proposal.
It could also be made to work for other packaging systems, and the
tooling that reads it wouldn't need to know the original packaging
system.

Thoughts?

Matthew

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

Re: Stepping down as Fedora Jam maintainer

[Erich Eickmeyer]

On Monday, April 12, 2021 7:52:24 AM PDT Matthew Miller wrote:
> On Sun, Apr 11, 2021 at 11:38:40PM -, JT Pennington wrote:
> 
> > I'd like to volunteer to pick up the Fedora Jam project and maintain it.
> 
> 
> Awesome -- thanks JT!
> 
> -- 
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

Thanks for stepping-up, JT!

JT is someone I'm very familiar with, as we have even shared a hotel room at 
Linux Fest Northwest back in 2014. If there's anybody who has capable hands 
about handling a spin/lab, it's him.

I've gone-ahead and handed-over the two Fedora Jam pagure repos to him, and 
I'm sure he'll be able to take-on the rest in due time.

I'll be sticking around as a resource to help in whatever way I can, and I'm 
even keeping some packages so that I can stay familiar with RPM packaging.

Thanks for doing this, JT! Let me know if you need anything.

Erich

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

New Fedora Developer Portal release

[Pavel Valena]

Hello,

long overdue release has landed to: https://developer.fedoraproject.org/

Please check the updated website!

Most notable changes (in no particular order):

 - Removed search, due to plugin incompatability [1].
 - Updated Ruby install page [2].
 - Nodejs page update [3].
 - New Web Application page [4].
 - Almost all Python pages updated [5].
 - Docker pages updated [6].

Detailed info is available on our ML [*].

Any feedback is welcome!

[1] https://github.com/developer-portal/website/pull/104
[2] 
https://developer.fedoraproject.org/tech/languages/ruby/ruby-installation.html
[3] https://developer.fedoraproject.org/tech/languages/nodejs/nodejs.html
[4] https://developer.fedoraproject.org/start/sw/web-app/about.html
[5] 
https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html
[6] https://developer.fedoraproject.org/tools/docker/docker-installation.html
[*] 
https://lists.fedoraproject.org/archives/list/developer-por...@lists.fedoraproject.org/thread/NKYSVEDIZYFTJXINAU7WFNZLQE5XR33A/

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

Re: Grub 2 protected packages

[Javier Martinez Canillas]

On Mon, Apr 12, 2021 at 11:51 PM Chris Murphy  wrote:
>
> On Mon, Apr 12, 2021 at 4:01 AM Neal Gompa  wrote:
> >
> > Ideally, we should change to a system similar to what openSUSE does
> > and have the RPMs install bootloader content into /usr, then execute a
> > helper program that copies things over to /boot and configures things
> > properly (we should still have the files %ghosted in /boot, though!).
> > This makes it much more straightforward to support updating or
> > downgrading bootloader files when needed, which is why openSUSE does
> > it this way to support full system snapshots with rollback
> > functionality.
>
> That's the intent of bootupd.
> https://github.com/coreos/bootupd/
>
> And also include 'grub2-install' on BIOS systems to ensure the
> embedded instance is also kept up to date. And a possible future
> feature is EFI system partition syncing in the case of multiple ESPs.

Agreed that packages shouldn't install anything in /boot or update the
bootloader images (e.g: the embedding gap for x86 legacy BIOS, PReP
partition for ppc64le, etc) and instead all that setup logic should be
done by bootupd.

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

Re: [Ocaml-devel] Re: Need feedback on ocaml-atd review request

[Jerry James]

On Fri, Apr 9, 2021 at 5:33 PM Michel Alexandre Salim
 wrote:
> ok, the camlzip OPAM module still uses Makefiles to install, and rather
> than trying to make sure I override the right environment variables to
> get it to build correctly, I figured I'd rather fix opam2rpm to support
> Zip archives:
>
> https://pagure.io/opam2rpm/pull-request/6

Thank you!  I have merged the pull request.  I want to point out, too,
that camlzip is already packaged as ocaml-zip.  Also, I recently
announced a dependency visualizer, named depict, and included an
example of visualizing the dependencies of Infer.  See
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OEBTONN7ONDN42LMZTQD3D2X7W5XTXCM/

I will take a look at your review request for ocaml-atd.  Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Grub 2 protected packages

[Chris Murphy]

On Mon, Apr 12, 2021 at 4:01 AM Neal Gompa  wrote:
>
> Ideally, we should change to a system similar to what openSUSE does
> and have the RPMs install bootloader content into /usr, then execute a
> helper program that copies things over to /boot and configures things
> properly (we should still have the files %ghosted in /boot, though!).
> This makes it much more straightforward to support updating or
> downgrading bootloader files when needed, which is why openSUSE does
> it this way to support full system snapshots with rollback
> functionality.

That's the intent of bootupd.
https://github.com/coreos/bootupd/

And also include 'grub2-install' on BIOS systems to ensure the
embedded instance is also kept up to date. And a possible future
feature is EFI system partition syncing in the case of multiple ESPs.


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

Re: Stepping down as Fedora Jam maintainer

[JT Pennington]

Erich, you want to transfer those two pagure repos over to me?  
You should still have my email from back in the day, but let me know if there's 
anything info you want to pass long on things you were working on, current 
issues you were aware of, things that were requested or planned, etc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)

[Lennart Poettering]

On Mo, 12.04.21 20:40, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> On Mon, 2021-04-12 at 15:46 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
>
> Putting packaging info into a binary guarantees that each successive
> package containing ELF binaries will not contain exactly the same
> binaries, even if there are no changes.
>
> Now, what I just wrote there is predicated on "reproducible builds"
> where the same source (including deps, headers) and the same toolchain
> produce the same output. This may or may not be a thing. My concern is
> that we completely eliminate the possibility of binaries being
> unchanged.

I think this is a misunderstanding how reproducible builds are
supposed to work. For example, consider $SOURCE_DATE_EPOCH as defined
here:

https://reproducible-builds.org/specs/source-date-epoch/

It's expressly defined to be used as the source timestamp when that
source timestamp is included in build output. It also also expressly
documented to be a value initialized from the packaging Changelog
timestamps. Or in other words: the way the reproducible builds project
understands their own stuff it's absolutely OK to generate different
output on package rebuilds that change the package versions.

Or in other words: packaging metadata are sources too. If they change
(and a version bump constitutes a change) the output might change, and
that's expected. What's key really is that the only things that can
effect generated output are the build/packaging environment and the
sources, but not parameters outside of that, such as the actual
wallclock.

> My concern centers around the Copy on Write (CoW) use case - when
> packages are updated, some files changes, and some may stay the same.
> Where they are the same, we can save I/O and possibly download time
> long term.

Reproducible builds the way they are defined do not address such
file-level CoW optimization so much. They do address CoW optimization
on a package level much more however: i.e. the same package build will
have the same files in them, no matter what.

Or to say this differently: if you want reproducible to work the way
ou think it should work, you'd have to start by convincing the uptream
maintainers to kill $SOURCE_DATE_EPOCH and similar concepts, but good
luck with that.

Lennart

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

Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)

[Lennart Poettering]

On Mo, 12.04.21 16:14, David Malcolm (dmalc...@redhat.com) wrote:

> So I want to push back on the idea that a single package can be
> associated with a coredump, or be the one responsible for the crash:
> any or all of the ELF objects linked into the process could be at
> fault.

The example in the feature page shows how we handle this: you'll see
the packaging metadata of all involved ELF objects in coredumpctl's
output. i.e. we should be nicely covered on this, and we are fully
aware that the "main" ELF objects is the culprit of crashes only in a
fraction of cases.

Lennart

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

Planned Outage - teams.fedoraproject.org - 2021-04-13 08:30 UTC

[Kevin Fenzi]

Planned Outage - teams.fedoraproject.org - 2021-04-13 08:30 UTC

There will be an outage starting at 2021-04-13 08:30 UTC,
which will last approximately 1 hour.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-04-13 08:30 UTC'

Reason for outage:

A number of updates and patches are pending on our taiga instance 
(teams.fedoraproject.org). During this time the service may be down or 
unresponsive.

Affected Services:

https://teams.fedoraproject.org

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/9867

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.


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

Planned Outage - teams.fedoraproject.org - 2021-04-13 08:30 UTC

[Kevin Fenzi]

Planned Outage - teams.fedoraproject.org - 2021-04-13 08:30 UTC

There will be an outage starting at 2021-04-13 08:30 UTC,
which will last approximately 1 hour.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-04-13 08:30 UTC'

Reason for outage:

A number of updates and patches are pending on our taiga instance 
(teams.fedoraproject.org). During this time the service may be down or 
unresponsive.

Affected Services:

https://teams.fedoraproject.org

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/9867

Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.


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

Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)

[Matthew Almond via devel]

On Mon, 2021-04-12 at 15:46 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects

Putting packaging info into a binary guarantees that each successive
package containing ELF binaries will not contain exactly the same
binaries, even if there are no changes.

Now, what I just wrote there is predicated on "reproducible builds"
where the same source (including deps, headers) and the same toolchain
produce the same output. This may or may not be a thing. My concern is
that we completely eliminate the possibility of binaries being
unchanged.

My concern centers around the Copy on Write (CoW) use case - when
packages are updated, some files changes, and some may stay the same.
Where they are the same, we can save I/O and possibly download time
long term.

My recommendation here is to (continue to?) log build ids, and resolve
remotely if you don't have an rpmdb to consult. Build ids are opaque
and meaningless to end users, but end users aren't the target. My
expectation is that any data collection around crashes needs to
aggregate, and build ids are good enough to identify packages, even
after the fact.

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

Re: Packaging new Compiz 0.9 version

[Artem Tim]

Good to know, thanks for answer. Can we package then separate compat version 
with 0.9 version? Still WIP build [1] but fully working. And already filed some 
bugs [2] upstream.

[1] https://copr.fedorainfracloud.org/coprs/atim/compiz0.9/
[2] https://bugs.launchpad.net/compiz/+bug/1923481
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)

[David Malcolm]

On Mon, 2021-04-12 at 15:46 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
> 
> == Summary ==
> All binaries (executables and shared libraries) are annotated with an
> ELF
> note that identifies the rpm distributing this file.
> 
> == Owner ==
> * Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
> * Email: zbys...@in.waw.pl
> * Name: Lennart Poettering
> * Email: mzsrq...@0pointer.net
> 
> 
> == Detailed Description ==
> See [https://github.com/systemd/systemd/issues/18433 systemd issue
> #18433]
> for discussion and implementation proposals.
> 
> Programs crash. And when they do, they dump core, and we want to tell
> the
> user which package, including the version, caused the failure.

This might be better as:
  "which packages [plural] could have been responsible for the failure"

I used to maintain the Fedora "python" package, and I kept receiving
bugzilla reports assigned to the "python" package filed via ABRT,
because /usr/bin/python had crashed.  It was almost never
/usr/bin/python at fault: it's a tiny 4k executable linked to a much
larger libpython.so (in a different subpackage) - but generally that
wasn't at fault either: the python extension API exposes the insides of
the virtual machine and its objects directly, and it's very easy for a
buggy extension to corrupt something in the process, sometimes at some
remove from where the segfault finally crashes the process down.

I tried writing scripts to help update the bugs to use the correct bz
component.  In theory you could look at the deepest point in the
callstack, but it might e.g. be an assertion failure handler in a
shared library, rather than the "real" site of the crash.  Or some
object could have become corrupted at some point long before the crash
actually fires, so the blame can't be diagnosed just from the final
callstack.

Dealing with this deluge of misfiled bug reports is what got me
interested in static analysis and on maintaining GCC itself, fwiw.

So I want to push back on the idea that a single package can be
associated with a coredump, or be the one responsible for the crash:
any or all of the ELF objects linked into the process could be at
fault.

Hope this is constructive (sorry, the wording in the proposal touched a
nerve for me!)

Dave

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

F35 Change: Package information on ELF objects (System-Wide Change proposal)

[Ben Cotton]

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

== Summary ==
All binaries (executables and shared libraries) are annotated with an ELF
note that identifies the rpm distributing this file.

== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@in.waw.pl
* Name: Lennart Poettering
* Email: mzsrq...@0pointer.net


== Detailed Description ==
See [https://github.com/systemd/systemd/issues/18433 systemd issue #18433]
for discussion and implementation proposals.

Programs crash. And when they do, they dump core, and we want to tell the
user which package, including the version, caused the failure. ELF note
`.note.package` will be added to specify package nevra. By embedding the
this information directly in the binary object, package nevra is
immediately available from a core dump.

=== Existing system: `.note.gnu.build-id` ===

We already have build-ids: every ELF object has a `.note.gnu.build-id`
note, and given a core file, we can read the build-id and look it up in the
rpm database (`dnf repoquery --whatprovides debuginfo(build-id) = …`) to
map it to a package name.
Build-ids are unique and compact and very generic and work as expected in
general. But they have some downsides:
* build-ids are not very informative for users. Before the build-id is
converted back to the appropriate package, it's completely opaque.
* build-ids require a working rpm database or an internet connection to map
to the package name.

Three important cases:
* minimal containers: the rpm database is not installed in the containers.
The information about build-ids needs to be stored externally, so package
name information is not available immediately, but only after offline
processing. The new note doesn't depend on the rpm db in any way.
* handling of a core from a container, where the container and host have
different distros
* self-built and external packages: unless a lot of care is taken to keep
access to the debuginfo packages, this information may be lost. The new
note is available even if the repository metadata gets lost. Users can
easily provide equivalent information in a format that makes sense in their
own environment. It should work even when rpms and debs and other formats
are mixed, e.g. during container image creation.

=== New system: `.note.package` ===

The new note is created and propagated similarly to `.note.gnu.build-id`.
The difference is that we inject the information about package nevra from
the build system.

The implementation is very simple: `%{build_ldflags}` are extended with a
command to insert a custom note as a separate section in an ELF object. See
[https://github.com/systemd/package-notes/blob/main/hello.spec hello.spec]
for an example. This is done in the default macros, so all packages that
use the prescribed link flags will be affected.

The note is a compat json string. This allows the format to be trivially
extensible (new fields can be added at will), easy to process (json is
extremely popular and parsers are widely available). Using a single field
is more space-efficient. With multiple fields the padding and alignment
requirements cause unnecessary overhead.

The system was designed with cross-distro collaboration and is flexible
enough to identify binaries from different packaging formats and build
systems (rpms, debs, custom binaries).

The overhead is about 200 bytes for each ELF object.
If we do this only for executables, then for the whole distro, 5000 × 200 =
1 MB.
If we do it for shared libraries, then the cost will be maybe 4 times
higher.
Precise measurements TBD once we know the final implementation and figure
out the right repoquery magic.

=== Examples ===

$ objdump -s -j .note.package build/libhello.so

build/libhello.so: file format elf64-x86-64

Contents of section .note.package:
 02ec 0400 6300 7e1afeca 46444f00  c...~...FDO.
 02fc 7b227479 7065223a 2272706d 222c226e  {"type":"rpm","n
 030c 616d6522 3a226865 6c6c6f22 2c227665  ame":"hello","ve
 031c 7273696f 6e223a22 302d312e 6665  rsion":"0-1.fc35
 032c 2e783836 5f363422 2c226f73 43706522  .x86_64","osCpe"
 033c 3a226370 653a2f6f 3a666564 6f726170  :"cpe:/o:fedorap
 034c 726f6a65 63743a66 65646f72 613a  roject:fedora:33
 035c 227d "}..



$ readelf --notes build/hello | grep "description data" | sed -e
"s/\s*description data: //g" -e "s/ //g" | xxd -p -r | jq
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to
0x10de
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to
0x10af
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to
0x119f
{
  "type": "rpm",
  "name": "hello",
  "version": "0-1.fc35.x86_64",
  "osCpe": "cpe:/o:fedoraproject:fedora:33"
}



$ coredumpctl info
   PID: 44522 (fsverity)
...
   Package: fsverity-utils/1.3-1
  build-id: ac89bf7175b04d7eec7f6544a923f45be111f0be
   Message: Process 44522 (fsverity) of user 1000 

F35 Change: Package information on ELF objects (System-Wide Change proposal)

[Ben Cotton]

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

== Summary ==
All binaries (executables and shared libraries) are annotated with an ELF
note that identifies the rpm distributing this file.

== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@in.waw.pl
* Name: Lennart Poettering
* Email: mzsrq...@0pointer.net


== Detailed Description ==
See [https://github.com/systemd/systemd/issues/18433 systemd issue #18433]
for discussion and implementation proposals.

Programs crash. And when they do, they dump core, and we want to tell the
user which package, including the version, caused the failure. ELF note
`.note.package` will be added to specify package nevra. By embedding the
this information directly in the binary object, package nevra is
immediately available from a core dump.

=== Existing system: `.note.gnu.build-id` ===

We already have build-ids: every ELF object has a `.note.gnu.build-id`
note, and given a core file, we can read the build-id and look it up in the
rpm database (`dnf repoquery --whatprovides debuginfo(build-id) = …`) to
map it to a package name.
Build-ids are unique and compact and very generic and work as expected in
general. But they have some downsides:
* build-ids are not very informative for users. Before the build-id is
converted back to the appropriate package, it's completely opaque.
* build-ids require a working rpm database or an internet connection to map
to the package name.

Three important cases:
* minimal containers: the rpm database is not installed in the containers.
The information about build-ids needs to be stored externally, so package
name information is not available immediately, but only after offline
processing. The new note doesn't depend on the rpm db in any way.
* handling of a core from a container, where the container and host have
different distros
* self-built and external packages: unless a lot of care is taken to keep
access to the debuginfo packages, this information may be lost. The new
note is available even if the repository metadata gets lost. Users can
easily provide equivalent information in a format that makes sense in their
own environment. It should work even when rpms and debs and other formats
are mixed, e.g. during container image creation.

=== New system: `.note.package` ===

The new note is created and propagated similarly to `.note.gnu.build-id`.
The difference is that we inject the information about package nevra from
the build system.

The implementation is very simple: `%{build_ldflags}` are extended with a
command to insert a custom note as a separate section in an ELF object. See
[https://github.com/systemd/package-notes/blob/main/hello.spec hello.spec]
for an example. This is done in the default macros, so all packages that
use the prescribed link flags will be affected.

The note is a compat json string. This allows the format to be trivially
extensible (new fields can be added at will), easy to process (json is
extremely popular and parsers are widely available). Using a single field
is more space-efficient. With multiple fields the padding and alignment
requirements cause unnecessary overhead.

The system was designed with cross-distro collaboration and is flexible
enough to identify binaries from different packaging formats and build
systems (rpms, debs, custom binaries).

The overhead is about 200 bytes for each ELF object.
If we do this only for executables, then for the whole distro, 5000 × 200 =
1 MB.
If we do it for shared libraries, then the cost will be maybe 4 times
higher.
Precise measurements TBD once we know the final implementation and figure
out the right repoquery magic.

=== Examples ===

$ objdump -s -j .note.package build/libhello.so

build/libhello.so: file format elf64-x86-64

Contents of section .note.package:
 02ec 0400 6300 7e1afeca 46444f00  c...~...FDO.
 02fc 7b227479 7065223a 2272706d 222c226e  {"type":"rpm","n
 030c 616d6522 3a226865 6c6c6f22 2c227665  ame":"hello","ve
 031c 7273696f 6e223a22 302d312e 6665  rsion":"0-1.fc35
 032c 2e783836 5f363422 2c226f73 43706522  .x86_64","osCpe"
 033c 3a226370 653a2f6f 3a666564 6f726170  :"cpe:/o:fedorap
 034c 726f6a65 63743a66 65646f72 613a  roject:fedora:33
 035c 227d "}..



$ readelf --notes build/hello | grep "description data" | sed -e
"s/\s*description data: //g" -e "s/ //g" | xxd -p -r | jq
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to
0x10de
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to
0x10af
readelf: build/hello: Warning: Gap in build notes detected from 0x1091 to
0x119f
{
  "type": "rpm",
  "name": "hello",
  "version": "0-1.fc35.x86_64",
  "osCpe": "cpe:/o:fedoraproject:fedora:33"
}



$ coredumpctl info
   PID: 44522 (fsverity)
...
   Package: fsverity-utils/1.3-1
  build-id: ac89bf7175b04d7eec7f6544a923f45be111f0be
   Message: Process 44522 (fsverity) of user 1000 

Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Frank Ch. Eigler]

Bjorn wrote:

>> https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
>
> The change page lacks a discussion of security implications. An informed
> decision requires answers to questions such as: [...]

Thank you for your questions.  Added a section and placed initial
answers there:

https://fedoraproject.org/wiki/Changes/DebuginfodByDefault#Security_FAQ

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

Re: Orphaned packages looking for new maintainers

[Michael J Gruber]

> portmidi  mjg, orphan, xavierb 0 weeks ago

Taking since I was co-maintaining anyways and maintain a dependency of 
portmidi. Though, anyone is welcome to take over.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packaging new Compiz 0.9 version

[Wolfgang Ulbrich]

The official fedora spin requires compiz-0.88. compiz-0.88 is under active 
development and does perfectly match Mate-desktop.
In the past gnome itself decided not to use compiz in favor of mutter.
As Mate spin owner i am against to update compiz only because of gnome-flash, 
which was never official supported by gnome mainline.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-34-20210412.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp
Minimal raw-xz armhfp

Failed openQA tests: 15/189 (x86_64), 4/127 (aarch64)

New failures (same test not failed in Fedora-34-20210411.n.0):

ID: 853214  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/853214
ID: 853265  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/853265
ID: 853294  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/853294
ID: 853327  Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/853327
ID: 853367  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/853367
ID: 853429  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/853429
ID: 853474  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/853474
ID: 853621  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/853621
ID: 853625  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/853625

Old failures (same test failed in Fedora-34-20210411.n.0):

ID: 853218  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/853218
ID: 853219  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/853219
ID: 853222  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/853222
ID: 853231  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/853231
ID: 853243  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/853243
ID: 853249  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/853249
ID: 853250  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/853250
ID: 853284  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/853284
ID: 853396  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/853396
ID: 853471  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/853471

Soft failed openQA tests: 4/189 (x86_64), 6/127 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-34-20210411.n.0):

ID: 853207  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/853207
ID: 853248  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/853248
ID: 853305  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/853305
ID: 853311  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/853311
ID: 853324  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/853324
ID: 853349  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/853349
ID: 853364  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/853364
ID: 853386  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/853386
ID: 853445  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/853445
ID: 853500  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/853500

Passed openQA tests: 160/189 (x86_64), 94/127 (aarch64)

New passes (same test not passed in Fedora-34-20210411.n.0):

ID: 853251  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/853251
ID: 853331  Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/853331
ID: 853393  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/853393
ID: 853419  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/853419
ID: 853477  Test: aarch64 universal install_kickstart_user_creation@uefi
URL: https://openqa.fedoraproject.org/tests/853477

Skipped non-gating openQA tests: 33 of 316

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.49 to 0.18
Previous test data: https://openqa.fedoraproject.org/tests/852397#downloads
Current test data: 

Re: Orphaned packages looking for new maintainers

[Ankur Sinha]

On Mon, Apr 12, 2021 18:32:52 +0200, Miro Hrončok wrote:
> neuro-sig: openigtlink, ctk

Taken these for the neuro-sig (which had admin access to these already).

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


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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-04-12.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

Add64 orphan   0 weeks ago
CuraEngine-lulzbotorphan   6 weeks ago
ccls  orphan   4 weeks ago
connman   orphan   3 weeks ago
ctk   neuro-sig, orphan1 weeks ago
cura-lulzbot  orphan, spot 6 weeks ago
dssi  orphan   0 weeks ago
dssi-vst  orphan   0 weeks ago
fbreader  orphan   0 weeks ago
fedora-jam-backgroundsorphan   0 weeks ago
fedora-jam-kde-theme  jvlomax, orphan  0 weeks ago
fluidsynth-dssi   orphan   0 weeks ago
freqtweak orphan   0 weeks ago
gnome-desktop alexl, caolanm, fmuellner, gnome-sig,0 weeks ago
  orphan, rhughes
gnome-guitar  orphan   0 weeks ago
grc   orphan   4 weeks ago
gsignond  orphan   4 weeks ago
gsignond-plugin-lastfmorphan   4 weeks ago
gsignond-plugin-mail  orphan   4 weeks ago
gsignond-plugin-oauth orphan   4 weeks ago
gsignond-plugin-sasl  orphan   4 weeks ago
gtk-nodoka-engine orphan   0 weeks ago
harmonyseqorphan   0 weeks ago
hexter-dssi   orphan   0 weeks ago
jackctlmmcorphan   0 weeks ago
jakarta-messaging orphan   5 weeks ago
jboss-el-3.0-api  orphan   5 weeks ago
jboss-jsp-2.3-api orphan   4 weeks ago
jboss-jstl-1.2-apiorphan   4 weeks ago
jboss-servlet-3.1-api orphan   5 weeks ago
jmeters   orphan, tartina  0 weeks ago
kpassgen  orphan   1 weeks ago
lemonpos  orphan   1 weeks ago
libaccounts-glib  orphan   4 weeks ago
libarcus-lulzbot  orphan   6 weeks ago
libinstpatch  orphan   0 weeks ago
libunibreak   orphan   0 weeks ago
lulzbot-marlin-firmware   orphan, spot 6 weeks ago
lv2-c++-tools orphan, tartina  0 weeks ago
lv2-fabla orphan, tartina  0 weeks ago
lv2-ll-pluginsorphan, tartina  0 weeks ago
lv2-mdaEPiano orphan, tartina  0 weeks ago
lv2-newtonatororphan, tartina  0 weeks ago
lv2-sorcerorphan, tartina  0 weeks ago
lv2-swh-plugins   orphan, tartina  0 weeks ago
lv2-vocoder-plugins   orphan, tartina  0 weeks ago
mailman   orphan   1 weeks ago
maven-verifiermizdebsk, orphan  

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b26bce013a   
chromium-89.0.4389.90-3.el8
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-58127424cd   
perl-Net-Netmask-2.0001-1.el8
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4ceb7b7897   
libopenmpt-0.5.7-1.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-125be1ea97   
perl-Net-CIDR-Lite-0.22-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-aa018d2e2a   
clamav-0.103.2-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d8aad094e9   
singularity-3.7.3-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-781b228611   
seamonkey-2.53.7-3.el8


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

centpkg-0.6.1-1.el8
python-pefile-2019.4.18-5.el8

Details about builds:



 centpkg-0.6.1-1.el8 (FEDORA-EPEL-2021-7c0547932f)
 CentOS utility for working with dist-git

Update Information:

- Latest upstream - Add bash completion support - Add manpage support

ChangeLog:

* Thu Apr  8 2021 Carl George  - 0.6.1-1
- Latest upstream
- Add bash completion support
- Add manpage support
* Tue Mar 30 2021 Carl George  - 0.5.1-3
- Fix epel7/python2 compatibility




 python-pefile-2019.4.18-5.el8 (FEDORA-EPEL-2021-db8b7b5d6d)
 Python module for working with Portable Executable files

Update Information:

Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

ChangeLog:



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

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

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

Failed openQA tests: 17/189 (x86_64), 11/127 (aarch64)

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

ID: 852843  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/852843
ID: 852868  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/852868
ID: 852884  Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/852884
ID: 853124  Test: aarch64 universal install_repository_http_variation@uefi
URL: https://openqa.fedoraproject.org/tests/853124

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

ID: 852847  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/852847
ID: 852848  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/852848
ID: 852851  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/852851
ID: 852860  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/852860
ID: 852865  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/852865
ID: 852872  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/852872
ID: 852878  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/852878
ID: 852879  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/852879
ID: 852913  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/852913
ID: 852983  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/852983
ID: 853025  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/853025
ID: 853074  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/853074
ID: 853081  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/853081
ID: 853096  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/853096
ID: 853097  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/853097
ID: 853100  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/853100
ID: 853103  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/853103
ID: 853111  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/853111
ID: 853112  Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/853112
ID: 853129  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/853129
ID: 853130  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/853130
ID: 853132  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/853132
ID: 853142  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/853142
ID: 853143  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/853143

Soft failed openQA tests: 46/127 (aarch64), 63/189 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 853004  Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/853004

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

ID: 852828  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/852828
ID: 852829  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/852829
ID: 852835  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/852835
ID: 852836  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/852836
ID: 852840  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/852840
ID: 852842  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/852842
ID: 852844  Test: x86_64 Server-dvd-iso 

[Bug 1948301] perl-Graphics-TIFF-10 is available

[bugzilla]

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



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

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


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

[Bug 1948241] perl-perlfaq-5.20210411 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-4583f61395 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-4583f61395`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-4583f61395

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


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

[Bug 1948301] perl-Graphics-TIFF-10 is available

[bugzilla]

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



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

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


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

[Bug 1948241] perl-perlfaq-5.20210411 is available

[bugzilla]

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



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

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


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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-04-12.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

Add64 orphan   0 weeks ago
CuraEngine-lulzbotorphan   6 weeks ago
ccls  orphan   4 weeks ago
connman   orphan   3 weeks ago
ctk   neuro-sig, orphan1 weeks ago
cura-lulzbot  orphan, spot 6 weeks ago
dssi  orphan   0 weeks ago
dssi-vst  orphan   0 weeks ago
fbreader  orphan   0 weeks ago
fedora-jam-backgroundsorphan   0 weeks ago
fedora-jam-kde-theme  jvlomax, orphan  0 weeks ago
fluidsynth-dssi   orphan   0 weeks ago
freqtweak orphan   0 weeks ago
gnome-desktop alexl, caolanm, fmuellner, gnome-sig,0 weeks ago
  orphan, rhughes
gnome-guitar  orphan   0 weeks ago
grc   orphan   4 weeks ago
gsignond  orphan   4 weeks ago
gsignond-plugin-lastfmorphan   4 weeks ago
gsignond-plugin-mail  orphan   4 weeks ago
gsignond-plugin-oauth orphan   4 weeks ago
gsignond-plugin-sasl  orphan   4 weeks ago
gtk-nodoka-engine orphan   0 weeks ago
harmonyseqorphan   0 weeks ago
hexter-dssi   orphan   0 weeks ago
jackctlmmcorphan   0 weeks ago
jakarta-messaging orphan   5 weeks ago
jboss-el-3.0-api  orphan   5 weeks ago
jboss-jsp-2.3-api orphan   4 weeks ago
jboss-jstl-1.2-apiorphan   4 weeks ago
jboss-servlet-3.1-api orphan   5 weeks ago
jmeters   orphan, tartina  0 weeks ago
kpassgen  orphan   1 weeks ago
lemonpos  orphan   1 weeks ago
libaccounts-glib  orphan   4 weeks ago
libarcus-lulzbot  orphan   6 weeks ago
libinstpatch  orphan   0 weeks ago
libunibreak   orphan   0 weeks ago
lulzbot-marlin-firmware   orphan, spot 6 weeks ago
lv2-c++-tools orphan, tartina  0 weeks ago
lv2-fabla orphan, tartina  0 weeks ago
lv2-ll-pluginsorphan, tartina  0 weeks ago
lv2-mdaEPiano orphan, tartina  0 weeks ago
lv2-newtonatororphan, tartina  0 weeks ago
lv2-sorcerorphan, tartina  0 weeks ago
lv2-swh-plugins   orphan, tartina  0 weeks ago
lv2-vocoder-plugins   orphan, tartina  0 weeks ago
mailman   orphan   1 weeks ago
maven-verifiermizdebsk, orphan  

Re: Orphaning the cura-lulzbot package set

[Miro Hrončok]

On 01. 03. 21 15:36, Tom Callaway wrote:
This fork of cura has basically been abandoned by upstream, and the new company 
that acquired Lulzbot has gone out of compliance with the source code for the 
firmware. They have made it very clear that they have no real interest in 
working with the community to improve this situation, and I no longer have any 
motivation to maintain these packages.


Accordingly, I've orphaned the following packages:

* cura-lulzbot
* lulzbot-marlin-firmware
* CuraEngine-lulzbot
* python-uranium-lulzbot

~spot

P.S. I opened an upstream pull request to add support for the Lulzbot TAZ Pro 
and the Mini 2 in the main Cura codebase (still actively maintained). I would 
highly recommend that anyone considering reviving these packages devote their 
efforts in that direction instead.


Hey spot,
The packages are retired on rawhide now.

Should cura obsolete cura-lulzbot?

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

Re: dnf repoquery and installed module problem

[Miro Hrončok]

On 12. 04. 21 14:23, Richard Shaw wrote:
I'm trying to collect the provides from the openexr package so I know what needs 
to be rebuilt in Rawhide but the repoquery command fails due to a module I have 
installed:


$ dnf repoquery --repoid rawhide --provides openexr > provides
Fedora - Rawhide - Developmental packages for t  12 MB/s |  57 MB     00:04
Last metadata expiration check: 0:00:14 ago on Mon 12 Apr 2021 07:17:08 AM CDT.
Modular dependency problem:

  Problem: conflicting requests
   - nothing provides module(platform:f33) needed by module 
nodejs:12:3320210223224147:601d93de.x86_64


If I'm trying to do a repoquery of another release, in this case rawhide, I 
really don't care about anything I have installed on my f33 machine. Am I going 
to have to start doing this in mock?


Enabled modular streams break repoquery for other repos, but it is designed that 
way, so the bug was closed:


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

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

Re: [Reminder] Fedora IoT Test Week is Starting Today! 12 April 2021

[Geoffrey Marr]

Yikes! The above links, while textually correct, don't link to the correct
pages! Please either copy/paste the above links or use the following
hyperlinks.

[0] https://fedoraproject.org/wiki/Test_Day:2021-04-12_Fedora_34_IoT_Edition
[1] https://testdays.fedoraproject.org/events/110

Geoff Marr
IRC: coremodule


On Mon, Apr 12, 2021 at 8:07 AM Geoffrey Marr  wrote:

> Hello testers!
>
> This is a friendly reminder that the Fedora IoT Test Week is starting
> today, 12 April 2021! See the test day wiki page [0] and the testday app
> [1] for more information on how to get started testing.
>
> Please note that this test week is a little different... Since Fedora is
> expected to release at least one Release Candidate (RC) for Fedora 34 this
> week, we will start by testing the latest branched compose of Fedora IoT,
> then switch to testing the RC when it releases. Please make sure to list
> which version of the Fedora IoT images you are using in the comment section
> on the results page.
>
> We appreciate any and all testing that can be done, in a VM or on
> baremetal hardware; both are welcome!
>
> Geoff Marr
> IRC: coremodule
>
> [0] fedoraproject.org/wiki/Test_Day:2021-04-12_Fedora_34_IoT_Edition
> 
> [1] https://testdays.fedoraproject.org/events/110
> 
>
> Geoff Marr
> IRC: coremodule
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Grub 2 protected packages

[Lennart Poettering]

On Mo, 12.04.21 11:22, Colin Walters (walt...@verbum.org) wrote:

> But, trying to change the traditional RPM path seems quite tricky to
> do safely without having a window where the grub binaries are
> deleted from `/boot` e.g.

Wouldn't it suffice to just start marking the files as %ghost in an
RPM package update? I'd assume tht RPM would then leave the files
that are already in place in place, no?

> And we've conditioned people to the idea that `yum update` will also
> update grub for EFI systems.

Well, the RPM scriptlets of grub could should the equivalent of "bootctl
update" of course.



Lennart

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

Re: Gating feedback from early adopters after almost 2 years: It doesn't seem to work

[Miro Hrončok]

On 10. 04. 21 7:50, Stef Walter wrote:

Hey Miro,

Sad to hear that it's been so rough.

On Wed, Apr 7, 2021 at 9:59 AM Miro Hrončok > wrote:


Hello,
I was torn whether to share this here or not. I don't want to be the one who
always complains about things, but at the end I've decided that without 
honest
feedback, there cannot be progress (and I've realized I already am that 
guy).

Please don't take this feedback personally, I know that building things is
hard.
I don't criticize people, but the tools.

Almost 2 years ago, we've decided to be the early adopters of gating in 
Fedora
with the python-virtualenv package:

https://src.fedoraproject.org/rpms/python-virtualenv/c/66b7533376f


Gating has proved more problematic than useful. It almost never works 
reliably,
the problems are impossible to decipher and/or debug. Too often we had to 
ask
for a CI-expert human intervention or straight out waive the results.

The humans we've contacted were always very friendly, helpful and they were
able
to solve our issues. However, human-operated CIs unfortunately don't scale 
very
well.


Heh heh.

At first, we assumed the issues will get ironed out with time, but there
seem to
be no visible progress.

Moreover, the gating caught 0 issues, because we already test our changes 
via
Pull Requests.

I'm not sure if others have similar experience, or if we just got unlucky :(


Martin Pitt recently posted a blog post about how he's been using the same tests 
and environments upstream in Pull Requests + downstream in Fedora gating. He 
also talks about "Fedora Gating woes" there. Perhaps similar concerns and 
pragmatic solutions.


https://cockpit-project.org/blog/fmf-unified-testing.html 



Thanks for the link Stef,
we will certainly be looking into fmf and tmt, it is on my TODO for a while. I 
had no idea it is to be more reliable than standard test interface, which 
certainly moves it higher in to priority list :)


As for what is said in the blog post, I am not sure that running test in 
upstream using the *exact same environment* is what we want. We want to run 
tests downstream using the Fedora environment as up to date as possible. The 
problem we are trying to solve is "make sure that if we do this downstream, is 
still works in up to date Fedora" not "if upstream commits this change, make 
sure it does not break in this pinned environment". For me at least, It's all 
about integration into the distro, not about regression testing -- upstream 
already has that covered.


(I believe Python situation wrt this is different from projects that target 
Fedora-ecosystem as their primary deployment platform, such as cokpit or anaconda.)


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

Re: Grub 2 protected packages

[Colin Walters]

On Mon, Apr 12, 2021, at 10:52 AM, Lennart Poettering wrote:
> O
> (Of course, sd-boot works this way: the RPM packages drop EFI binaries
> into /usr/, and "bootctl install" and "bootctl update" will copy them
> into the boot loader partitions, carefully and defensively in order
> not to corrupt what else might be there.)

Yep, rpm-ostree and bootupd (https://github.com/coreos/bootupd/) that are used 
by Fedora CoreOS are similar.

But, trying to change the traditional RPM path seems quite tricky to do safely 
without having a window where the grub binaries are deleted from `/boot` e.g.  
And we've conditioned people to the idea that `yum update` will also update 
grub for EFI systems.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1948241] perl-perlfaq-5.20210411 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-68c0221125 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-68c0221125`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-68c0221125

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


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

[Bug 1948301] perl-Graphics-TIFF-10 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-0e212aa57f has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-0e212aa57f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-0e212aa57f

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


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

Re: Stepping down as Fedora Jam maintainer

[Matthew Miller]

On Sun, Apr 11, 2021 at 11:38:40PM -, JT Pennington wrote:
> I'd like to volunteer to pick up the Fedora Jam project and maintain it.

Awesome -- thanks JT!

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

Re: Grub 2 protected packages

[Lennart Poettering]

On Mo, 12.04.21 06:00, Neal Gompa (ngomp...@gmail.com) wrote:

> > In fact, the presence of a bunch of other files in /boot in
> > grub2-efi-x64 seems like a bad idea. IMO, just installing the grub2
> > packages should either not modify /boot (which is not the exclusive
> > property of grub2 and often has limited space), or if this cannot
> > be done, grub2 needs to make sure that the grub2 packages are not
> > a dependency of anything and can only be installed with an explicit
> > user request.
>
> Ideally, we should change to a system similar to what openSUSE does
> and have the RPMs install bootloader content into /usr, then execute a
> helper program that copies things over to /boot and configures things
> properly (we should still have the files %ghosted in /boot, though!).
> This makes it much more straightforward to support updating or
> downgrading bootloader files when needed, which is why openSUSE does
> it this way to support full system snapshots with rollback
> functionality.

I vehemently agree with this. The ESP and other boot loader partitions
should really be considered common good and not really "owned" by RPM
or other packaging tools the way stuff in /usr/ is owned by them.

Multiple OSes and Linux distributions might want to drop stuff in
these partitions (under common names even, consider the main EFI
entrypoint after all), and hence the update semantics need to be a bit
more cooperative, to avoid everyone steps on each other toes all the
time. Hence: use RPM to update boot loaders binaries in /usr, and use
a separate tool to copy things over to the ESP and other boot
partitions when appropriate.

(Of course, sd-boot works this way: the RPM packages drop EFI binaries
into /usr/, and "bootctl install" and "bootctl update" will copy them
into the boot loader partitions, carefully and defensively in order
not to corrupt what else might be there.)

Lennart

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

Re: Grub 2 protected packages

[Lennart Poettering]

On So, 11.04.21 03:53, Robert Scheck (rob...@fedoraproject.org) wrote:

> My intention of packaging efifs for Fedora was to get systemd-boot handling
> my ext4 XBOOTLDR (https://github.com/systemd/systemd/issues/17756), which
> still is not working, because of the two issues mentioned there (and less
> systemd-boot upstream interest as it seems).

I would be delighted to merge a patch to sd-boot that works around
this issue. None has been submitted so far, and in my personal use
this issue hasn't shown up yet, so I didn't really put the effor in
myself yet.

I'd also be delighted to merge a patch for sd-boot that auto-loads all
drivers in some drop-in directory in the ESP before searching for boot
menu items, so that there's a nice way to load other file system
drivers.

I'll look into both these issues eventually if noone else does, but
it's not the top prio for me I have to say.

A submitted, clean PR would speed things up a lot.

Lennart

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

[Reminder] Fedora IoT Test Week is Starting Today! 12 April 2021

[Geoffrey Marr]

Hello testers!

This is a friendly reminder that the Fedora IoT Test Week is starting
today, 12 April 2021! See the test day wiki page [0] and the testday app
[1] for more information on how to get started testing.

Please note that this test week is a little different... Since Fedora is
expected to release at least one Release Candidate (RC) for Fedora 34 this
week, we will start by testing the latest branched compose of Fedora IoT,
then switch to testing the RC when it releases. Please make sure to list
which version of the Fedora IoT images you are using in the comment section
on the results page.

We appreciate any and all testing that can be done, in a VM or on baremetal
hardware; both are welcome!

Geoff Marr
IRC: coremodule

[0] fedoraproject.org/wiki/Test_Day:2021-04-12_Fedora_34_IoT_Edition

[1] https://testdays.fedoraproject.org/events/110


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

[Bug 1948301] perl-Graphics-TIFF-10 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-f505396015 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-f505396015


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

[Bug 1948301] perl-Graphics-TIFF-10 is available

[bugzilla]

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



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


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

[Bug 1948301] perl-Graphics-TIFF-10 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

[Bug 1948301] perl-Graphics-TIFF-10 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




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

Fedora 34 compose report: 20210412.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-34-20210411.n.0
NEW: Fedora-34-20210412.n.0

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

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

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

= ADDED IMAGES =
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-34-20210412.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Heads Up: openexr 3.0 coming to Rawhide

[Richard Shaw]

I'm currently in the process of testing all deps in my COPR. Assuming no
major issues are found I'll setup a side tag to perform all the builds. I
expect to be done by this coming weekend.

Affected packages are:

alembic
aqsis
bcd
blender
calligra
CTL
darktable
Field3D
freeimage
gegl04
gimp
gmic
gstreamer1-plugins-bad-free
hugin
ImageMagick
kdebase3
kdelibs
kde-runtime
kf5-kimageformats
kio-extras
krita
luminance-hdr
luxcorerender
opencv
OpenImageIO
OpenSceneGraph
openshadinglanguage
openvdb
pfstools
povray
prusa-slicer
synfig
synfigstudio
vigra
vips
YafaRay

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

Re: dnf repoquery and installed module problem

[Richard Shaw]

Never mind... It's still annoying but I has assumed it failed, but stdout
went to the file as expected.

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

dnf repoquery and installed module problem

[Richard Shaw]

I'm trying to collect the provides from the openexr package so I know what
needs to be rebuilt in Rawhide but the repoquery command fails due to a
module I have installed:

$ dnf repoquery --repoid rawhide --provides openexr > provides
Fedora - Rawhide - Developmental packages for t  12 MB/s |  57 MB 00:04

Last metadata expiration check: 0:00:14 ago on Mon 12 Apr 2021 07:17:08 AM
CDT.
Modular dependency problem:

 Problem: conflicting requests
  - nothing provides module(platform:f33) needed by module
nodejs:12:3320210223224147:601d93de.x86_64

If I'm trying to do a repoquery of another release, in this case rawhide, I
really don't care about anything I have installed on my f33 machine. Am I
going to have to start doing this in mock?

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

[Bug 1948241] perl-perlfaq-5.20210411 is available

[bugzilla]

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



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


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

[Bug 1948241] perl-perlfaq-5.20210411 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-perlfaq-5.20210411-1.f
   ||c35




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

[Bug 1936221] perl-libwww-perl-6.53 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 CC||ppi...@redhat.com
 Resolution|--- |ERRATA
Last Closed||2021-04-12 10:47:30




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

[Bug 1948241] perl-perlfaq-5.20210411 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




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

Fedora rawhide compose report: 20210412.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210411.n.0
NEW: Fedora-Rawhide-20210412.n.0

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

Size of added packages:  149.69 KiB
Size of dropped packages:0 B
Size of upgraded packages:   5.74 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20210411.n.0.iso

= ADDED PACKAGES =
Package: samdump2-3.0.0-20.fc35
Summary: Retrieves syskey and extracts hashes from Windows 2k/NT/XP/Vista SAM
RPMs:samdump2
Size:149.69 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  arm-none-eabi-gcc-cs-1:10.2.0-5.fc35
Old package:  arm-none-eabi-gcc-cs-1:10.2.0-4.fc35
Summary:  GNU GCC for cross-compilation for arm-none-eabi target
RPMs: arm-none-eabi-gcc-cs arm-none-eabi-gcc-cs-c++
Size: 907.48 MiB
Size change:  -445.70 KiB
Changelog:
  * Sun Apr 11 2021 Michal Hlavinka  - 1:10.2.0-5
  - add explicit requirement for autoconf 2.69


Package:  avr-binutils-1:2.35-4.fc35
Old package:  avr-binutils-1:2.35-3.fc34
Summary:  Cross Compiling GNU binutils targeted at avr
RPMs: avr-binutils
Size: 8.97 MiB
Size change:  -3.08 KiB
Changelog:
  * Sun Apr 11 2021 Michal Hlavinka  - 1:2.35-4
  - add explicit requirement for autoconf 2.69


Package:  avr-gcc-1:10.2.0-3.fc35
Old package:  avr-gcc-1:10.2.0-2.fc34
Summary:  Cross Compiling GNU GCC targeted at avr
RPMs: avr-gcc avr-gcc-c++
Size: 147.35 MiB
Size change:  -112.43 KiB
Changelog:
  * Sun Apr 11 2021 Michal Hlavinka  - 1:10.2.0-3
  - add explicit requirement for autoconf 2.69


Package:  bcm283x-firmware-20210407-1.8c7c524.fc35
Old package:  bcm283x-firmware-20210310-1.0591568.fc35
Summary:  Firmware for the Broadcom bcm283x/bcm2711 used in the Raspberry Pi
RPMs: bcm2711-firmware bcm2835-firmware bcm283x-firmware 
bcm283x-overlays
Size: 13.67 MiB
Size change:  14.93 KiB
Changelog:
  * Sun Apr 11 2021 Peter Robinson  
20210407-1.8c7c524
  - Update to latest firmware


Package:  bubblemail-1.4-1.fc35
Old package:  bubblemail-1.3-3.fc35
Summary:  Extensible mail notification service
RPMs: bubblemail
Size: 1000.09 KiB
Size change:  12.65 KiB
Changelog:
  * Sun Apr 11 2021 Alexander Ploumistos  - 1.4-1
  - Update to 1.4


Package:  catch-2.13.5-1.fc35
Old package:  catch-2.13.4-3.fc35
Summary:  Modern, C++-native, header-only, framework for unit-tests, TDD 
and BDD
RPMs: catch-devel
Size: 1.15 MiB
Size change:  -1.97 MiB
Changelog:
  * Sun Apr 11 2021 Tom Hughes  - 2.13.5-1
  - Update to 2.13.5 upstream release


Package:  copyq-4.0.0-1.fc35
Old package:  copyq-3.13.0-3.fc34
Summary:  Advanced clipboard manager
RPMs: copyq
Size: 11.16 MiB
Size change:  373.98 KiB
Changelog:
  * Sun Apr 11 2021 Gerald Cox  - 4.0.0-1
  - Upstream release rhbz#1948314


Package:  dummy-test-package-gloster-0-3379.fc35
Old package:  dummy-test-package-gloster-0-3369.fc35
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 210.21 KiB
Size change:  613 B
Changelog:
  * Sun Apr 11 2021 packagerbot  - 0-3370
  - rebuilt

  * Sun Apr 11 2021 packagerbot  - 0-3371
  - rebuilt

  * Sun Apr 11 2021 packagerbot  - 0-3372
  - rebuilt

  * Sun Apr 11 2021 packagerbot  - 0-3373
  - rebuilt

  * Sun Apr 11 2021 packagerbot  - 0-3374
  - rebuilt

  * Sun Apr 11 2021 packagerbot  - 0-3375
  - rebuilt

  * Sun Apr 11 2021 packagerbot  - 0-3376
  - rebuilt

  * Sun Apr 11 2021 packagerbot  - 0-3377
  - rebuilt

  * Mon Apr 12 2021 packagerbot  - 0-3378
  - rebuilt

  * Mon Apr 12 2021 packagerbot  - 0-3379
  - rebuilt


Package:  fbzx-4.6.0-1.fc35
Old package:  fbzx-4.5.0-1.fc35
Summary:  A ZX Spectrum emulator for FrameBuffer
RPMs: fbzx
Size: 723.31 KiB
Size change:  -71 B
Changelog:
  * Sun Apr 11 2021 Andrea Musuruane  - 4.6.0-1
  - Updated to new upstream release


Package:  gnome-shell-extension-bubblemail-14-1.fc35
Old package:  gnome-shell-extension-bubblemail-1.3-2.fc34
Summary:  GNOME Shell indicator for new and unread mail using Bubblemail
RPMs: gnome-shell-extension-bubblemail
Size: 37.55 KiB
Size change:  720 B
Changelog:
  * Sun Apr 11 2021 Alexander Ploumistos  - 14-1
  - Update to v14 - compatible with GNOME 40 
  - New versioning scheme
  - Bump required bubblemail service version to 1.3


Package:  golang-github-niklasfasching-org-1.5.0-1.fc35
Old package:  golang-github-niklasfasching-org-1.4.0-2.fc34
Summary:  Org mode parser with html & pretty printed org rendering
RPMs: go-org golang-github-niklasfasching-org-devel

[Bug 1909364] perl-CPANPLUS-0.9910 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 CC||ppi...@redhat.com
 Resolution|--- |ERRATA
Last Closed||2021-04-12 10:45:53




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

[Bug 1948339] perl-Log-Agent-1.005 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Log-Agent-1.005-1.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-04-12 10:35:45



--- Comment #3 from Petr Pisar  ---
Log::Agent::Driver::Syslog::make() changed -socktype argument semantics.
Suitable only for Rawhide.


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

Re: Grub 2 protected packages

[PGNet Dev]

On 4/12/21 3:51 AM, Javier Martinez Canillas wrote:

I dropped it by mistake when rebasing to 2.06, sorry about that. I've
fixed it now in F33, F34 and Rawhide.


i see rawhide has 'stable' already; and that F33/F34 are 'pending->testing'.

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

[rpms/perl-Log-Agent] PR #1: Tests

[Petr Pisar]

ppisar merged a pull-request against the project: `perl-Log-Agent` that you are 
following.

Merged pull-request:

``
Tests
``

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

[rpms/perl-Log-Agent] PR #1: Tests

[Petr Pisar]

ppisar opened a new pull-request against the project: `perl-Log-Agent` that you 
are following:
``
Tests
``

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

Re: Grub 2 protected packages

[Neal Gompa]

On Mon, Apr 12, 2021 at 5:43 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sat, Apr 10, 2021 at 09:04:09PM -, Filippe LeMarchand wrote:
> > > This shouldn't be the case. Unless there's a bug, grub2 may be
> > > installed an unused. If it interferes with sd-boot, please file
> > > a bug.
> >
> > The grub2-efi-x64 package contains directory
> > /boot/loader/entries. AFAICT this directory presence alone makes
> > kernel-install script install the boot files there instead of
> > /boot/efi/loader (which is needed for sd-boot). Should this be
> > considered a grub2 bug?
>
> It's not only a grub2 bug, it's also a straightforward recreation of a
> bug that was already fixed once with a lot of pain [1].
>
> At the time a solution was hashed out that depends on the presence of
> certain directories [2]. The idea was that bootctl would create
> /boot/efi/loader/entries only when 'bootctl install' is called [3].
> And the appropriate grub2 equivalents would do that same when grub2 is
> installed to EFI. And generally, it should be fine for both sets of
> rpms (and even other boot loaders!) to be installed into the system,
> so that systems don't stop booting again when the grub2 rpms are
> pulled in through a dependency.
>
> This is fragile, and is certainly not an ideal solution, but we didn't
> have a better solution that would work for existing systems without an
> explicit user intervention. But now grub2 embeds /boot/loader/entries
> directly in grub2-efi-x64.rpm, breaking things.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1648907
> [2] https://github.com/systemd/systemd/commit/cf73f65089
> [3] https://github.com/systemd/systemd/commit/341890de86
>
> In fact, the presence of a bunch of other files in /boot in
> grub2-efi-x64 seems like a bad idea. IMO, just installing the grub2
> packages should either not modify /boot (which is not the exclusive
> property of grub2 and often has limited space), or if this cannot
> be done, grub2 needs to make sure that the grub2 packages are not
> a dependency of anything and can only be installed with an explicit
> user request.
>

Ideally, we should change to a system similar to what openSUSE does
and have the RPMs install bootloader content into /usr, then execute a
helper program that copies things over to /boot and configures things
properly (we should still have the files %ghosted in /boot, though!).
This makes it much more straightforward to support updating or
downgrading bootloader files when needed, which is why openSUSE does
it this way to support full system snapshots with rollback
functionality.



-- 
真実はいつも一つ！/ 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Grub 2 protected packages

[Zbigniew Jędrzejewski-Szmek]

On Sat, Apr 10, 2021 at 09:04:09PM -, Filippe LeMarchand wrote:
> > This shouldn't be the case. Unless there's a bug, grub2 may be
> > installed an unused. If it interferes with sd-boot, please file
> > a bug.
> 
> The grub2-efi-x64 package contains directory
> /boot/loader/entries. AFAICT this directory presence alone makes
> kernel-install script install the boot files there instead of
> /boot/efi/loader (which is needed for sd-boot). Should this be
> considered a grub2 bug?

It's not only a grub2 bug, it's also a straightforward recreation of a
bug that was already fixed once with a lot of pain [1].

At the time a solution was hashed out that depends on the presence of
certain directories [2]. The idea was that bootctl would create
/boot/efi/loader/entries only when 'bootctl install' is called [3].
And the appropriate grub2 equivalents would do that same when grub2 is
installed to EFI. And generally, it should be fine for both sets of
rpms (and even other boot loaders!) to be installed into the system,
so that systems don't stop booting again when the grub2 rpms are
pulled in through a dependency.

This is fragile, and is certainly not an ideal solution, but we didn't
have a better solution that would work for existing systems without an
explicit user intervention. But now grub2 embeds /boot/loader/entries
directly in grub2-efi-x64.rpm, breaking things.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1648907
[2] https://github.com/systemd/systemd/commit/cf73f65089
[3] https://github.com/systemd/systemd/commit/341890de86

In fact, the presence of a bunch of other files in /boot in
grub2-efi-x64 seems like a bad idea. IMO, just installing the grub2
packages should either not modify /boot (which is not the exclusive
property of grub2 and often has limited space), or if this cannot
be done, grub2 needs to make sure that the grub2 packages are not
a dependency of anything and can only be installed with an explicit
user request.

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

Fedora-Cloud-32-20210412.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-20210411.0):

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

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

[Bug 1948339] perl-Log-Agent-1.005 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 12th April (Today)

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 12th
April (today!) at 1300UTC in #fedora-neuro on IRC (Freenode). The
meeting is a public meeting, and open for everyone to attend. You can
join us over:

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

or Matrix/Element:
https://matrix.to/#/!xgwUsLNGIoOAXMxGMQ:matrix.org?via=matrix.org=t2bot.io

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

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

or you can use this link:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20210412T13=%3A=1

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

- New introductions and roll call.
- Tasks from last week's meeting:
  
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-03-29-14.06.html
- Open Pagure tickets:
  
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Open bugs check: https://tinyurl.com/neurofedora-bugs
- Open package reviews check:
  https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- Koschei packages check:
  https://koschei.fedoraproject.org/groups/neuro-sig
- CompNeuro lab compose status check for F34/F35:
  https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

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


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

Re: Grub 2 protected packages

[Javier Martinez Canillas]

On Sun, Apr 11, 2021 at 2:29 PM PGNet Dev  wrote:
>
> > Ordinarily, no. But in this case, since GRUB 2.06~rc1 is required to
> > solve major critical vulnerabilities and it's very difficult to pull
> > the patch set that fixes it (>115 patches!) backwards, GRUB got moved
> > forward instead.
> >
> > GRUB 2.06~rc1 was pretty much released to release the patch set...
>
> got it.
>

As Neal said, the other option was to backport all the CVE fixes and
SBAT support patches which was a riskier option.

Also, we are trying to get rid of the huge patch-set that the Fedora
package is currently carrying, not adding more to the set.

> then will stick with v2.06, and try to get it re-patched for Xen @ the bug.
>

I dropped it by mistake when rebasing to 2.06, sorry about that. I've
fixed it now in F33, F34 and Rawhide.

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

[Bug 1947739] perl-Workflow-1.53 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Workflow-1.53-1.fc35
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-04-12 07:37:16



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1734925


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

[Bug 1948067] perl-GnuPG-Interface-1.02 is available

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-GnuPG-Interface-1.02-1
   ||.fc35
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-04-12 07:36:40



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1735157


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

Fedora-Cloud-33-20210412.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-20210411.0):

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

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

Re: Retiring from Perl maintenance

[Petr Pisar]

V Sun, Apr 11, 2021 at 04:04:19PM +0200, Emmanuel Seyman napsal(a):
> I will gladly take ownership of the following:
> 
> * perl-CGI-FastTemplate
> * perl-CGI-FormBuilder
> * perl-Dancer-Session-Cookie
> * perl-HTML-Escape
> * perl-HTML-FormatExternal
> * perl-HTML-FormFu-Element-reCAPTCHA
> * perl-HTML-FormFu-MultiForm
> * perl-HTML-HTML5-Entities
> * perl-HTML-HTML5-Parser
> * perl-HTML-HTML5-Sanity
> * perl-HTML-HTML5-Writer
> * perl-MooseX-ArrayRef
> * perl-MooseX-AttributeShortcuts
> * perl-MooseX-CoercePerAttribute
> * perl-MooseX-MarkAsMethods
> * perl-MooseX-Meta-TypeConstraint-Mooish
> * perl-MooseX-TraitFor-Meta-Class-BetterAnonClassNames
> * perl-MooseX-Types-DateTime-MoreCoercions
> * perl-MooseX-Util
> * perl-MooX-Struct
> * perl-MouseX-Foreign
> 
Moved.

-- Petr


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

Re: Retiring from Perl maintenance

[Petr Pisar]

V Sun, Apr 11, 2021 at 11:20:52AM +0100, Paul Howarth napsal(a):
> I'm happy to take the following:
> 
> perl-Function-Parameters
> perl-Math-Random-MT-Auto
> perl-Object-InsideOut
> perl-Perl-Critic-Deprecated
> perl-Perl-Critic-Lax
> perl-Perl-Critic-Pulp
> perl-PPIx-QuoteLike
> perl-Sereal
> perl-Sereal-Decoder
> perl-Sereal-Encoder
> perl-Test-UseAllModules
> 
Tranferred. You should be warned that Sereal (optionally?) requires miniz
which sufferes from a security issue which upstream is not willing to
address (bug #1597487). It's a pitty that Sereal, which was designed to
replace unsafe Storable, is also not safe for this reason.

-- Petr



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

[Test-Announce] Grub and Shim Test Day, 2021-04-12

[Sumantro Mukherjee]

Hi,

Grub and Shim Test Day starts today
https://fedoraproject.org/wiki/Test_Day:2021-04-12_Grub_and_Shim_Test_Day

Special call out: No installation required! If you have (U)EFI x86_64
hardware, with or without Secure Boot, please create install media
using one of the provided special test ISOs, and boot your system.
Please test all makes/models you happen to have available. We're not
anticipating shim bugs, but firmware peculiarities that shim might
have to work around.

If you have Fedora 33/34 installed, with updates-testing repo enabled,
you likely already have shim-15.4-3. In which case ... it works!
Please report your test results here ->
https://testdays.fedoraproject.org/events/111

BIOS firmware and additional architectures are covered in the test
day, see the page for details.

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

Grub and Shim Test Day, 2021-04-12

[Chris Murphy]

Hi,

Grub and Shim Test Day starts today
https://fedoraproject.org/wiki/Test_Day:2021-04-12_Grub_and_Shim_Test_Day

Special call out: No installation required! If you have (U)EFI x86_64
hardware, with or without Secure Boot, please create install media
using one of the provided special test ISOs, and boot your system.
Please test all makes/models you happen to have available. We're not
anticipating shim bugs, but firmware peculiarities that shim might
have to work around.

If you have Fedora 33/34 installed, with updates-testing repo enabled,
you likely already have shim-15.4-3. In which case ... it works!
Please report your test results here ->
https://testdays.fedoraproject.org/events/111

BIOS firmware and additional architectures are covered in the test
day, see the page for details.


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