Fedora-Cloud-33-20211109.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

Re: Self Introduction: Alexander Bulimov

[Benjamin Kircher]

On Mon, 2021-11-08 at 16:19 +, Alexander Bulimov wrote:
> Hello!
> 
> I work at Facebook on the team dealing with all things NTP/PTP,
> including the OCP Time Appliance Project.
> 
> We've already open-sourced lots of related software, Davide Cavalca
> kindly packaged most of it, and from now on I'll be actively
> supporting and updating it.
> 
> My focus for now will be on all the stuff under
> github.com/facebookincubator/ntp, github.com/facebookincubator/ptp,
> github.com/Orolia2s/oscillatord, and dependencies.
> 
> The plan is to maintain it with Davide's help, and provide regular
> updates as the Time Appliance project is in the very active phase
> now.
> 
> Cheers
> Alex

Welcome!

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

Firmware packages

[Miroslav Suchý]

In the recent discussion about saving space (in the ELF thread) there poped up linux-firmware topic several time. Let's 
kick it off as separate thread.


I have several question and I am unable to find the answer for them.

1. How do I find which firmware package I need? On my workstation I have:

$ rpm-qa|grepfirmware |wc-l
27

I seriously doubt I need all of them. I definitely do not need them on server, where I never add any new HW. But how do 
I know which one is in use and which not?


2. How the firmware packages actually work? Do I need them to be present every time? Or when module is loaded? Or 
something else? (sorry if this too naive question).


3. The linux-firmare has 100MB. And cca 280 MB extracted. Is it about the time to split the package? Here are the 
biggest space eater of the space:


18M /usr/lib/firmware/amdgpu
18M /usr/lib/firmware/qcom
28M /usr/lib/firmware/intel
31M /usr/lib/firmware/mrvl
47M /usr/lib/firmware/mellanox

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

[Demi Marie Obenour]

On 11/8/21 12:36 PM, Simo Sorce wrote:
> On Sat, 2021-11-06 at 07:43 +, Daniel Alley wrote:
>>> On Wed, Aug 11, 2021 at 10:03:50PM +0200, Marek Marczykowski-
>>> Górecki wrote:
>>> I do think we should drop drpms or make them more useful, but I
>>> don't
>>> think there's any security angle here. (see below)
>>>
>>> drpms work by downloading the delta, then using it + the version
>>> you
>>> have installed to recreate the signed rpm (just like you downloaded
>>> the
>>> full signed update) and then the gpg signature is checked of that
>>> full rpm,
>>> just like one you downloaded. If the drpm is tampered with it won't
>>> reassemble and it will fall back to the full signed rpm.
>>
>> Sorry to resurrect this thread.
>>
>> Another issue - which is not per-se a security issue but it's still a
>> problem - is that deltarpm uses md5 checksums pervasively.  They're
>> everywhere.  And it uses its own implementation of md5 which doesn't
>> respect FIPS, so even when the user has *explicitly* configured their
>> system to not use md5 for anything security-relevant, libdeltarpm
>> won't know or care. 
> 
> md5 used as a checksum to only detect network transmission issues is
> not a problem, and is not under the purview of the FIPS certification.
> 
> As mentioned above the actual packages are still finally reassembled
> and the signature checked, so that is what matters in terms of security
> (those algorithms and computations need to be FIPS approved and the
> implementation certified).
This is enough for FIPS, yes, but it is still very risky, as a bug in the
package reassembly process is a remote root exploit.  At a minimum, I
recommend disabling deltarpm by default if repo_gpgcheck is not 1.

Sincerely,
Demi Marie Obenour


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


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

Re: Automated formal verification of RPM packages

[Kamil Dudka]

On Monday, November 8, 2021 7:10:45 PM CET Jerry James wrote:
> Nice!  Thanks for working on this.  I tried to use the csmock plugin,
> but got this at the end of the build (on an x86_64 F34 host, building
> for fedora-35-x86_64):
> 
> + for file in 
> /tmp/csmockadxnd155/metamath-0.198-1.fc36/debug/raw-results/builddir/cbmc-capture/pid-*.out
> + cbmc-convert-output -a
> /bin/sh: line 4: cbmc-convert-output: command not found
> 
> !!! 2021-11-08 10:02:57error: post-process hook failed
> 
> The problem appears to be that csmock-plugin-cbmc doesn't require cbmc
> or cbmc-utils:

Thank you for pointing it out!  It is exactly as you say.  I have submitted
a pull request to fix this:

https://github.com/csutils/csmock/pull/46

Kamil

> $ rpm -q --requires csmock-plugin-cbmc
> csexec
> csmock-common(python3)
> python(abi) = 3.9
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> rpmlib(PayloadIsZstd) <= 5.4.18-1
> 
> 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

License change for stockfish: GPLv3+ -> GPLv3+ and CC0

[Ondrej Mosnacek]

Hi,

The stockfish package will start building from an additional source
file containing trained neural network weights, which is provided
under the Creative Commons Zero license.

See the pending pull request for more details:
https://src.fedoraproject.org/rpms/stockfish/pull-request/1

-- 
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Qa-tools-sig] Orphaned packages looking for new maintainers​

[Frantisek Zatloukal]

On Mon, Nov 8, 2021 at 4:53 PM Miro Hrončok  wrote:

>
> python-pylibmcabompard, orphan, pjp1 weeks
> ago
>

Taken.


-- 

Best regards / S pozdravem,

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

Re: dnf "no match for group package" on upgrade...

[Kevin Fenzi]

On Mon, Nov 08, 2021 at 05:01:47PM -0500, Matthew Miller wrote:
> On Mon, Nov 08, 2021 at 09:55:42PM +0100, Dominik 'Rathann' Mierzejewski 
> wrote:
> > +1 to both.
> 
> https://github.com/rpm-software-management/dnf/pull/1795
> 
> https://pagure.io/releng/issue/10376

I'll add here that even though there's a number of PR's open against
fedora-comps, it's pretty reasonably maintained I think. Uncontroversial
changes are merged pretty quickly... it's just the messy ones where some
group can't come to consensus where they sit around for a long time. 

I guess I can just look at closing those and tell people to re-file when
they have made some decision. 

kevin


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

Re: dnf "no match for group package" on upgrade...

[Matthew Miller]

On Mon, Nov 08, 2021 at 09:55:42PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> +1 to both.

https://github.com/rpm-software-management/dnf/pull/1795

https://pagure.io/releng/issue/10376


-- 
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: dnf "no match for group package" on upgrade...

[Adam Williamson]

On Mon, 2021-11-08 at 15:41 -0500, Matthew Miller wrote:
> I'm seeing a number of people confused by this message, usually followed by
> some actual transaction error.
> 
> I _think_ this is happening because these packages are in comps but do not
> exist in the distro. Is this correct? I tried to search for it, but the
> error message is _very_ common in ... well, people who are asking about it
> because of what I said. (For example: 
> https://unix.stackexchange.com/q/542877/2511)
> 
> I found https://bugzilla.redhat.com/show_bug.cgi?id=1538346 but not much of
> a general resolution. It does note that one issue is arch-specific
> packages (which maybe just need "arch=..." in comps?).
> 
> I think we should:
> 
> 1. Have a schedule standarded task to remove any packages listed but
>non-existent after branch from rawhide. (I assume a Rel-Eng task?)
> 
> 2. Have DNF make this message less scary. Maybe even move down to a debug
>message and not show it by default — I am not seeing a situation where
>they're useful to _most_ end-users.
> 
> Anything I'm missing?

These tend to pile up in comps, and I think resolving them *correctly*
is not always that easy of a task. It's *easy* to just remove them, but
I don't doing like that. Nothing is in comps for no reason. I think the
correct thing to do is figure out why they were put there, and what
they should sensibly be replaced by, if anything. Often it turns out
something got retired because it got renamed, or there isn't a direct
rename but there's a clear conceptual replacement, or something along
those lines. Doing this is rather harder than just blanket removing
things, though and is likely to be a substantial time commitment.

Back in 2018 I did two sweeps for this:

https://pagure.io/fedora-comps/c/6928aeb646da1729e46ccecfeaf3d71b3eacef6f?branch=main
https://pagure.io/fedora-comps/c/f17d7ec65ef6d4b7d9a183ed76d79f09577b4147?branch=main

and those took me at least a day each, I think. As you can see from the
changes, it's often not as simple as "just delete the line".

I also, at the time, wrote a script to find 'missing' entries like
this:

https://pagure.io/fedora-comps/c/b7db172dc739f8acd50fc8e2a0129931036f3c22?branch=main

it's still there, as check-missing in the comps repo. Ian McInerny has
since tweaked it a bit, including making it capable of automatically
removing the 'missing' entries (though I don't think it's a good idea
to just use that and say the job's done, for the reasons explained
above). He ran it and did a mass removal in the F33 timeframe:

https://pagure.io/fedora-comps/pull-request/506
https://pagure.io/fedora-comps/c/88c584531bf2fddb96ac2020fca0a74e1da37f1e?branch=main

though nobody seems to have tried to identify appropriate replacements
for the removed lines, which is unfortunate. Also I just noticed his
changes seem to get indenting wrong, wherever it changes the
 line, it indents it wrongly...
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

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

[Lennart Poettering]

On Mo, 08.11.21 13:54, David Cantrell (dcantr...@redhat.com) wrote:

> > > One of the reasons we are sticking to JSON here is so that we can use
> > > battle-tested parsers we already use for other stuff. you want a
> > > parser that is already used, verified, tested elsewhere, and JSON
> > > makes that easy. A homegrown parser of an entirely new special purpose
> > > format is a lot more problematic security-wise.
> >
> > In particular, the implementation in systemd is undergoing continuous
> > fuzzing in oss-fuzz, so we hope any simple issues have been already
> > caught.
>
> I wasn't really concerned with the reliability of the parser, but
> rather the necessity of JSON in the first place.  The more layers
> anything has, the higher the risk.

JSON is truly universal. We use it *everywhere* already, including in
trusted, security-sensitive areas.

Most prominently, LUKS2 uses JSON to encode most of its metadata in
the LUKS2 superblock. It doesn't get much more security-sensitive than
that.

And I think that's a *good* thing: JSON might not be perfect — because
nothing is —, but it's certainly one of the better designed generic
data formats around, and it's complexity is absolutely managable. I am
pretty sure *more* subsystems should use that to store their data, and
that we'd unify *more* on it, rather then *less*. Homegrown, manual,
application-specific formats and parsers are a *bad* thing, and not
something to strive for.

Sharing data formats, unifying behaviour and parsers is a way to
*minimize* components both on the conceptual level and in code. Thus
one shouldn't see the reuse of JSON here as "yet another layer", but
instead as "reuse existing infra" to *reduce* the number of layers.

So yes, the fact that the JSON parser used here is a layer that is
already deployed widely (though in other contexts) and has been
thoroughly fuzzed is a *good* thing, and putting together a new parser
here for a new format woudn't be.

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: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Nov 08, 2021 at 02:06:17PM -0500, David Cantrell wrote:
> I was thinking more about this proposal over the past weekend and
> where I keep ending up is that this is really optimizing for a small
> use case by touching ELF metadata all over the system. And that
> strikes me as pretty invasive, so is it worth the tradeoffs and risks
> and such?

I think this a point of confusion/disagreement. Why do you say that the
change is "invasive"?

Is it the extra size? It's completely dwarfed by many other routine
changes that we do, from new compiler speed optimizations that
increase size a bit, through new translation strings, through new
translation languages, through any additional functionality in any of
the frequently used libs, to the recent change from XZ to ZSTD. I'm
quite sure that if this level of changed happened implicitly through
e.g. a compiler change, nobody would ever notice.
Is it the extra compilation time? The answer is similar here: the
extra cost of inserting a few hundred bytes is completely dwarfed by
the compilation and linkage times, especially with LTO.
Is it the extra complexity? It's a very very simple generator and one
additional linkage option. This hasn't been widely deployed, so of
course there might be some complications, but there really very little
that can break here, and even if there's some issue, I'm fairly
confident we'll be able to fix it. So far the details of
implementation haven't really been questioned. If it turns out that the
current generator implementation is a problem, I'll be happy to
rewrite it, maybe even in lua, so that it can be done as part of the
spec generation without any external code. (Though I'd very much prefer
to wait with such optimizations until the format and contents have
seen more exposure; right now this would be premature optimization.)
And the note is inserted during package build, and then isn't consumed
by anything, until maybe the program crashes. Parsing the note is
completely trivial in complexity compared to the stack unwinding and
backtrace generation that happens in coredump analyzers. So it really
has no effect during normal runtime, and a very small one in analysis
programs for which the note is intended.

So I really don't understand the question about tradeoffs and risks.

> It has been stated multiple times that the information needs to be
> in the ELF header because containers and images may lack an RPM
> database.  Fair, but what about the users that both want a container
> and image without the RPM database and systemd-coredump?

Please, don't read too much into the part about containers. Personally,
I don't care about containers too much, I care about the other cases,
in particular programs crashing in the initrd.

systemd-coredump is also not particularly important here: it's just one
of consumer of this, even though it'll probably be an important one in
the context of Fedora. We are trying to build a generic standard, and
new uses that we can't even predict now will show up over time. The
format is open-ended, so it seems likely that people will come up
with new stuff to put there in their own builds.

systemd-coredump generally is *not* present in container images.

> They still have all of their ELF files with this information that
> they removed in other ways. Do we provide those users with a script
> to strip .gnu.notes from everything or is that even a use case of
> concern?

FWIW, you can remove the note, e.g. with patchelf or objcopy. 
Maybe I'm misunderstanding, but I don't see why this would be a concern,
and in particular why it would be *our* concern. It'd be like stripping
.note.gnu.build-id: technically possible, but I've never heard that come
up and I don't see why it would.

> Efforts to get the system very small for container and image use has
> been a goal for a while.  And sure we're not talking about a lot of
> data, but that's now.  The size of everything only grows, so is that
> something to consider with the implementation of this feature?

Realistically, the sizes here are too small for this to matter.
For a container image with a few dozen libraries and a few executables,
we are talking about kilobytes of data compared to hundreds of megs
for a container built from distro packages. Anyone who really optimizes
container size to the level where this would matter, is never going to
use our distro binaries but will use custom builds.

> Another thing I thought about were reproducible builds.  Does this
> impact reproducible builds and if so, how do we handle that?

This does not impact reproducible builds at all.
See the answer in
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#Won.27t_this_affect_the_Reproducible_Builds_effort.3F
 .

> I would feel more comfortable with this proposal if the data for
> systemd-coredump was not part of the ELF metadata.  Or if it
> absolutely must be part of the ELF metadata, users should know how it
> can be removed.

Yes, it must must be p

Re: dnf "no match for group package" on upgrade...

[Dominik 'Rathann' Mierzejewski]

On Monday, 08 November 2021 at 21:41, Matthew Miller wrote:
[...]
> I think we should:
> 
> 1. Have a scheduled standard task to remove any packages listed but
>non-existent after branch from rawhide. (I assume a Rel-Eng task?)
> 
> 2. Have DNF make this message less scary. Maybe even move down to a debug
>message and not show it by default — I am not seeing a situation where
>they're useful to _most_ end-users.

+1 to both.

> Anything I'm missing?

Not that I can think of.

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

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

[Luca Boccassi]

> On Thu, Nov 04, 2021 at 10:26:20AM +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> But a binary representation of that could strip it down into ~50%.

Would it though? Have you tested and checked it to make that determination? Can 
you share the code to reproduce it?

The values necessarily have to be strings, since the data varies unpredictably. 
The longest data fields are most likely going to be CPE and debuginfod URLs, 
package name and package version, which can be in the worst cases a few dozen 
bytes each. And to avoid completely throwing extensibility and flexibility to 
the wind, which is one of the key aspects of the proposals, the keys have to be 
strings too, so that each producer can add new fields if they want to, and 
users/support/maintainers can read them just fine without knowing all possible 
keys in advance. So at most you'd save from the json's quotes, commas and 
colons - that's 6 bytes per field. With 5 fields, that's 30 bytes saved without 
considering the space needed for the header encoding sizes and whatnot, on a 
total of ~200 bytes, with a considerable worse usability (custom format needing 
its own parsers and builders instead of well-known and understood json). It 
doesn't seem worth the trouble.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: deltarpm usefulness?

[Kevin Fenzi]

On Sun, Nov 07, 2021 at 10:43:33AM -0800, Gordon Messmer wrote:
> On 11/7/21 01:14, Rajeesh K V wrote:
> > Deltarpm did
> > reduce a lot of update download size for many years since 2007
> 
> 
> I remember seeing 60-70% reduction really often, and 90+ periodically.  I've
> read Kevin's explanation of why it's not working as well now, but I wonder
> what changed between the early implementation when results were very good
> and now, when they really aren't.

I think it's because you only see deltas from N to N+1 now and before
you saw deltas from N to N+X before. So, I think if we made it somehow
create older deltas, you would again see better savings. The issue
doesn't just cause there to be fewer deltas, but it also causes those
few be be against very recent changes, so less effective.


kevin


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

dnf "no match for group package" on upgrade...

[Matthew Miller]

I'm seeing a number of people confused by this message, usually followed by
some actual transaction error.

I _think_ this is happening because these packages are in comps but do not
exist in the distro. Is this correct? I tried to search for it, but the
error message is _very_ common in ... well, people who are asking about it
because of what I said. (For example: 
https://unix.stackexchange.com/q/542877/2511)

I found https://bugzilla.redhat.com/show_bug.cgi?id=1538346 but not much of
a general resolution. It does note that one issue is arch-specific
packages (which maybe just need "arch=..." in comps?).

I think we should:

1. Have a schedule standarded task to remove any packages listed but
   non-existent after branch from rawhide. (I assume a Rel-Eng task?)

2. Have DNF make this message less scary. Maybe even move down to a debug
   message and not show it by default — I am not seeing a situation where
   they're useful to _most_ end-users.

Anything I'm missing?


-- 
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: Long-running side tag for porting Fedora to C99 (no implicit decls)

[Kevin Fenzi]

On Mon, Nov 08, 2021 at 02:06:43PM +0100, Florian Weimer wrote:
> I would like to create a long-running rawhide side tag for preparing
> Fedora for the removal of implicit function declarations from the GCC
> defaults.  This is a change that happened in the C99 version of the
> language, but GCC could not adopt at the time because too much software
> was broken by it.  Even today, there are build failures, and, arguably
> worse, successful builds with different feature sets.
> 
> The goal is to disable implicit function declarations in GCC 13, to be
> released in spring 2023 (not next year's GCC 12 version).  This plan was
> presented at this year's Cauldron, and was met with approval:
> 
>   Eliminating implicit function declarations
>   
> 
> I have some space to work on this during the coming months, for
> implementing the buildroot changes (in gcc and presumably
> redhat-rpm-config, built off branches in dist-git), for creating some
> HTML reports, and even for creating the package changes themselves.
> Changes will be submitted to upstream projects initially.  Eventually,
> we'll have to fix the Fedora packages if there's no upstream release
> with the fixes.  We'll need some way to coordinate the fixes between
> multiple developers, a way to find unapplied upstream fixes once we are
> heading towards Fedora 38, and ideally some way to share patches across
> distributions if the upstream project no longer exists/accepts patches.
> 
> If Fedora wants to support this, I'd need a long-running side tag in
> Koji, and a few dist-git branches (for gcc and redhat-rpm-config).  I
> can do the test builds as scratch builds, to conserve storage space and
> not to pollute Koji with uninteresting NVRs.
> 
> Thoughts?

Isn't this an ideal use case for copr? 
Or is the lack of s390x (and non emulated armv7) there too much of a hurdle?

kevin


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

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

[Luca Boccassi]

> On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:
> 
> I was thinking more about this proposal over the past weekend and
> where I keep ending up is that this is really optimizing for a small
> use case by touching ELF metadata all over the system.  And that
> strikes me as pretty invasive, so is it worth the tradeoffs and risks
> and such?

Well, whether it's small or not is subjective, I think. CBL-Mariner was the 
first distro to add support for this, and I can tell you with certainty that 
it's not small at all for the internal use cases where this is employed.
I mean build-ids too, if everything goes well and nothing ever crashes or needs 
debugged, are never needed. So one could say that even adding that to the ELF 
header is touching everything for a small use case. But I don't think it would 
be fair, because even if most of the times things are just working and you 
don't need to debug anything, it's when things start to go very wrong that you 
want to have as much help and as many tools at your disposal as possible.
Even if it was a small use case, support engineers and maintainers have such a 
hard job already, it seems to me it would be worth making some of it easier if 
the cost is just a few KBs in disk space in the typical scenario.

> Debugging is a pain, and anything to make that easier is better.  It
> has been stated multiple times that the information needs to be in the
> ELF header because containers and images may lack an RPM database.
> Fair, but what about the users that both want a container and image
> without the RPM database and systemd-coredump?  They still have all of
> their ELF files with this information that they removed in other ways.
> Do we provide those users with a script to strip .gnu.notes from
> everything or is that even a use case of concern?
>
> Efforts to get the system very small for container and image use has
> been a goal for a while.  And sure we're not talking about a lot of
> data, but that's now.  The size of everything only grows, so is that
> something to consider with the implementation of this feature?

Note that systemd-coredump is on the host, not in the container. This is one of 
the points of the proposal, and mentioned in the wiki: core files are collected 
and analyzed on the host, not in container guests, so one of the reasons an 
rpm/dpkg/whatever database won't help is because they don't necessarily match. 
So users don't have to include systemd-coredump in their container images at 
all, before or after this proposal.

Moreover, the difference in size in a typical small container between an 
rpm/dpkg/whatever database and the overhead of these notes is several orders of 
magnitudes - several megabytes vs several kilobytes. Again this comparison is 
done on the wiki: 
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#Why_not_just_use_the_rpm_database.3F

Finally, if one is really convinced that they don't need this and want to strip 
it out, there's not even the need for a script, objcopy supports removing notes 
out of the box with objcopy --remove-section.

> Another thing I thought about were reproducible builds.  Does this
> impact reproducible builds and if so, how do we handle that?

It does not impact that, this is covered on the wiki: 
https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#Won.27t_this_affect_the_Reproducible_Builds_effort.3F

> I would feel more comfortable with this proposal if the data for
> systemd-coredump was not part of the ELF metadata.  Or if it
> absolutely must be part of the ELF metadata, users should know how it
> can be removed.  I would also vote for a format other than JSON, but
> that's just me.

At MSFT we tried several options, but as far as we could tell the only way to 
be 100% certain that the metadata is always included automatically in the 
corefile if present in the binary is by using an allocated ELF PT_NOTE. Note 
that systemd-coredump is just one of the possible consumers - again at MSFT we 
have other internal tooling consuming it as well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Summary/Minutes from today's FESCo Meeting (2021-11-08)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting/2021-11-08/fesco.2021-11-08-19.02.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting/2021-11-08/fesco.2021-11-08-19.02.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting/2021-11-08/fesco.2021-11-08-19.02.log.html

* #2682 F36 Change: Openldap-2.5  (zbyszek, 19:05:18)
  * AGREED: Change is approved, with the proviso that the dnf upgrade
must go through, and the service will refuse to start until the data
is successfully migrated. Change owner will figure out the best way
to communicate this to the admin (+6, 0, 0)  (zbyszek, 19:23:28)

* #2684 F36 Change: Drop NIS(+) support from PAM  (zbyszek, 19:24:39)
  * AGREED: NIS/NIS+ will be removed from the distro in F36, contingent
upon the inclusion of documentation and/or migration tools being
made prominently available (+6, 0, 0)  (zbyszek, 19:42:42)
  * ACTION: besser82[m] will initiate the work on the article  (zbyszek,
19:44:30)
  * ACTION: StephenGallagher will help too  (zbyszek, 19:45:24)

* #2687 F36 Change: Package information on ELF objects  (zbyszek,
  19:45:59)
  * AGREED: Let's discuss this more on the mailing list and revisit next
week.  (zbyszek, 19:51:20)

* Next week's chair  (zbyszek, 19:51:26)
  * ACTION: StephenGallagher will chair the next meeting  (zbyszek,
19:53:10)

* Open Floor  (zbyszek, 19:53:15)

Meeting ended at 19:56:28 UTC.




Action Items

* besser82[m] will initiate the work on the article
* StephenGallagher will help too
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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​

[Ondrej Mosnacek]

On Mon, Nov 8, 2021 at 4:55 PM Miro Hrončok  wrote:
> 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-11-08.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
> 
> stockfish orphan   1 weeks ago

Going to take a stab at this one...

--
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

No responsive maintainer xenithorb

[Juan Orti via devel]

Hi,

Anyone knows if xenithorb is still active in Fedora? It's been years since the 
last update of the package btrbk and he/she hasn't replied to my question in 
bugzilla [1].

I've created the non-responsive maintainer bug [2]. If anyone knows anything, 
please, ping me. I'm interested in updating btrbk and I can maintain it if 
needed.

Thank you.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1765928#c18
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2021317
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[David Cantrell]

On Thu, Oct 28, 2021 at 09:30:18PM +0200, Lennart Poettering wrote:

On Do, 28.10.21 12:10, David Cantrell (dcantr...@redhat.com) wrote:


Thanks for revising the change proposal and filling in more details.
After reading through it, I have some questions:

1) The proposal notes that users tend to combine built packages from
different distributions.  Even in the current environment, do we care
about those use cases without also getting a reproducer for Fedora?


I'd see it this way: ultimately, if this gets adopted by multiple
distros this annotation will helps us separating out the reports by
distro, and then ignore everything but fedora. i.e. if someone deploys
a debian or ubuntu container on a fedora host this should be something
we shouldn't be bothered with supporting. But right now a coredump
generated that way won't tell us much about the situation. But once
this spec is adopted this becomes easy: if we get a report we'll
immediately see that the code that aborted was actually from a
different distro, and we can point the reporter to that and tell them
politely to ask the other distro for help, or alternatively invest the
time and reproduce the issue with the binary provided by fedora
instead.

So, having this info around us allows us to be more efficient with
"not caring" for non-fedora issues.


For me, I feel that in a situation like that where a user has
submitted a bug report that implies using a binary from some other
distribution will lead me to ask "ok, but does this happen with the
packages provided in Fedora?  If so, how can I reproduce the problem
locally?"  So while these scenarios are described in the proposal, are
they something that Fedora is trying to support?


Well, I don't think Fedora has to care about crashes in other distro's
binaries. we have more than enough to look after anyway. But I do think
we should make it easier to detect this situation and more easily
provide helpful pointers how to find someone else who might be
interested or what to do to make fedora interested.


3) The proposal notes making crash reporting more user-readable.  NVRs
instead of Build-IDs, for instance.  Why can't systemd ask debuginfod
for that information for reporting?  Why does this need to be embedded
in the ELF objects?  If it's a value-add, then it could happen if
debuginfod is set up and just have it fall back on the current
reporting mechanism.


We want to be able to do things generically in an offline fashion in
systemd-coredump. I.e. we run the coredump analyzer in a tight
sandbox, and we want quick answers without relying on the network.

The goal of systemd-coredump is to make a coredump something that is
primarily a relatively cheapish log event, and were we do analysis as
much as possible locally, automatically, securely, in privacy and
quickly. If we'd always talk to the network we'd have to open our
sandbox quite a bit, we'd be dependent on external services, we'd leak
some data to the outside, we'd be unreliable and slower — and all that
even though we are interested in only a single string of data
ultimately.

(I think debuginfod is excellent, but I think it would probably be a
consumer of this spec, not a replacement. for example, consider that
the spec has a suggested field 'debugInfoUrl' already, which would
inform debugging tools about the debuginfod servers to talk to to
acquire extended debug info data)


I was thinking more about this proposal over the past weekend and
where I keep ending up is that this is really optimizing for a small
use case by touching ELF metadata all over the system.  And that
strikes me as pretty invasive, so is it worth the tradeoffs and risks
and such?

Debugging is a pain, and anything to make that easier is better.  It
has been stated multiple times that the information needs to be in the
ELF header because containers and images may lack an RPM database.
Fair, but what about the users that both want a container and image
without the RPM database and systemd-coredump?  They still have all of
their ELF files with this information that they removed in other ways.
Do we provide those users with a script to strip .gnu.notes from
everything or is that even a use case of concern?

Efforts to get the system very small for container and image use has
been a goal for a while.  And sure we're not talking about a lot of
data, but that's now.  The size of everything only grows, so is that
something to consider with the implementation of this feature?

Another thing I thought about were reproducible builds.  Does this
impact reproducible builds and if so, how do we handle that?

I would feel more comfortable with this proposal if the data for
systemd-coredump was not part of the ELF metadata.  Or if it
absolutely must be part of the ELF metadata, users should know how it
can be removed.  I would also vote for a format other than JSON, but
that's just me.

Thanks,

--
David Cantrell  Red Hat, Inc. | Boston, MA |
EST5EDT
___

Re: Orphaned packages looking for new maintainers​

[Gwyn Ciesla via devel]

I've taken it, but I can let you work on the FTBFS if you like. Or I can. 
Whichever. :)

-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Monday, November 8th, 2021 at 11:24 AM, Artur Frenszek-Iwicki 
 wrote:

> > SDL2_gfx ignatenkobrain, orphan 1 weeks ago
> 

> I'd like to pick this up, but I have next to zero experience working with 
> autotools,
> 

> so I'll defer adopting the package until I have a working fix for the FTBFS.
> 

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

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

> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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

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

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

[David Cantrell]

On Fri, Oct 29, 2021 at 10:17:09PM +, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Oct 29, 2021 at 09:53:25PM +0200, Lennart Poettering wrote:

On Fr, 29.10.21 13:57, David Cantrell (dcantr...@redhat.com) wrote:

> Has there been any consideration for potential security risks with
> regards to the data in this string?  Of concern to me are encoding
> formats, size limits or reporting, and structure formats.  The
> proposal notes JSON, which has been involved in security related
> problems in the past.

One of the reasons we are sticking to JSON here is so that we can use
battle-tested parsers we already use for other stuff. you want a
parser that is already used, verified, tested elsewhere, and JSON
makes that easy. A homegrown parser of an entirely new special purpose
format is a lot more problematic security-wise.


In particular, the implementation in systemd is undergoing continuous
fuzzing in oss-fuzz, so we hope any simple issues have been already
caught.


I wasn't really concerned with the reliability of the parser, but
rather the necessity of JSON in the first place.  The more layers
anything has, the higher the risk.

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Automated formal verification of RPM packages

[Jerry James]

On Mon, Nov 8, 2021 at 1:23 AM Kamil Dudka  wrote:
> Formal verification of RPM packages with CBMC, Divine, and Symbiotic is now
> easier than ever before!  csmock plug-ins for these tools are now available
> in stable Fedora releases.  The plug-ins are still experimental and they have
> some technical limitations:

Nice!  Thanks for working on this.  I tried to use the csmock plugin,
but got this at the end of the build (on an x86_64 F34 host, building
for fedora-35-x86_64):

+ for file in 
/tmp/csmockadxnd155/metamath-0.198-1.fc36/debug/raw-results/builddir/cbmc-capture/pid-*.out
+ cbmc-convert-output -a
/bin/sh: line 4: cbmc-convert-output: command not found

!!! 2021-11-08 10:02:57error: post-process hook failed

The problem appears to be that csmock-plugin-cbmc doesn't require cbmc
or cbmc-utils:

$ rpm -q --requires csmock-plugin-cbmc
csexec
csmock-common(python3)
python(abi) = 3.9
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1

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: F35 no USB after today's updates

[Sergio Pascual]

El lun, 8 nov 2021 a las 15:02, Sergio Pascual ()
escribió:

>
>
> El lun, 8 nov 2021 a las 14:36, Stephen John Smoogen ()
> escribió:
>
>>
>> Can you try downgrading to the F34 linux-firmware and see if the f34
>> kernel sees the chipset again?
>>
>>
>>
> I have downgraded everything to the released F35 and now it works, with
> kernel 5.14.16-301 and linux-firmware-20210919-125
>
>
>
I have updated the system from F35 without updates to fully updated and the
problem has disappeared. I have updated in small groups of packages and
rebooted afterwards to check USB. Whatever happened, it is fixed now. My
current kernel is 5.14.16-301  but 5.15.15-300 works also

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

[Simo Sorce]

On Sat, 2021-11-06 at 07:43 +, Daniel Alley wrote:
> > On Wed, Aug 11, 2021 at 10:03:50PM +0200, Marek Marczykowski-
> > Górecki wrote:
> > I do think we should drop drpms or make them more useful, but I
> > don't
> > think there's any security angle here. (see below)
> > 
> > drpms work by downloading the delta, then using it + the version
> > you
> > have installed to recreate the signed rpm (just like you downloaded
> > the
> > full signed update) and then the gpg signature is checked of that
> > full rpm,
> > just like one you downloaded. If the drpm is tampered with it won't
> > reassemble and it will fall back to the full signed rpm.
> 
> Sorry to resurrect this thread.
> 
> Another issue - which is not per-se a security issue but it's still a
> problem - is that deltarpm uses md5 checksums pervasively.  They're
> everywhere.  And it uses its own implementation of md5 which doesn't
> respect FIPS, so even when the user has *explicitly* configured their
> system to not use md5 for anything security-relevant, libdeltarpm
> won't know or care. 

md5 used as a checksum to only detect network transmission issues is
not a problem, and is not under the purview of the FIPS certification.

As mentioned above the actual packages are still finally reassembled
and the signature checked, so that is what matters in terms of security
(those algorithms and computations need to be FIPS approved and the
implementation certified).

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-IoT-36-20211108.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

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

New failures (same test not failed in Fedora-IoT-36-20211027.0):

ID: 1056905 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1056905
ID: 1056906 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1056906
ID: 1056920 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1056920

Old failures (same test failed in Fedora-IoT-36-20211027.0):

ID: 1056875 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1056875
ID: 1056895 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1056895

Skipped non-gating openQA tests: 26 of 31
-- 
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: Orphaned packages looking for new maintainers​

[Artur Frenszek-Iwicki]

> SDL2_gfx  ignatenkobrain, orphan   1 weeks ago
I'd like to pick this up, but I have next to zero experience working with 
autotools,
so I'll defer adopting the package until I have a working fix for the FTBFS.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Long-running side tag for porting Fedora to C99 (no implicit decls)

[Florian Weimer]

* Kevin Kofler via devel:

> Florian Weimer wrote:
>> Eventually, we'll have to fix the Fedora packages if there's no upstream
>> release with the fixes.
>
> We just have to add -Wno-error=implicit-function-declaration to the build 
> flags of the offending packages (same as for format-security).

For some packages, that is unfortunately more difficult than fixing the
actual source of the incompatibility.

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

[Test-Announce] Fedora-IoT 36 RC 20211108.0 nightly compose nominated for testing

[rawhide]

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

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_36_RC_20211108.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_36_RC_20211108.0_General

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

Join the Release Party for Fedora Linux 35 - Nov. 12 - 13

[Marie Nordin]

Hi Fedora Friends,

Fedora Linux 35 is now officially available — read the announcement on Fedora
Magazine [1]. Join us at
the upcoming Release Party for Fedora Linux 35, happening later this week
Friday, Nov. 12, and Saturday, Nov. 13. Register here
[2].

Learn about the newest release of Fedora and latest community activity. View
the full schedule here[3].

There will be sessions on:

• Fedora Workstation 35

• Element for the Fedora community

• Outreach and Websites & Apps teams revamps

• "35 Release in 30 minutes" from the Fedora Project Leader, Matthew Miller

• ... and more!

A HUGE thanks and congratulations to everyone who helped make this
possible. Hope to see you there!

Links:

[1] Fedora Magazine Fedora Linux 35 release announcement:
https://fedoramagazine.org/announcing-fedora-35/

[2] Fedora Linux 35 release party registration:
https://hopin.com/events/fedora-linux-35-release-party/registration

[3] Fedora Linux 35 release party schedule:
https://fedoraproject.org/wiki/Fedora_Linux_35_Release_Party_Schedule


--

Marie Nordin

Fedora Community Action and Impact Coordinator

Red Hat  • Fedora Project 

She/Her/Hers

IRC/Element: riecatnor



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

[Robbie Harwood]

Stephen John Smoogen  writes:

> On Mon, 8 Nov 2021 at 04:32, Michael Schroeder  wrote:
>>
>> On Sat, Nov 06, 2021 at 07:43:02AM -, Daniel Alley wrote:
>> > Another issue - which is not per-se a security issue but it's still a 
>> > problem - is that deltarpm uses md5 checksums pervasively.  They're 
>> > everywhere.  And it uses its own implementation of md5 which doesn't 
>> > respect FIPS, so even when the user has *explicitly* configured their 
>> > system to not use md5 for anything security-relevant, libdeltarpm won't 
>> > know or care.
>>
>> They are used as a consistency check, it might as well use crc32.
>> So I don't see why FIPS is a concern for you.
>>
>
> In order to get the overall system to be FIPS (and equivalent EU/RU/CN
> ones) certified all the implementations of various functions have to
> be audited and reviewed. Some must be able to be turned off no matter
> what. It doesn't matter if 99 of the 100 versions of md5um are only
> for consistency, they must be able to be turned off/not used and not
> affect the system.

I don't think that's quite accuroate.  If the crypto primitive isn't
being used for security, then FIPS isn't interested - FIPS is only
certifying the cryptography used, and this isn't it.  (It's non-FIPS
relevant.)

This leads to a very common workaround for legacy cryptosystems of
tunneling the "bad" crypto in something else: one example is interacting
with RC4 and NTLM, where they're still used but over a tunnel (TLS, VPN,
etc.) that doesn't expose them.

Be well,
--Robbie


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

Planned Outage - bodhi.fedoraproject.org - 2021-11-10 8:00 UTC External

[Adam Saleh]

Planned Outage - bodhi.fedoraproject.org - 2021-11-10 08:00 UTC

There will be an outage starting on monday at 2021-11-10 08:00 UTC,
which will last approximately 2 hours.

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

date -d '2021-11-10 08:00UTC'

Reason for outage:

Bodhi will be upgraded to 5.7.1.

This is a repeat after I missed the outage window on monday.

Affected Services:

bodhi / updates.fedoraproject.org may be down or unresponsive during
the upgrade window

Ticket Link:

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

Please join #fedora-admin or #fedora-noc on chat.libera.net
or add comments to the ticket for this outage above.
___
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

Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

[Kevin Kofler via devel]

Florian Weimer wrote:
> Eventually, we'll have to fix the Fedora packages if there's no upstream
> release with the fixes.

We just have to add -Wno-error=implicit-function-declaration to the build 
flags of the offending packages (same as for format-security).

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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Kevin Kofler via devel]

Andreas Schneider wrote:
> I have electron building offline for Fedora, you can find it here:
> 
> https://build.opensuse.org/package/show/network:im:signal/nodejs-electron

I see from the presence of electron-13-openh264-format-security.patch that 
you are building the bundled OpenH264. This is not going to be allowed on 
Fedora: only the openh264 repository provided by Cisco is allowed to 
distribute OpenH264 for Fedora due to how the H.264 patent license works. 
And as I understand it, you cannot even build against a system OpenH264 
(because that repository is not enabled in the build system). The only 
packages that support OpenH264 within Fedora are those that can dlopen it at 
runtime, which Chromium cannot.

The build of openh264 is also controlled by enable_proprietary_codecs, which 
you unconditionally set to true. So your approach is not going to work on 
Fedora. In fact, you are not even supposed to include openh264 in the 
tarball at all. At least in qt5-qtwebengine, I added an rm -rf line to the 
tarball cleanup script that removes it (some time ago, back when upstream 
had added the bundled copy), I have not checked whether the chromium package 
does that too, but in any case, it should.

This is also another reason why just swapping out ffmpeg will not give you 
fully working support for patent-encumbered codecs, whereas the qt5-
qtwebengine-freeworld approach (just rebuilding the whole thing) will. (qt5-
qtwebengine-freeworld in RPM Fusion does include the bundled OpenH264, as 
there is nothing preventing shipping non-Cisco builds there, the copyright 
license is perfectly fine, it is the patent license that only applies to 
builds shipped by Cisco.) FFmpeg does not include a H.264 encoder at all. It 
has support for using an external libx264, but Chromium does not support 
using that libx264 support, nor using libx264 directly. Instead, Chromium 
relies on OpenH264 for encoding (probably because that ensures that the 
bitstream will only use features that are also supported by the OpenH264 
decoder used by some other browsers, even though Chromium does not use the 
decoder from OpenH264, only the encoder). Hence, Chromium uses OpenH264 
directly (for encoding), which is a compile-time decision based on 
enable_proprietary_codecs and not affected by replacing FFmpeg at all.

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

Re: Orphaned packages looking for new maintainers​

[Daniel P . Berrangé]

On Mon, Nov 08, 2021 at 04:52:38PM +0100, Miro Hrončok wrote:
> 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-11-08.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
> 
> netcf berrange, orphan 1 weeks ago

I do *not* intend to pick up ownership of this. It is dead upstream and
we're letting it die off from F35 onwards, since we don't believe it is
used by anything now that libvirt dropped its usage.

I'm merely retaining commit privs in case older branches need patching

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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Neal Gompa]

On Mon, Nov 8, 2021 at 11:50 AM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
>
> > On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel
> >  wrote:
> >>
> >> On 08/11/2021 10:12, Andreas Schneider wrote:
> >> > I'm interested in this, as I try to package electron for Fedora.
> >>
> >> Electron can't be build completely from sources without downloading
> >> pre-built binaries/blobs from npm.
> >>
> >
> > This is not true anymore.
>
> As I understand it, it was never true, in the sense that it was always
> *possible* to build Electron completely from sources. The issue was that the
> upstream build system worked against you there and that you had to jump
> through a lot of hoops to use components built from source instead of blobs
> downloaded from somewhere. Each of the Electron stages was just downloading
> the next lower layer as a blob, which in turn included the next lower layer
> as a blob. In particular, each Electron app bundled the Electron blob which
> was just downloaded from Electron at build time, and each Electron build
> bundled the Chromium fork blob which was also downloaded as a blob during
> the build. (I think there were even one or two additional blob layers that I
> have forgotten. The minified JavaScript blobs you mention were probably also
> already part of it.) I do not know to what extent, if at all, this has been
> improved since last I checked.

Electron can use vanilla Chromium source trees to build now rather
than a prebuilt libchromiumcontent library.



-- 
真実はいつも一つ！/ 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: deltarpm usefulness?

[Matthew Miller]

On Sun, Nov 07, 2021 at 05:19:39PM -0600, Robby Callicotte via devel wrote:
> Having deltarpms turned on by default would seem to make the most sense in 
> the 
> IOT/Edge space, but in order to reap the most benefit these systems would 
> have 
> to download the deltas daily. 

Fedora IoT uses rpm-ostree, so gets deltas in a different way.

-- 
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: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Kevin Kofler via devel]

Neal Gompa wrote:

> On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel
>  wrote:
>>
>> On 08/11/2021 10:12, Andreas Schneider wrote:
>> > I'm interested in this, as I try to package electron for Fedora.
>>
>> Electron can't be build completely from sources without downloading
>> pre-built binaries/blobs from npm.
>>
> 
> This is not true anymore.

As I understand it, it was never true, in the sense that it was always 
*possible* to build Electron completely from sources. The issue was that the 
upstream build system worked against you there and that you had to jump 
through a lot of hoops to use components built from source instead of blobs 
downloaded from somewhere. Each of the Electron stages was just downloading 
the next lower layer as a blob, which in turn included the next lower layer 
as a blob. In particular, each Electron app bundled the Electron blob which 
was just downloaded from Electron at build time, and each Electron build 
bundled the Chromium fork blob which was also downloaded as a blob during 
the build. (I think there were even one or two additional blob layers that I 
have forgotten. The minified JavaScript blobs you mention were probably also 
already part of it.) I do not know to what extent, if at all, this has been 
improved since last I checked.

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

Re: Orphaned packages looking for new maintainers​

[Sérgio Basto]

On Mon, 2021-11-08 at 16:52 +0100, Miro Hrončok wrote:
> platform  orphan, sergiomb 4
> weeks ago

I took it because is needed by libcec , I was already maintainer of the
package 

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

Re: Orphaned packages looking for new maintainers​

[Didik Supriadi]

Hi,

On 11/8/21 22:52, Miro Hrončok wrote:

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-11-08.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
 


joni  orphan 1 weeks ago
...
options 0 weeks ago


I've unorphan both of those package.


pam_mount lupinix, orphan, steve   1 weeks ago
passenger kanarip, orphan 1 weeks ago
perl-Nagios-Plugin    jpo, orphan, ppisar 4 weeks ago
perl-OpenOffice-UNO   filabrazilska, orphan, scenek 1 
weeks ago

php-voms-admin    orphan 4 weeks ago
plasma-applet-redshift-control    kde-sig, lupinix, orphan 1 weeks ago
platform  orphan, sergiomb 4 weeks ago
postgres-decoderbufs  fjanus, hhorak, orphan, 1 weeks ago
  panovotn
ptpd  jondkent, orphan 4 weeks ago
purple-mattermost orphan 4 weeks ago
python-email_reply_parser orphan, python-sig 6 weeks ago
python-power  orphan, python-sig 6 weeks ago
python-pylibmc    abompard, orphan, pjp 1 weeks ago
python-sockjs-tornado orphan, python-sig 4 weeks ago
qotd  orphan 4 weeks ago
quasselgrep   orphan 4 weeks ago
qwtpolar  orphan 1 weeks ago
rubygem-simple-navigation orphan 1 weeks ago
rubygem-six   orphan 1 weeks ago
rust-ruma-events  orphan, rust-sig 1 weeks ago
seahorse-sharing  gnome-sig, orphan, stefw 1 weeks ago
shuffledns    go-sig, orphan 1 weeks ago
spasm-ng  orphan 4 weeks ago
stockfish orphan 1 weeks ago
sugar-visualmatch orphan 1 weeks ago
tfdocgen  orphan 4 weeks ago
tilp2 orphan 4 weeks ago
trafshow  orphan 1 weeks ago
treefrog-framework    orphan 4 weeks ago
truth orphan 1 weeks ago
ugene orphan 1 weeks ago
uglify-js1    nodejs-sig, orphan, patches 4 weeks ago
unshield  orphan 4 weeks ago
vanessa_logger    orphan 1 weeks ago
vgrive    orphan 1 weeks ago
wxpdfdoc  orphan, swt2c 1 weeks ago
xfce4-equake-plugin   cheese, orphan 1 weeks ago
xoreos-tools  orphan 4 weeks ago
yarock    kde-sig, martinkg, orphan 6 weeks ago
yecht orphan 1 weeks ago
yydebug   orphan 1 weeks ago
zgrab2    orphan 4 weeks ago

The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2021-11-08.txt

See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at 
https://packager-dashboard.fedoraproject.org/orphan


Affected (co)maintainers (either directly or via packages' dependencies):
abbra: esc
ablu: SDL2_gfx
abompard: python-pylibmc
acaringi: jacoco
akoutsou: golang-github-kolo-xmlrpc
amluto: jacoco
asaleh: dummy-test-package-rubino
athmane: afpfs-ng
berrange: netcf
bofh80: golang-github-kolo-xmlrpc
bowlofeggs: erlang-riak_core, erlang-exometer_core, erlang-riak_api, 
erlang-protobuffs, erlang-triq

cdorney: esc
cfu: esc
cheese: xfce4-equake-plugin
cipherboy: esc
ckelley: esc
clime: python-pylibmc
cockpit: golang-github-kolo-xmlrpc
codeblock: erlang-protobuffs, erlang-triq
copr-sig: python-pylibmc
cra: SDL2_gfx
dmoluguw: esc
dturecek: python-pylibmc
dwalluck: gnu-getopt
eclipseo: golang-github-kolo-xmlrpc, golang-github-beevik-ntp, 
golang-github-ema-qdisc, golang-github-mdlayher-wifi, 
gol

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Kevin Kofler via devel]

Kevin Kofler via devel wrote:
> And does Chromium fully work with HTML5 video if you do that? In
> particular, does it correctly report the list of supported codecs to the
> website? Last I checked, Chromium hardcoded the list of supported codecs
> at compile time (and there were actually only 2 hardcoded lists in the
> source code, one of which was selected at compile time depending on
> whether the "proprietary_codecs" flag was set at compile time or not; no
> attempt whatsoever was made to query ffmpeg for what codecs it actually
> supports, neither at compile time nor at runtime), so the only way to
> replace the list was to replace the entire Chromium (which is what
> qt5-qtwebengine-freeworld does for qt5-qtwebengine: it replaces the entire
> QtWebEngine shared libraries including the entire bundled Chromium).

PS: And, also last I checked, even MP3 (whose patents expired a few years 
ago) was still considered a "proprietary codec" by Chromium. (The Fedora 
Chromium package, but not the qt5-qtwebengine one, has a patch to enable MP3 
support, but I think it does not actually touch the supported codec list, it 
only enables the codec in the bundled ffmpeg. And to do so, it also requires 
several files related, according to their names, to other patent-encumbered 
codecs such as AAC, files that I was not comfortable with shipping in qt5-
qtwebengine when I last looked into the issue, which was before I handed 
over qt5-qtwebengine maintenance to Rex Dieter.)

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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Kevin Kofler via devel]

Andreas Schneider wrote:
> there are several packages in the distribution which require FFMPEG
> (libavformat, libavcodec, etc.), one of them being chromium. The package
> could be created in a way that you can easily replace it with a version
> from rpmfusion to get to the full encoder/decoder set including H264 etc.

And does Chromium fully work with HTML5 video if you do that? In particular, 
does it correctly report the list of supported codecs to the website? Last I 
checked, Chromium hardcoded the list of supported codecs at compile time 
(and there were actually only 2 hardcoded lists in the source code, one of 
which was selected at compile time depending on whether the 
"proprietary_codecs" flag was set at compile time or not; no attempt 
whatsoever was made to query ffmpeg for what codecs it actually supports, 
neither at compile time nor at runtime), so the only way to replace the list 
was to replace the entire Chromium (which is what qt5-qtwebengine-freeworld 
does for qt5-qtwebengine: it replaces the entire QtWebEngine shared 
libraries including the entire bundled Chromium).

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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Kevin Kofler via devel]

Dominik 'Rathann' Mierzejewski wrote:
> Chromium was checked by legal. I'm not aware of any other Fedora
> packages bundling a subset of FFmpeg.

qt5-qtwebengine does it too, using a fork of the cleanup script from the 
Chromium package.

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

Self Introduction: Alexander Bulimov

[Alexander Bulimov]

Hello!

I work at Facebook on the team dealing with all things NTP/PTP, including
the OCP Time Appliance Project.

We've already open-sourced lots of related software, Davide Cavalca kindly
packaged most of it, and from now on I'll be actively supporting and
updating it.

My focus for now will be on all the stuff under
github.com/facebookincubator/ntp, github.com/facebookincubator/ptp,
github.com/Orolia2s/oscillatord, and dependencies.

The plan is to maintain it with Davide's help, and provide regular updates
as the Time Appliance project is in the very active phase now.

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

Java-WebSocketorphan   1 weeks ago
SDL2_gfx  ignatenkobrain, orphan   1 weeks ago
afpfs-ng  orphan   1 weeks ago
arduino-ctags orphan   1 weeks ago
asl   orphan   1 weeks ago
bitlbee-discord   orphan   4 weeks ago
bytelist  lef, orphan  1 weeks ago
cAudioorphan   4 weeks ago
cataclysm-dda orphan   1 weeks ago
chaos-client  go-sig, orphan   1 weeks ago
chck  fale, orphan, zvetlik1 weeks ago
concurrent-trees  hhorak, orphan   1 weeks ago
conky-manager orphan   1 weeks ago
couchdb   orphan   1 weeks ago
crcimgorphan   4 weeks ago
crlfuzz   go-sig, orphan   1 weeks ago
cuetools  orphan   1 weeks ago
dummy-test-package-rubino asaleh, orphan, packagerbot, 1 weeks ago
  patrikp, scoady, wwoods
edac-utilsorphan   1 weeks ago
elog  orphan   4 weeks ago
erlang-certifierlang-maint-sig, orphan 2 weeks ago
erlang-cf erlang-maint-sig, orphan 2 weeks ago
erlang-cth_readable   erlang-maint-sig, orphan 2 weeks ago
erlang-erlware_commonserlang-maint-sig, orphan 2 weeks ago
erlang-eunit_formatters   erlang-maint-sig, orphan 2 weeks ago
erlang-exometer_core  orphan   1 weeks ago
erlang-hex_core   erlang-maint-sig, orphan 2 weeks ago
erlang-protobuffs orphan   1 weeks ago
erlang-providers  erlang-maint-sig, orphan 2 weeks ago
erlang-relx   erlang-maint-sig, orphan 2 weeks ago
erlang-riak_api   bowlofeggs, erlang-maint-sig,1 weeks ago
  orphan
erlang-riak_core  bowlofeggs, erlang-maint-sig,1 weeks ago
  orphan
erlang-ssl_verify_fun erlang-maint-sig, orphan 2 weeks ago
erlang-triq   orphan   1 weeks ago
esc   orphan   1 weeks ago
fennelepel-packagers-sig, lua- 1 weeks ago
  packagers-sig, orphan
forbidden-apisjvanek, orphan   1 weeks ago
freemarkerorphan   1 weeks ago
gauche-gl orphan   4 weeks ago
gdata-sharp   moezroy, orphan, tpokorra1 weeks ago
gfm   orphan   4 weeks ago
gnome-nibbles gnome-sig, orphan1 weeks ago
gnu-getoptdwalluck, mizdebsk, orphan   1 weeks ago
golang-github-beevik-ntp  go-sig, orphan   0 weeks ago
golang-github-dgraph-io-badgerorphan   4 weeks ago
golang-github-dgraph-io-  orphan

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Andreas Schneider]

On Monday, November 8, 2021 3:43:37 PM CET Vitaly Zaitsev via devel wrote:
> On 08/11/2021 15:35, Neal Gompa wrote:
> 
> > I've done an offline build with some prep work upfront, yes.
> 
> 
> Fully offline with rebuilding all JS dependencies from sources?
> 
> All minified JS blobs must be rebuild from sources on Fedora infra 
> instead of downloading them from npm with direct links.
> 
> 
> > It's not automatically a thing, but it is possible.
> 
> 
> Can you show the SPEC please?

I have electron building offline for Fedora, you can find it here:

https://build.opensuse.org/package/show/network:im:signal/nodejs-electron

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

[SONAME BUMP] libcint 5.0.0 / qcint 5.0.0

[Susi Lehtola]

Hi,


libcint 5.0.0 and qcint 5.0.0 have been released, with a soname bump.
I'll be pushing the update in one week to rawhide. The only affected
package is python-pyscf, which is also mine, and which I'll be similarly
updating to version 2.0.1 that has also been released recently.
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 no USB after today's updates

[Peter Robinson]

On Mon, Nov 8, 2021 at 1:36 PM Stephen John Smoogen  wrote:
>
> On Mon, 8 Nov 2021 at 08:16, Sergio Pascual  wrote:
> >
> >
> > El lun, 8 nov 2021 a las 13:39, Stephen John Smoogen () 
> > escribió:
> >>
> >> On Mon, 8 Nov 2021 at 06:53, Sergio Pascual  wrote:
> >> >
> >> > Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf 
> >> > updated' and rebooted. After the reboot, all my USBs are disabled. No 
> >> > mouse, no keyword.
> >> > I know my hardware works because the keyboard works in grub, and the 
> >> > light of my optical mouse in on until some errors appear in the kernel 
> >> > during boot.
> >> >
> >> > I have tried:
> >> > kernel-5.14.15-200.fc34.x86_64
> >> > kernel-5.14.15-300.fc35.x86_64
> >> > kernel-5.14.16-301.fc35.x86_64
> >> >
> >>
> >> The developers will need to know what the exact motherboard/laptop
> >> version and manufacturer you have in order to diagnose this issue. My
> >> initial guess is that since the f34 kernel also fails, that the
> >> problem is with a firmware module and whatever the motherboard is
> >> expecting to use. [The fact that it is only finding USB2 says that
> >> either the system is really old or that it is trying to fail to its
> >> lowest working value.]
> >>
> >>
> >
> >
> > My workstation is a Dell Precision Tower 7910.
> >
> > lscpi says I have the following serial bus controllers
> >
> > 00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI 
> > Host Controller (rev 05)
> > 00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB 
> > Enhanced Host Controller #2 (rev 05)
> > 00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB 
> > Enhanced Host Controller #1 (rev 05)
> >
>
> Can you try downgrading to the F34 linux-firmware and see if the f34
> kernel sees the chipset again?

Not sure what downgrading linux-firmware will do here a the Intel USB
controllers don't require firmware.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Neal Gompa]

On Mon, Nov 8, 2021 at 9:44 AM Vitaly Zaitsev via devel
 wrote:
>
> On 08/11/2021 15:35, Neal Gompa wrote:
> > I've done an offline build with some prep work upfront, yes.
>
> Fully offline with rebuilding all JS dependencies from sources?
>
> All minified JS blobs must be rebuild from sources on Fedora infra
> instead of downloading them from npm with direct links.
>
> > It's not automatically a thing, but it is possible.
>
> Can you show the SPEC please?
>

I haven't done it in the form of a spec file recently. It hasn't been worth my
time to do that yet with other blockers. I don't have anything I can
share at this time.



--
真実はいつも一つ！/ 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: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Vitaly Zaitsev via devel]

On 08/11/2021 15:35, Neal Gompa wrote:

I've done an offline build with some prep work upfront, yes.


Fully offline with rebuilding all JS dependencies from sources?

All minified JS blobs must be rebuild from sources on Fedora infra 
instead of downloading them from npm with direct links.



It's not automatically a thing, but it is possible.


Can you show the SPEC please?

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

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

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 67/141 (aarch64), 108/206 (x86_64)

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

ID: 1056297 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1056297
ID: 1056580 Test: aarch64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1056580

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

ID: 1056099 Test: x86_64 Server-dvd-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1056099
ID: 1056102 Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/1056102
ID: 1056142 Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/1056142
ID: 1056144 Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/1056144
ID: 1056145 Test: x86_64 Workstation-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1056145
ID: 1056153 Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1056153
ID: 1056169 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1056169
ID: 1056171 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1056171
ID: 1056191 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1056191
ID: 1056229 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1056229
ID: 1056310 Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1056310
ID: 1056311 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/1056311
ID: 1056314 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1056314
ID: 1056328 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1056328
ID: 1056354 Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1056354
ID: 1056355 Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/1056355
ID: 1056363 Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1056363
ID: 1056366 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1056366
ID: 1056378 Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/1056378
ID: 1056381 Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/1056381
ID: 1056383 Test: aarch64 universal upgrade_2_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1056383
ID: 1056385 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1056385
ID: 1056405 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1056405
ID: 1056410 Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1056410
ID: 1056418 Test: aarch64 universal upgrade_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1056418
ID: 1056420 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1056420
ID: 1056430 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1056430
ID: 1056431 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1056431
ID: 1056432 Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1056432
ID: 1056433 Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1056433
ID: 1056434 Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1056434
ID: 1056435 Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1056435
ID: 1056436 Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1056436
ID: 1056437 Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1056437
ID: 1056438 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1056438
ID: 1056439 Test: aarch64 universal install_mirrorlist_graphical

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Neal Gompa]

On Mon, Nov 8, 2021 at 9:34 AM Vitaly Zaitsev via devel
 wrote:
>
> On 08/11/2021 15:25, Neal Gompa wrote:
> > This is not true anymore.
>
> Have you tested the build without network access? Because even Flatpaks
> download everything from npm.
>

I've done an offline build with some prep work upfront, yes. It's not
automatically a thing, but it is possible.



-- 
真実はいつも一つ！/ 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: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Vitaly Zaitsev via devel]

On 08/11/2021 15:25, Neal Gompa wrote:

This is not true anymore.


Have you tested the build without network access? Because even Flatpaks 
download everything from npm.


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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Neal Gompa]

On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel
 wrote:
>
> On 08/11/2021 10:12, Andreas Schneider wrote:
> > I'm interested in this, as I try to package electron for Fedora.
>
> Electron can't be build completely from sources without downloading
> pre-built binaries/blobs from npm.
>

This is not true anymore.



-- 
真実はいつも一つ！/ 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: F35 no USB after today's updates

[Pablo Sebastián Greco]

On 8/11/21 11:02, Sergio Pascual wrote:



El lun, 8 nov 2021 a las 14:36, Stephen John Smoogen 
() escribió:



Can you try downgrading to the F34 linux-firmware and see if the f34
kernel sees the chipset again?



I have downgraded everything to the released F35 and now it works, 
with kernel 5.14.16-301 and linux-firmware-20210919-125


The fix for this problem is the difference between -300 and -301 (revert 
of 2 commits), which are already included in 5.14.17 too



-- 
Stephen J Smoogen.

Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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


Pablo.___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Vitaly Zaitsev via devel]

On 08/11/2021 10:12, Andreas Schneider wrote:

I'm interested in this, as I try to package electron for Fedora.


Electron can't be build completely from sources without downloading 
pre-built binaries/blobs from npm.


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

Re: F35 no USB after today's updates

[Michael Cronenworth]

On 11/8/21 5:53 AM, Sergio Pascual wrote:
Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf updated' and 
rebooted. After the reboot, all my USBs are disabled. No mouse, no keyword.
I know my hardware works because the keyboard works in grub, and the light of my 
optical mouse in on until some errors appear in the kernel during boot.


I have tried:
kernel-5.14.15-200.fc34.x86_64
kernel-5.14.15-300.fc35.x86_64
kernel-5.14.16-301.fc35.x86_64



Maybe you're affected by this[1] guy?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2019788
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 no USB after today's updates

[Sergio Pascual]

El lun, 8 nov 2021 a las 14:36, Stephen John Smoogen ()
escribió:

>
> Can you try downgrading to the F34 linux-firmware and see if the f34
> kernel sees the chipset again?
>
>
>
I have downgraded everything to the released F35 and now it works, with
kernel 5.14.16-301 and linux-firmware-20210919-125




>
> --
> Stephen J Smoogen.
> Let us be kind to one another, for most of us are fighting a hard
> battle. -- Ian MacClaren
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Martin Stransky]

On 11/8/21 13:37, Dominik 'Rathann' Mierzejewski wrote:

On Monday, 08 November 2021 at 11:51, Andreas Schneider wrote:

On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski
wrote:

On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:


Hi,

there are several packages in the distribution which require FFMPEG
(libavformat, libavcodec, etc.), one of them being chromium. The package
could

  be created in a way that you can easily replace it with a version

from rpmfusion to get to the full encoder/decoder set including H264 etc.

This is working fine with openSUSE and packages from Packman.

https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg

The Packman version always has a higher release version than the one in
the

  distribution.


I'm interested in this, as I try to package electron for Fedora. The big
problem is the included ffmpeg. With openSUSE I can just use the system
ffmpeg, with Fedora I have to do some source code voodoo which I really
would

  like to avoid.



Maintaining such package would require keeping watch for any new files
you'd need to include and going through legal review each time you do.


Did you take a look how they solved it at SUSE?


Actually, yes. We cannot do the same as we cannot distribute the full
upstream source.


You have list for encoder and decoders which are allowed to be built. So if a
new encoder or decoder would be added, it would just not be built. You will
just always end up with the same set of encoders/decoders with every update.


Sometimes new dependencies get added to existing decoders/encoders which
would require legal review.


Packman uses the exact same package as openSUSE and all it does it to enable
all encoders and decoders.

All packages requiring ffmpeg can just always be built against the system
version.

It should be less legal work, as you have to check just one package and not
several which might include it as third_party source code.


Chromium was checked by legal. I'm not aware of any other Fedora
packages bundling a subset of FFmpeg.


Firefox ships bundled ffmpeg with VP8/9 and maybe some other codecs.

--
Martin Stransky
Software Engineer / Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 no USB after today's updates

[Miroslav Suchý]

Dne 08. 11. 21 v 12:53 Sergio Pascual napsal(a):
Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf updated' and rebooted. After the reboot, all my 
USBs are disabled. No mouse, no keyword.
I know my hardware works because the keyboard works in grub, and the light of my optical mouse in on until some errors 
appear in the kernel during boot.


I have tried:
kernel-5.14.15-200.fc34.x86_64
kernel-5.14.15-300.fc35.x86_64
kernel-5.14.16-301.fc35.x86_64

without success.
I'm getting messages like these:


I had the same issue this morning (F35). Beside the `dnf upgrade` I upgraded the firmware using LVFS. But after 3rd 
reboot and a pause for a breakfast the USB have started working.


I had no time to investigate it further. The symptoms were the same. USB keyboard worked in the grub, but did not worked 
later (not even in luks decrypt). I will try to spend later some times on logs.


Miroslav

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 no USB after today's updates

[Stephen John Smoogen]

On Mon, 8 Nov 2021 at 08:16, Sergio Pascual  wrote:
>
>
> El lun, 8 nov 2021 a las 13:39, Stephen John Smoogen () 
> escribió:
>>
>> On Mon, 8 Nov 2021 at 06:53, Sergio Pascual  wrote:
>> >
>> > Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf 
>> > updated' and rebooted. After the reboot, all my USBs are disabled. No 
>> > mouse, no keyword.
>> > I know my hardware works because the keyboard works in grub, and the light 
>> > of my optical mouse in on until some errors appear in the kernel during 
>> > boot.
>> >
>> > I have tried:
>> > kernel-5.14.15-200.fc34.x86_64
>> > kernel-5.14.15-300.fc35.x86_64
>> > kernel-5.14.16-301.fc35.x86_64
>> >
>>
>> The developers will need to know what the exact motherboard/laptop
>> version and manufacturer you have in order to diagnose this issue. My
>> initial guess is that since the f34 kernel also fails, that the
>> problem is with a firmware module and whatever the motherboard is
>> expecting to use. [The fact that it is only finding USB2 says that
>> either the system is really old or that it is trying to fail to its
>> lowest working value.]
>>
>>
>
>
> My workstation is a Dell Precision Tower 7910.
>
> lscpi says I have the following serial bus controllers
>
> 00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI 
> Host Controller (rev 05)
> 00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB 
> Enhanced Host Controller #2 (rev 05)
> 00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB 
> Enhanced Host Controller #1 (rev 05)
>

Can you try downgrading to the F34 linux-firmware and see if the f34
kernel sees the chipset again?



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 no USB after today's updates

[Jason Montleon]

I have a similar system. lspci out looks near identical. The system was 
just booted this morning.


I normally run it headless with just power and network connected, but 
plugging in a USB mouse, thumb drive, and USB optical drive, they show 
up fine in dmesg and lsusb output using random USB ports on the front 
and back, as does the card reader on the front of the system. I mounted 
the thumb drive fine.


# dmidecode | grep -i Precision && uname -srvpi && lspci | grep USB
Product Name: Precision Tower 7810
Linux 5.14.16-301.fc35.x86_64 #1 SMP Wed Nov 3 13:55:42 UTC 2021 x86_64 
x86_64
00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB 
xHCI Host Controller (rev 05)
00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB 
Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB 
Enhanced Host Controller #1 (rev 05)



On 11/8/21 08:15, Sergio Pascual wrote:


El lun, 8 nov 2021 a las 13:39, Stephen John Smoogen (>) escribió:


On Mon, 8 Nov 2021 at 06:53, Sergio Pascual mailto:sergio.pa...@gmail.com>> wrote:
 >
 > Hi, I upgraded my workstation to F35 last Friday, and today I
'dnf updated' and rebooted. After the reboot, all my USBs are
disabled. No mouse, no keyword.
 > I know my hardware works because the keyboard works in grub, and
the light of my optical mouse in on until some errors appear in the
kernel during boot.
 >
 > I have tried:
 > kernel-5.14.15-200.fc34.x86_64
 > kernel-5.14.15-300.fc35.x86_64
 > kernel-5.14.16-301.fc35.x86_64
 >

The developers will need to know what the exact motherboard/laptop
version and manufacturer you have in order to diagnose this issue. My
initial guess is that since the f34 kernel also fails, that the
problem is with a firmware module and whatever the motherboard is
expecting to use. [The fact that it is only finding USB2 says that
either the system is really old or that it is trying to fail to its
lowest working value.]




My workstation is a Dell Precision Tower 7910.

lscpi says I have the following serial bus controllers

00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB 
xHCI Host Controller (rev 05)
00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB 
Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB 
Enhanced Host Controller #1 (rev 05)


Regards


 > without success.
 > I'm getting messages like these:
 >
 > [   23.722355] usb 3-10: new high-speed USB device number 7 using
xhci_hcd
 > [   23.857746] usb 3-10: New USB device found, idVendor=0bda,
idProduct=0184, bcdDevice=84.13
 > [   23.857755] usb 3-10: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
 > [   23.857759] usb 3-10: Product: USB2.0-CRW
 > [   23.857762] usb 3-10: Manufacturer: Generic
 > [   23.857764] usb 3-10: SerialNumber: 2010081884130
 > [   24.016363] usb 3-7.1: new high-speed USB device number 8
using xhci_hcd
 > [   29.648377] usb 3-7.1: device descriptor read/64, error -110
 > [   45.520400] usb 3-7.1: device descriptor read/64, error -110
 > [   45.624451] usb 3-7-port1: attempt power cycle
 > [   45.738358] usb 3-13: new high-speed USB device number 9 using
xhci_hcd
 > [   45.865929] usb 3-13: New USB device found, idVendor=05e3,
idProduct=0608, bcdDevice=32.98
 > [   45.865939] usb 3-13: New USB device strings: Mfr=0,
Product=1, SerialNumber=0
 > [   45.865942] usb 3-13: Product: USB2.0 Hub
 > [   45.866653] hub 3-13:1.0: USB hub found
 > [   45.866992] hub 3-13:1.0: 4 ports detected
 > [   46.304365] usb 3-7.1: new high-speed USB device number 10
using xhci_hcd
 > [   56.160384] xhci_hcd :00:14.0: Abort failed to stop
command ring: -110
 > [   56.160384] xhci_hcd :00:14.0: xHCI host controller not
responding, assume dead
 > [   56.160384] xhci_hcd :00:14.0: HC died; cleaning up
 > [   56.488455] xhci_hcd :00:14.0: Timeout while waiting for
setup device command
 > [   56.488480] usb 4-2: USB disconnect, device number 2
 > [   56.904366] usb 3-7.1: device not accepting address 10, error -108
 > [   56.904412] usb 3-7-port1: couldn't allocate usb_device
 > [   56.904464] usb usb3-port2: couldn't allocate usb_device
 > [   56.904502] usb 3-13-port1: couldn't allocate usb_device
 > [   56.904603] usb 3-3: USB disconnect, device number 2
 > [   56.927819] usb 3-6: USB disconnect, device number 3
 >
 >
 >
 > ___
 > devel mailing list -- devel@lists.fedoraproject.org

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

 > F

Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

[Neal Gompa]

On Mon, Nov 8, 2021 at 8:27 AM Florian Weimer  wrote:
>
> * Neal Gompa:
>
> > Seems like a worthy effort to me. Though instead of having branches
> > for redhat-rpm-config, you could add macros to flag it on and off by
> > default, and have releng configure a side-tag for you that turns it on
> > for package builds (we can have macros set for build tags).
>
> Is it possible to set a dist tag suffix for the branch, then?  In
> combination with the flag approach, that would actually be more
> convenient (assuming the gcc folks are okay with a conditionally applied
> patch for that branch).
>

You can set the dist tag suffix in the build tag too. That's what we
do for ELN, for example.

You can set any number of macros this way and use them as flags to
trigger behavioral differences in packages submitted to build. The way
*I* suggest doing it (you may choose another way, of course) would be
to set the flags up in the build tag and build from the rawhide
branch. Fixes for C99 should be integrated straight into the mainline
rawhide branch anyway.


-- 
真実はいつも一つ！/ 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: Long-running side tag for porting Fedora to C99 (no implicit decls)

[Florian Weimer]

* Neal Gompa:

> Seems like a worthy effort to me. Though instead of having branches
> for redhat-rpm-config, you could add macros to flag it on and off by
> default, and have releng configure a side-tag for you that turns it on
> for package builds (we can have macros set for build tags).

Is it possible to set a dist tag suffix for the branch, then?  In
combination with the flag approach, that would actually be more
convenient (assuming the gcc folks are okay with a conditionally applied
patch for that branch).

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Rawhide kernel crash

[Justin Forbes]

On Mon, Nov 8, 2021 at 6:56 AM edmond pilon  wrote:
>
> CONFIG_SYSFB_SIMPLEFB=y
> CONFIG_DRM_SIMPLEDRM=m
> # CONFIG_FB_SIMPLE is not set
>
> Fix the issue.

These configs are in preparation for an F36 potential feature, and
were not intended to work flawlessly on F35 or earlier. They were
backed out from the fedora-5.15 branch as soon as it was created
because that branch targets stable Fedora.   While simpledrm will work
for many systems at this time, it seems to have issues with nvidia
drivers at least.

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

Re: F35 no USB after today's updates

[Sergio Pascual]

El lun, 8 nov 2021 a las 13:39, Stephen John Smoogen ()
escribió:

> On Mon, 8 Nov 2021 at 06:53, Sergio Pascual 
> wrote:
> >
> > Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf
> updated' and rebooted. After the reboot, all my USBs are disabled. No
> mouse, no keyword.
> > I know my hardware works because the keyboard works in grub, and the
> light of my optical mouse in on until some errors appear in the kernel
> during boot.
> >
> > I have tried:
> > kernel-5.14.15-200.fc34.x86_64
> > kernel-5.14.15-300.fc35.x86_64
> > kernel-5.14.16-301.fc35.x86_64
> >
>
> The developers will need to know what the exact motherboard/laptop
> version and manufacturer you have in order to diagnose this issue. My
> initial guess is that since the f34 kernel also fails, that the
> problem is with a firmware module and whatever the motherboard is
> expecting to use. [The fact that it is only finding USB2 says that
> either the system is really old or that it is trying to fail to its
> lowest working value.]
>
>
>

My workstation is a Dell Precision Tower 7910.

lscpi says I have the following serial bus controllers

00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI
Host Controller (rev 05)
00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB
Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB
Enhanced Host Controller #1 (rev 05)

Regards




> > without success.
> > I'm getting messages like these:
> >
> > [   23.722355] usb 3-10: new high-speed USB device number 7 using
> xhci_hcd
> > [   23.857746] usb 3-10: New USB device found, idVendor=0bda,
> idProduct=0184, bcdDevice=84.13
> > [   23.857755] usb 3-10: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> > [   23.857759] usb 3-10: Product: USB2.0-CRW
> > [   23.857762] usb 3-10: Manufacturer: Generic
> > [   23.857764] usb 3-10: SerialNumber: 2010081884130
> > [   24.016363] usb 3-7.1: new high-speed USB device number 8 using
> xhci_hcd
> > [   29.648377] usb 3-7.1: device descriptor read/64, error -110
> > [   45.520400] usb 3-7.1: device descriptor read/64, error -110
> > [   45.624451] usb 3-7-port1: attempt power cycle
> > [   45.738358] usb 3-13: new high-speed USB device number 9 using
> xhci_hcd
> > [   45.865929] usb 3-13: New USB device found, idVendor=05e3,
> idProduct=0608, bcdDevice=32.98
> > [   45.865939] usb 3-13: New USB device strings: Mfr=0, Product=1,
> SerialNumber=0
> > [   45.865942] usb 3-13: Product: USB2.0 Hub
> > [   45.866653] hub 3-13:1.0: USB hub found
> > [   45.866992] hub 3-13:1.0: 4 ports detected
> > [   46.304365] usb 3-7.1: new high-speed USB device number 10 using
> xhci_hcd
> > [   56.160384] xhci_hcd :00:14.0: Abort failed to stop command ring:
> -110
> > [   56.160384] xhci_hcd :00:14.0: xHCI host controller not
> responding, assume dead
> > [   56.160384] xhci_hcd :00:14.0: HC died; cleaning up
> > [   56.488455] xhci_hcd :00:14.0: Timeout while waiting for setup
> device command
> > [   56.488480] usb 4-2: USB disconnect, device number 2
> > [   56.904366] usb 3-7.1: device not accepting address 10, error -108
> > [   56.904412] usb 3-7-port1: couldn't allocate usb_device
> > [   56.904464] usb usb3-port2: couldn't allocate usb_device
> > [   56.904502] usb 3-13-port1: couldn't allocate usb_device
> > [   56.904603] usb 3-3: USB disconnect, device number 2
> > [   56.927819] usb 3-6: USB disconnect, device number 3
> >
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>
>
>
> --
> Stephen J Smoogen.
> Let us be kind to one another, for most of us are fighting a hard
> battle. -- Ian MacClaren
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wi

Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

[Neal Gompa]

On Mon, Nov 8, 2021 at 8:07 AM Florian Weimer  wrote:
>
> I would like to create a long-running rawhide side tag for preparing
> Fedora for the removal of implicit function declarations from the GCC
> defaults.  This is a change that happened in the C99 version of the
> language, but GCC could not adopt at the time because too much software
> was broken by it.  Even today, there are build failures, and, arguably
> worse, successful builds with different feature sets.
>
> The goal is to disable implicit function declarations in GCC 13, to be
> released in spring 2023 (not next year's GCC 12 version).  This plan was
> presented at this year's Cauldron, and was met with approval:
>
>   Eliminating implicit function declarations
>   
>
> I have some space to work on this during the coming months, for
> implementing the buildroot changes (in gcc and presumably
> redhat-rpm-config, built off branches in dist-git), for creating some
> HTML reports, and even for creating the package changes themselves.
> Changes will be submitted to upstream projects initially.  Eventually,
> we'll have to fix the Fedora packages if there's no upstream release
> with the fixes.  We'll need some way to coordinate the fixes between
> multiple developers, a way to find unapplied upstream fixes once we are
> heading towards Fedora 38, and ideally some way to share patches across
> distributions if the upstream project no longer exists/accepts patches.
>
> If Fedora wants to support this, I'd need a long-running side tag in
> Koji, and a few dist-git branches (for gcc and redhat-rpm-config).  I
> can do the test builds as scratch builds, to conserve storage space and
> not to pollute Koji with uninteresting NVRs.
>
> Thoughts?
>

Seems like a worthy effort to me. Though instead of having branches
for redhat-rpm-config, you could add macros to flag it on and off by
default, and have releng configure a side-tag for you that turns it on
for package builds (we can have macros set for build tags).



-- 
真実はいつも一つ！/ 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

Long-running side tag for porting Fedora to C99 (no implicit decls)

[Florian Weimer]

I would like to create a long-running rawhide side tag for preparing
Fedora for the removal of implicit function declarations from the GCC
defaults.  This is a change that happened in the C99 version of the
language, but GCC could not adopt at the time because too much software
was broken by it.  Even today, there are build failures, and, arguably
worse, successful builds with different feature sets.

The goal is to disable implicit function declarations in GCC 13, to be
released in spring 2023 (not next year's GCC 12 version).  This plan was
presented at this year's Cauldron, and was met with approval:

  Eliminating implicit function declarations
  

I have some space to work on this during the coming months, for
implementing the buildroot changes (in gcc and presumably
redhat-rpm-config, built off branches in dist-git), for creating some
HTML reports, and even for creating the package changes themselves.
Changes will be submitted to upstream projects initially.  Eventually,
we'll have to fix the Fedora packages if there's no upstream release
with the fixes.  We'll need some way to coordinate the fixes between
multiple developers, a way to find unapplied upstream fixes once we are
heading towards Fedora 38, and ideally some way to share patches across
distributions if the upstream project no longer exists/accepts patches.

If Fedora wants to support this, I'd need a long-running side tag in
Koji, and a few dist-git branches (for gcc and redhat-rpm-config).  I
can do the test builds as scratch builds, to conserve storage space and
not to pollute Koji with uninteresting NVRs.

Thoughts?

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

Fedora rawhide compose report: 20211108.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20211107.n.0
NEW: Fedora-Rawhide-20211108.n.0

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

Size of added packages:  0 B
Size of dropped packages:5.82 MiB
Size of upgraded packages:   2.90 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: feedreader-2.11.0-4.fc35
Summary: RSS desktop client
RPMs:feedreader
Size:5.82 MiB


= UPGRADED PACKAGES =
Package:  antlr4-project-4.9.3-1.fc36
Old package:  antlr4-project-4.9.2-3.fc35
Summary:  Parser generator (ANother Tool for Language Recognition)
RPMs: antlr4 antlr4-cpp-runtime antlr4-cpp-runtime-devel antlr4-doc 
antlr4-maven-plugin antlr4-runtime antlr4-runtime-test-annotation-processors 
antlr4-runtime-test-annotations golang-antlr4-runtime-devel nodejs-antlr4 
python3-antlr4-runtime swift-antlr4-runtime
Size: 9.18 MiB
Size change:  786.32 KiB
Changelog:
  * Sun Nov 07 2021 Jerry James  - 4.9.3-1
  - Version 4.9.3
  - Drop upstreamed -unicode-properties and -utf8cpp patches


Package:  bluez-5.62-2.fc36
Old package:  bluez-5.62-1.fc36
Summary:  Bluetooth utilities
RPMs: bluez bluez-cups bluez-deprecated bluez-hid2hci bluez-libs 
bluez-libs-devel bluez-mesh bluez-obexd
Size: 10.79 MiB
Size change:  12.00 KiB
Changelog:
  * Sun Nov 07 2021 Adam Williamson  - 5.62-2
  - Revert an upstream change to fix problems with Logitech MX mice (#2019970)


Package:  bpython-0.22-1.fc36
Old package:  bpython-0.21-3.fc35
Summary:  Fancy curses interface to the Python interactive interpreter
RPMs: python3-bpython python3-bpython-urwid
Size: 343.21 KiB
Size change:  10.02 KiB
Changelog:
  * Sun Nov 07 2021 Terje Rosten  - 0.22.0-1
  - 0.22.0


Package:  calc-2.14.0.6-1.fc36
Old package:  calc-2.14.0.3-1.fc36
Summary:  Arbitrary precision arithmetic system and calculator
RPMs: calc calc-devel calc-libs calc-stdrc
Size: 5.57 MiB
Size change:  5.74 KiB
Changelog:
  * Sun Nov 07 2021 Matthew Miller  2.14.0.6-1
  - update to 2.14.0.6 experimental release


Package:  clamav-0.103.4-1.fc36
Old package:  clamav-0.103.3-9.fc36
Summary:  End-user tools for the Clam Antivirus scanner
RPMs: clamav clamav-data clamav-devel clamav-filesystem clamav-lib 
clamav-milter clamav-update clamd
Size: 233.53 MiB
Size change:  9.51 MiB
Changelog:
  * Sun Nov 07 2021 S??rgio Basto  - 0.103.4-1
  - Update to 0.103.4


Package:  collectd-5.12.0-12.fc36
Old package:  collectd-5.12.0-11.fc36
Summary:  Statistics collection daemon for filling RRD files
RPMs: collectd collectd-amqp collectd-amqp1 collectd-apache 
collectd-ascent collectd-bind collectd-ceph collectd-chrony collectd-curl 
collectd-curl_json collectd-curl_xml collectd-dbi collectd-disk collectd-dns 
collectd-drbd collectd-email collectd-generic-jmx collectd-gps 
collectd-hugepages collectd-infiniband collectd-ipmi collectd-iptables 
collectd-ipvs collectd-java collectd-log_logstash collectd-lua collectd-mcelog 
collectd-mdevents collectd-memcachec collectd-modbus collectd-mysql 
collectd-netlink collectd-nginx collectd-notify_desktop collectd-notify_email 
collectd-nut collectd-onewire collectd-openldap collectd-ovs_events 
collectd-ovs_stats collectd-pinba collectd-ping collectd-postgresql 
collectd-python collectd-redis collectd-rrdcached collectd-rrdtool 
collectd-sensors collectd-smart collectd-snmp collectd-snmp_agent 
collectd-synproxy collectd-utils collectd-varnish collectd-virt collectd-web 
collectd-write_http collectd-write_kafka collectd-write_mongodb 
collectd-write_prometheus collectd-write_redis collectd-write_riemann 
collectd-write_sensu collectd-write_syslog collectd-write_tsdb collectd-xencpu 
collectd-zookeeper libcollectdclient libcollectdclient-devel perl-Collectd
Size: 10.76 MiB
Size change:  30.62 KiB
Changelog:
  * Sun Nov 07 2021 Bj??rn Esser  - 5.12.0-12
  - Rebuild (riemann-c-client)


Package:  community-mysql-8.0.27-2.fc36
Old package:  community-mysql-8.0.27-1.fc36
Summary:  MySQL client programs and shared libraries
RPMs: community-mysql community-mysql-common community-mysql-devel 
community-mysql-errmsg community-mysql-libs community-mysql-server 
community-mysql-test
Size: 1.17 GiB
Size change:  -97.68 KiB
Changelog:
  * Sun Nov 07 2021 Mamoru TASAKA  - 8.0.27-2
  - rebuild for new protobuf


Package:  coolreader-3.2.59-1.fc36
Old package:  coolreader-3.2.54-2.fc35
Summary:  Cross platform open source e-book reader
RPMs: coolreader
Size: 12.98 MiB
Size change:  1.03 MiB
Changelog:
  * Sun Nov 07 2021 Andy Mender  - 3.2.59-1
  - Bump version to 3.2.59
  - Add new build

Re: Rawhide kernel crash

[edmond pilon]

CONFIG_SYSFB_SIMPLEFB=y
CONFIG_DRM_SIMPLEDRM=m
# CONFIG_FB_SIMPLE is not set

Fix the issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 no USB after today's updates

[Stephen John Smoogen]

On Mon, 8 Nov 2021 at 06:53, Sergio Pascual  wrote:
>
> Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf updated' 
> and rebooted. After the reboot, all my USBs are disabled. No mouse, no 
> keyword.
> I know my hardware works because the keyboard works in grub, and the light of 
> my optical mouse in on until some errors appear in the kernel during boot.
>
> I have tried:
> kernel-5.14.15-200.fc34.x86_64
> kernel-5.14.15-300.fc35.x86_64
> kernel-5.14.16-301.fc35.x86_64
>

The developers will need to know what the exact motherboard/laptop
version and manufacturer you have in order to diagnose this issue. My
initial guess is that since the f34 kernel also fails, that the
problem is with a firmware module and whatever the motherboard is
expecting to use. [The fact that it is only finding USB2 says that
either the system is really old or that it is trying to fail to its
lowest working value.]


> without success.
> I'm getting messages like these:
>
> [   23.722355] usb 3-10: new high-speed USB device number 7 using xhci_hcd
> [   23.857746] usb 3-10: New USB device found, idVendor=0bda, idProduct=0184, 
> bcdDevice=84.13
> [   23.857755] usb 3-10: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [   23.857759] usb 3-10: Product: USB2.0-CRW
> [   23.857762] usb 3-10: Manufacturer: Generic
> [   23.857764] usb 3-10: SerialNumber: 2010081884130
> [   24.016363] usb 3-7.1: new high-speed USB device number 8 using xhci_hcd
> [   29.648377] usb 3-7.1: device descriptor read/64, error -110
> [   45.520400] usb 3-7.1: device descriptor read/64, error -110
> [   45.624451] usb 3-7-port1: attempt power cycle
> [   45.738358] usb 3-13: new high-speed USB device number 9 using xhci_hcd
> [   45.865929] usb 3-13: New USB device found, idVendor=05e3, idProduct=0608, 
> bcdDevice=32.98
> [   45.865939] usb 3-13: New USB device strings: Mfr=0, Product=1, 
> SerialNumber=0
> [   45.865942] usb 3-13: Product: USB2.0 Hub
> [   45.866653] hub 3-13:1.0: USB hub found
> [   45.866992] hub 3-13:1.0: 4 ports detected
> [   46.304365] usb 3-7.1: new high-speed USB device number 10 using xhci_hcd
> [   56.160384] xhci_hcd :00:14.0: Abort failed to stop command ring: -110
> [   56.160384] xhci_hcd :00:14.0: xHCI host controller not responding, 
> assume dead
> [   56.160384] xhci_hcd :00:14.0: HC died; cleaning up
> [   56.488455] xhci_hcd :00:14.0: Timeout while waiting for setup device 
> command
> [   56.488480] usb 4-2: USB disconnect, device number 2
> [   56.904366] usb 3-7.1: device not accepting address 10, error -108
> [   56.904412] usb 3-7-port1: couldn't allocate usb_device
> [   56.904464] usb usb3-port2: couldn't allocate usb_device
> [   56.904502] usb 3-13-port1: couldn't allocate usb_device
> [   56.904603] usb 3-3: USB disconnect, device number 2
> [   56.927819] usb 3-6: USB disconnect, device number 3
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Dominik 'Rathann' Mierzejewski]

On Monday, 08 November 2021 at 11:51, Andreas Schneider wrote:
> On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski 
> wrote:
> > On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
> > 
> > > Hi,
> > > 
> > > there are several packages in the distribution which require FFMPEG 
> > > (libavformat, libavcodec, etc.), one of them being chromium. The package
> > > could 
>  be created in a way that you can easily replace it with a version
> > > from rpmfusion to get to the full encoder/decoder set including H264 etc.
> > > 
> > > This is working fine with openSUSE and packages from Packman.
> > > 
> > > https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> > > https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
> > > 
> > > The Packman version always has a higher release version than the one in
> > > the 
>  distribution.
> > > 
> > > I'm interested in this, as I try to package electron for Fedora. The big 
> > > problem is the included ffmpeg. With openSUSE I can just use the system 
> > > ffmpeg, with Fedora I have to do some source code voodoo which I really
> > > would 
>  like to avoid.
> > 
> > 
> > Maintaining such package would require keeping watch for any new files
> > you'd need to include and going through legal review each time you do.
> 
> Did you take a look how they solved it at SUSE?

Actually, yes. We cannot do the same as we cannot distribute the full
upstream source.

> You have list for encoder and decoders which are allowed to be built. So if a 
> new encoder or decoder would be added, it would just not be built. You will 
> just always end up with the same set of encoders/decoders with every update.

Sometimes new dependencies get added to existing decoders/encoders which
would require legal review.

> Packman uses the exact same package as openSUSE and all it does it to enable 
> all encoders and decoders.
> 
> All packages requiring ffmpeg can just always be built against the system 
> version.
> 
> It should be less legal work, as you have to check just one package and not 
> several which might include it as third_party source code.

Chromium was checked by legal. I'm not aware of any other Fedora
packages bundling a subset of FFmpeg.

> > IMO it's much less work to just maintain everything that depends on
> > FFmpeg in RPM Fusion.
> >
> > If you're determined, however, you could start with what Chromium does:
> > https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
> 
> How is it less work if you need to clean ffmpeg source codes in several 
> projects which include it instead of just linking the system one? It is more 
> prone to errors to remove sources and you have to track it instead of just 
> having a fixed decoder/encoder set you build.

I agree it would be better to have one system package that others would
link against but as with everything, it's not always possible. You're
welcome to try.

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

Re: F35 no USB after today's updates

[Peter Robinson]

> Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf updated' 
> and rebooted. After the reboot, all my USBs are disabled. No mouse, no 
> keyword.
> I know my hardware works because the keyboard works in grub, and the light of 
> my optical mouse in on until some errors appear in the kernel during boot.

Please provide details of the actual HW.

> I have tried:
> kernel-5.14.15-200.fc34.x86_64
> kernel-5.14.15-300.fc35.x86_64
> kernel-5.14.16-301.fc35.x86_64
>
> without success.
> I'm getting messages like these:
>
> [   23.722355] usb 3-10: new high-speed USB device number 7 using xhci_hcd
> [   23.857746] usb 3-10: New USB device found, idVendor=0bda, idProduct=0184, 
> bcdDevice=84.13
> [   23.857755] usb 3-10: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [   23.857759] usb 3-10: Product: USB2.0-CRW
> [   23.857762] usb 3-10: Manufacturer: Generic
> [   23.857764] usb 3-10: SerialNumber: 2010081884130
> [   24.016363] usb 3-7.1: new high-speed USB device number 8 using xhci_hcd
> [   29.648377] usb 3-7.1: device descriptor read/64, error -110
> [   45.520400] usb 3-7.1: device descriptor read/64, error -110
> [   45.624451] usb 3-7-port1: attempt power cycle
> [   45.738358] usb 3-13: new high-speed USB device number 9 using xhci_hcd
> [   45.865929] usb 3-13: New USB device found, idVendor=05e3, idProduct=0608, 
> bcdDevice=32.98
> [   45.865939] usb 3-13: New USB device strings: Mfr=0, Product=1, 
> SerialNumber=0
> [   45.865942] usb 3-13: Product: USB2.0 Hub
> [   45.866653] hub 3-13:1.0: USB hub found
> [   45.866992] hub 3-13:1.0: 4 ports detected
> [   46.304365] usb 3-7.1: new high-speed USB device number 10 using xhci_hcd
> [   56.160384] xhci_hcd :00:14.0: Abort failed to stop command ring: -110
> [   56.160384] xhci_hcd :00:14.0: xHCI host controller not responding, 
> assume dead
> [   56.160384] xhci_hcd :00:14.0: HC died; cleaning up
> [   56.488455] xhci_hcd :00:14.0: Timeout while waiting for setup device 
> command
> [   56.488480] usb 4-2: USB disconnect, device number 2
> [   56.904366] usb 3-7.1: device not accepting address 10, error -108
> [   56.904412] usb 3-7-port1: couldn't allocate usb_device
> [   56.904464] usb usb3-port2: couldn't allocate usb_device
> [   56.904502] usb 3-13-port1: couldn't allocate usb_device
> [   56.904603] usb 3-3: USB disconnect, device number 2
> [   56.927819] usb 3-6: USB disconnect, device number 3
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Dominik 'Rathann' Mierzejewski]

On Monday, 08 November 2021 at 12:01, Fabio Valentini wrote:
> On Mon, Nov 8, 2021 at 11:51 AM Andreas Schneider  wrote:
> >
> > On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski
> > wrote:
> > > On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
> > >
> > > > Hi,
> > > >
> > > > there are several packages in the distribution which require FFMPEG
> > > > (libavformat, libavcodec, etc.), one of them being chromium. The package
> > > > could
> >  be created in a way that you can easily replace it with a version
> > > > from rpmfusion to get to the full encoder/decoder set including H264 
> > > > etc.
> > > >
> > > > This is working fine with openSUSE and packages from Packman.
> > > >
> > > > https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> > > > https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
> > > >
> > > > The Packman version always has a higher release version than the one in
> > > > the
> >  distribution.
> > > >
> > > > I'm interested in this, as I try to package electron for Fedora. The big
> > > > problem is the included ffmpeg. With openSUSE I can just use the system
> > > > ffmpeg, with Fedora I have to do some source code voodoo which I really
> > > > would
> >  like to avoid.
> > >
> > >
> > > Maintaining such package would require keeping watch for any new files
> > > you'd need to include and going through legal review each time you do.
> >
> > Did you take a look how they solved it at SUSE?
> >
> > You have list for encoder and decoders which are allowed to be built. So if 
> > a
> > new encoder or decoder would be added, it would just not be built. You will
> > just always end up with the same set of encoders/decoders with every update.
> >
> > Packman uses the exact same package as openSUSE and all it does it to enable
> > all encoders and decoders.
> >
> > All packages requiring ffmpeg can just always be built against the system
> > version.
> >
> > It should be less legal work, as you have to check just one package and not
> > several which might include it as third_party source code.
> >
> > > IMO it's much less work to just maintain everything that depends on
> > > FFmpeg in RPM Fusion.
> > >
> > > If you're determined, however, you could start with what Chromium does:
> > > https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
> >
> > How is it less work if you need to clean ffmpeg source codes in several
> > projects which include it instead of just linking the system one? It is more
> > prone to errors to remove sources and you have to track it instead of just
> > having a fixed decoder/encoder set you build.
> 
> It's not the point that it's easier.
> 
> If I understand correctly, any official ffmpeg package distributed by
> Fedora would not be allowed to contain even the *source code* for
> patent-encumbered or redistribution-limited codecs in its source
> package (because those sources are redistributed too). So the only way
> to achieve that would be to use "clean" tarballs - and a hardcoded
> list of "allowed codecs to build" alone is not enough to satisfy that
> requirement.

That's what I meant although I haven't said so explicitly. The chromium
script does what you've described.

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

Re: deltarpm usefulness?

[Stephen John Smoogen]

On Mon, 8 Nov 2021 at 04:32, Michael Schroeder  wrote:
>
> On Sat, Nov 06, 2021 at 07:43:02AM -, Daniel Alley wrote:
> > Another issue - which is not per-se a security issue but it's still a 
> > problem - is that deltarpm uses md5 checksums pervasively.  They're 
> > everywhere.  And it uses its own implementation of md5 which doesn't 
> > respect FIPS, so even when the user has *explicitly* configured their 
> > system to not use md5 for anything security-relevant, libdeltarpm won't 
> > know or care.
>
> They are used as a consistency check, it might as well use crc32.
> So I don't see why FIPS is a concern for you.
>

In order to get the overall system to be FIPS (and equivalent EU/RU/CN
ones) certified all the implementations of various functions have to
be audited and reviewed. Some must be able to be turned off no matter
what. It doesn't matter if 99 of the 100 versions of md5um are only
for consistency, they must be able to be turned off/not used and not
affect the system.
[ The reason why we can't have nice things is that various
super-programmers who see that 99 versions of md5sum are gone, but
find that one call in say librpm which still exists, so they make a
wrapper to it and then tie the bank code to it. Next thing you know,
you find yourself not just on the Register as a story about code gone
wrong but on the front page of various financial newspapers due to
bank losses.]


> Cheers,
>   Michael.
>
> --
> Michael Schroeder  SUSE Software Solutions Germany GmbH
> m...@suse.de  GF: Felix Imendoerffer HRB 36809, AG Nuernberg
> main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: deltarpm usefulness?

[Demi Marie Obenour]

On 11/8/21 5:02 AM, Fabio Valentini wrote:
> On Sat, Nov 6, 2021 at 11:47 PM Marius Schwarz  wrote:
>>
>> Am 11.08.21 um 22:03 schrieb Marek Marczykowski-Górecki:
>>> - there is also argument that people's connection bandwidth nowadays
>>> tends to be fast enough to make the package rebuilding actually
>>> slower than downloading the whole package (but that really vary between
>>> different installations)
>>
>> Since we now have Linux on smartphonesd, i heavily disagree with this
>> assumption and advocate to expand the drpm usage.
> 
> How would you suggest to do that?
> 
> From what I can tell, drpms are most useful if you update your system
> daily (because deltas are only kept from one compose, and need storage
> space) - but unless you have thousands of packages installed, the few
> hundred KB - a few MB of download savings you get from drpms every day
> (at most) are drowned out by the size of the daily repository metadata
> download to even get those drpms. And if you update less often to
> reduce the frequency with which you need to download the big repo
> metadata, you might not get drpms for any updates at all.
> 
> So I don't think that there's *any* scenario where using drpms results
> in a net reduction in MBs that need to be downloaded over time,
> because either
> - failed drpm reconstructions cause whole packages to be redownloaded anyway,
> - very few packages have drpms in every update push,
> - drpms are only kept for a very limited amount of time and limited
> number of packages,
> - savings from drpm usage is on the order of at most a few MB per
> update per day, and less if not updating every day, but
> - repository metadata downloads are reaching ~100MB / day, depending
> on how many repos are enabled.
> 
> So ... am I missing something, or do drpms actually make things worse
> in *every* respect right now?
> - more MBs downloaded per update / per day in every scenario I can think of,
> - more computationally intensive to reconstruct locally,
> - needs compute time and storage space in Fedora build system,
> - makes compose process more complicated.
> 
> Fabio

I don’t think you are missing anything.

Sincerely,
Demi Marie Obenour



OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


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

Re: deltarpm usefulness?

[Stephen John Smoogen]

On Sun, 7 Nov 2021 at 13:44, Gordon Messmer  wrote:
>
> On 11/7/21 01:14, Rajeesh K V wrote:
> > Deltarpm did
> > reduce a lot of update download size for many years since 2007
>
>
> I remember seeing 60-70% reduction really often, and 90+ periodically.
> I've read Kevin's explanation of why it's not working as well now, but I
> wonder what changed between the early implementation when results were
> very good and now, when they really aren't.
>

My guess is that we hit a sweet spot at a certain time, and we would
need to constantly tune deltarpm to find it. Compiler changes, link
tool changes, different options in a compile, etc can cause code to
look different enough that the diff is larger at times (even if the
underlying machine code is the same, just put in different places in
the executable.)


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: deltarpm usefulness?

[Stephen John Smoogen]

On Mon, 8 Nov 2021 at 05:17, Samuel Sieb  wrote:
>
> On 11/8/21 01:23, Demi Marie Obenour wrote:
> > On 11/7/21 12:15 AM, Sumit Bhardwaj wrote:
> >> It is not always about speed. There are still plenty of places in the world
> >> where people are on limited data plans and to them using delta rpms makes a
> >> lot of sense. They can work with slow speeds but not with high data
> >> expenses. So i feel turning it on by default and having a setting to turn
> >> it off is still a sane choice. Just my 2 cents.
> >>
> >>
> >> Regards,
> >> Sumit Bhardwaj
> >
> > I recommend that deltarpms be disabled by default as they increase attack
> > surface.  Users who need deltarpms to be enabled can turn them on manually.
> > In the future, deltarpms should be cryptographically signed, which would
> > mitigate these concerns.
>
> This has been discussed before.  The deltarpms don't need to be signed,
> it's irrelevant.  The resulting rpm is signed and the signature is
> checked before installing.

It isn't always irrelevant. The case which worries me is where the
attacks are on the tool which tries to make the RPM from the contents
on the disk and the deltarpm. In this case the tool has to have root
level access to reconstruct the original rpm and then apply the
deltarpm to it. Currently it must assume that the deltarpm is valid
until proven otherwise and so is going through untrustable data. This
is a place where anyone wanting to attack people who use Qubes are
most likely to focus on. [And yes that is a downstream but these sorts
of attackers are going to shotgun their attack in a way which hits
upstream also.]


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 no USB after today's updates

[Sergio Pascual]

Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf updated'
and rebooted. After the reboot, all my USBs are disabled. No mouse, no
keyword.
I know my hardware works because the keyboard works in grub, and the light
of my optical mouse in on until some errors appear in the kernel during
boot.

I have tried:
kernel-5.14.15-200.fc34.x86_64
kernel-5.14.15-300.fc35.x86_64
kernel-5.14.16-301.fc35.x86_64

without success.
I'm getting messages like these:

[   23.722355] usb 3-10: new high-speed USB device number 7 using xhci_hcd
[   23.857746] usb 3-10: New USB device found, idVendor=0bda,
idProduct=0184, bcdDevice=84.13
[   23.857755] usb 3-10: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[   23.857759] usb 3-10: Product: USB2.0-CRW
[   23.857762] usb 3-10: Manufacturer: Generic
[   23.857764] usb 3-10: SerialNumber: 2010081884130
[   24.016363] usb 3-7.1: new high-speed USB device number 8 using xhci_hcd
[   29.648377] usb 3-7.1: device descriptor read/64, error -110
[   45.520400] usb 3-7.1: device descriptor read/64, error -110
[   45.624451] usb 3-7-port1: attempt power cycle
[   45.738358] usb 3-13: new high-speed USB device number 9 using xhci_hcd
[   45.865929] usb 3-13: New USB device found, idVendor=05e3,
idProduct=0608, bcdDevice=32.98
[   45.865939] usb 3-13: New USB device strings: Mfr=0, Product=1,
SerialNumber=0
[   45.865942] usb 3-13: Product: USB2.0 Hub
[   45.866653] hub 3-13:1.0: USB hub found
[   45.866992] hub 3-13:1.0: 4 ports detected
[   46.304365] usb 3-7.1: new high-speed USB device number 10 using xhci_hcd
[   56.160384] xhci_hcd :00:14.0: Abort failed to stop command ring:
-110
[   56.160384] xhci_hcd :00:14.0: xHCI host controller not responding,
assume dead
[   56.160384] xhci_hcd :00:14.0: HC died; cleaning up
[   56.488455] xhci_hcd :00:14.0: Timeout while waiting for setup
device command
[   56.488480] usb 4-2: USB disconnect, device number 2
[   56.904366] usb 3-7.1: device not accepting address 10, error -108
[   56.904412] usb 3-7-port1: couldn't allocate usb_device
[   56.904464] usb usb3-port2: couldn't allocate usb_device
[   56.904502] usb 3-13-port1: couldn't allocate usb_device
[   56.904603] usb 3-3: USB disconnect, device number 2
[   56.927819] usb 3-6: USB disconnect, device number 3
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Schedule for Monday's FESCo Meeting (2021-11-08)

[Zbigniew Jędrzejewski-Szmek]

[Note the DST change in many places: the meeting may move up one hour for you.]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19:00UTC in #fedora-meeting on
irc.libera.chat.

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

or run:
  date -d '2021-11-08 19:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2681 F36 Change: Ansible 5 
https://pagure.io/fesco/issue/2681
APPROVED (+5,1,-0)

#2680 F36 Change: Enforce Authselect Configuration Consistency 
https://pagure.io/fesco/issue/2680
APPROVED (+2,0,-0)

#2675 Nonresponsive maintainer: Paul Gier pgier 
https://pagure.io/fesco/issue/2675
APPROVED (+2, 0, -0)

= Followups =


= New business =

#2682 F36 Change: Openldap-2.5 
https://pagure.io/fesco/issue/2682

#2684 F36 Change: Drop NIS(+) support from PAM
https://pagure.io/fesco/issue/2684

#2687 F36 Change: Package information on ELF objects
https://pagure.io/fesco/issue/2687


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: deltarpm usefulness?

[mkolman]

On Sat, 2021-11-06 at 23:46 +0100, Marius Schwarz wrote:
> Am 11.08.21 um 22:03 schrieb Marek Marczykowski-Górecki:
> > - there is also argument that people's connection bandwidth
> > nowadays
> >     tends to be fast enough to make the package rebuilding actually
> >     slower than downloading the whole package (but that really vary
> > between
> >     different installations)
> 
> Since we now have Linux on smartphonesd, i heavily disagree with this
> assumption and advocate to expand the drpm usage.
I'm afraid that in its current implementation deltarpm is simply not
very efficient, I usually see <5% saved when doing updates on my Fedora
laptop. I would not expect this to differ too much from a a Fedora
running on eq. PinePhone or other mobile device.

What could work well already is using ostree or ostree based Fedora
distro on a phone - that has efficient delta-based updates built in
and used by default. So using say Silverblue/Kinoite or similar on a
phone could be much more efficient than using deltarpm + you get
additional benefits of being able to roll back at any time, which could
be useful on such a new Fedora platform.

Also flatpaks are ostree based & should get the same delta download and
de-duplication benefits automatically. So using as many flatpaks as
possible on a Fedora running mobile phone could also help quite a bit.

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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Fabio Valentini]

On Mon, Nov 8, 2021 at 11:51 AM Andreas Schneider  wrote:
>
> On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski
> wrote:
> > On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
> >
> > > Hi,
> > >
> > > there are several packages in the distribution which require FFMPEG
> > > (libavformat, libavcodec, etc.), one of them being chromium. The package
> > > could
>  be created in a way that you can easily replace it with a version
> > > from rpmfusion to get to the full encoder/decoder set including H264 etc.
> > >
> > > This is working fine with openSUSE and packages from Packman.
> > >
> > > https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> > > https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
> > >
> > > The Packman version always has a higher release version than the one in
> > > the
>  distribution.
> > >
> > > I'm interested in this, as I try to package electron for Fedora. The big
> > > problem is the included ffmpeg. With openSUSE I can just use the system
> > > ffmpeg, with Fedora I have to do some source code voodoo which I really
> > > would
>  like to avoid.
> >
> >
> > Maintaining such package would require keeping watch for any new files
> > you'd need to include and going through legal review each time you do.
>
> Did you take a look how they solved it at SUSE?
>
> You have list for encoder and decoders which are allowed to be built. So if a
> new encoder or decoder would be added, it would just not be built. You will
> just always end up with the same set of encoders/decoders with every update.
>
> Packman uses the exact same package as openSUSE and all it does it to enable
> all encoders and decoders.
>
> All packages requiring ffmpeg can just always be built against the system
> version.
>
> It should be less legal work, as you have to check just one package and not
> several which might include it as third_party source code.
>
> > IMO it's much less work to just maintain everything that depends on
> > FFmpeg in RPM Fusion.
> >
> > If you're determined, however, you could start with what Chromium does:
> > https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
>
> How is it less work if you need to clean ffmpeg source codes in several
> projects which include it instead of just linking the system one? It is more
> prone to errors to remove sources and you have to track it instead of just
> having a fixed decoder/encoder set you build.

It's not the point that it's easier.

If I understand correctly, any official ffmpeg package distributed by
Fedora would not be allowed to contain even the *source code* for
patent-encumbered or redistribution-limited codecs in its source
package (because those sources are redistributed too). So the only way
to achieve that would be to use "clean" tarballs - and a hardcoded
list of "allowed codecs to build" alone is not enough to satisfy that
requirement.

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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Andreas Schneider]

On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski 
wrote:
> On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
> 
> > Hi,
> > 
> > there are several packages in the distribution which require FFMPEG 
> > (libavformat, libavcodec, etc.), one of them being chromium. The package
> > could 
 be created in a way that you can easily replace it with a version
> > from rpmfusion to get to the full encoder/decoder set including H264 etc.
> > 
> > This is working fine with openSUSE and packages from Packman.
> > 
> > https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> > https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
> > 
> > The Packman version always has a higher release version than the one in
> > the 
 distribution.
> > 
> > I'm interested in this, as I try to package electron for Fedora. The big 
> > problem is the included ffmpeg. With openSUSE I can just use the system 
> > ffmpeg, with Fedora I have to do some source code voodoo which I really
> > would 
 like to avoid.
> 
> 
> Maintaining such package would require keeping watch for any new files
> you'd need to include and going through legal review each time you do.

Did you take a look how they solved it at SUSE?

You have list for encoder and decoders which are allowed to be built. So if a 
new encoder or decoder would be added, it would just not be built. You will 
just always end up with the same set of encoders/decoders with every update.

Packman uses the exact same package as openSUSE and all it does it to enable 
all encoders and decoders.

All packages requiring ffmpeg can just always be built against the system 
version.

It should be less legal work, as you have to check just one package and not 
several which might include it as third_party source code.

> IMO it's much less work to just maintain everything that depends on
> FFmpeg in RPM Fusion.
>
> If you're determined, however, you could start with what Chromium does:
> https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh

How is it less work if you need to clean ffmpeg source codes in several 
projects which include it instead of just linking the system one? It is more 
prone to errors to remove sources and you have to track it instead of just 
having a fixed decoder/encoder set you build.

> Feel free to flag me for package review. I 

Best regards


Andreas

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-IoT-35-20211108.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

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

ID: 1055901 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1055901

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

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

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

Passed openQA tests: 15/16 (x86_64), 14/15 (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: deltarpm usefulness?

[Samuel Sieb]

On 11/8/21 01:23, Demi Marie Obenour wrote:

On 11/7/21 12:15 AM, Sumit Bhardwaj wrote:

It is not always about speed. There are still plenty of places in the world
where people are on limited data plans and to them using delta rpms makes a
lot of sense. They can work with slow speeds but not with high data
expenses. So i feel turning it on by default and having a setting to turn
it off is still a sane choice. Just my 2 cents.


Regards,
Sumit Bhardwaj


I recommend that deltarpms be disabled by default as they increase attack
surface.  Users who need deltarpms to be enabled can turn them on manually.
In the future, deltarpms should be cryptographically signed, which would
mitigate these concerns.


This has been discussed before.  The deltarpms don't need to be signed, 
it's irrelevant.  The resulting rpm is signed and the signature is 
checked before installing.

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

[Fabio Valentini]

On Sat, Nov 6, 2021 at 11:47 PM Marius Schwarz  wrote:
>
> Am 11.08.21 um 22:03 schrieb Marek Marczykowski-Górecki:
> > - there is also argument that people's connection bandwidth nowadays
> > tends to be fast enough to make the package rebuilding actually
> > slower than downloading the whole package (but that really vary between
> > different installations)
>
> Since we now have Linux on smartphonesd, i heavily disagree with this
> assumption and advocate to expand the drpm usage.

How would you suggest to do that?

From what I can tell, drpms are most useful if you update your system
daily (because deltas are only kept from one compose, and need storage
space) - but unless you have thousands of packages installed, the few
hundred KB - a few MB of download savings you get from drpms every day
(at most) are drowned out by the size of the daily repository metadata
download to even get those drpms. And if you update less often to
reduce the frequency with which you need to download the big repo
metadata, you might not get drpms for any updates at all.

So I don't think that there's *any* scenario where using drpms results
in a net reduction in MBs that need to be downloaded over time,
because either
- failed drpm reconstructions cause whole packages to be redownloaded anyway,
- very few packages have drpms in every update push,
- drpms are only kept for a very limited amount of time and limited
number of packages,
- savings from drpm usage is on the order of at most a few MB per
update per day, and less if not updating every day, but
- repository metadata downloads are reaching ~100MB / day, depending
on how many repos are enabled.

So ... am I missing something, or do drpms actually make things worse
in *every* respect right now?
- more MBs downloaded per update / per day in every scenario I can think of,
- more computationally intensive to reconstruct locally,
- needs compute time and storage space in Fedora build system,
- makes compose process more complicated.

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

Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Dominik 'Rathann' Mierzejewski]

On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
> Hi,
> 
> there are several packages in the distribution which require FFMPEG 
> (libavformat, libavcodec, etc.), one of them being chromium. The package 
> could 
> be created in a way that you can easily replace it with a version from 
> rpmfusion to get to the full encoder/decoder set including H264 etc.
> 
> This is working fine with openSUSE and packages from Packman.
> 
> https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
> 
> The Packman version always has a higher release version than the one in the 
> distribution.
> 
> I'm interested in this, as I try to package electron for Fedora. The big 
> problem is the included ffmpeg. With openSUSE I can just use the system 
> ffmpeg, with Fedora I have to do some source code voodoo which I really would 
> like to avoid.

Maintaining such package would require keeping watch for any new files
you'd need to include and going through legal review each time you do.

IMO it's much less work to just maintain everything that depends on
FFmpeg in RPM Fusion.

If you're determined, however, you could start with what Chromium does:
https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh

Feel free to flag me for package review. I one of the maintainers
of the ffmpeg package in RPM Fusion.

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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 08 November (Today)

[Ankur Sinha]

Hello everyone,

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

Matrix: https://matrix.to/#/#neuro:fedoraproject.org
IRC: https://webchat.libera.chat/?channels=#fedora-neuro

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&iso=20211108T13&p1=%3A&ah=1

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

- New introductions and roll call.
- Tasks from last meeting: 
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-10-25-13.01.html
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
- Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig
- 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 F36: 
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

Fedora-Cloud-34-20211108.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

Re: deltarpm usefulness?

[Michael Schroeder]

On Sat, Nov 06, 2021 at 07:43:02AM -, Daniel Alley wrote:
> Another issue - which is not per-se a security issue but it's still a problem 
> - is that deltarpm uses md5 checksums pervasively.  They're everywhere.  And 
> it uses its own implementation of md5 which doesn't respect FIPS, so even 
> when the user has *explicitly* configured their system to not use md5 for 
> anything security-relevant, libdeltarpm won't know or care.  

They are used as a consistency check, it might as well use crc32.
So I don't see why FIPS is a concern for you.

Cheers,
  Michael.

-- 
Michael Schroeder  SUSE Software Solutions Germany GmbH
m...@suse.de  GF: Felix Imendoerffer HRB 36809, AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: deltarpm usefulness?

[Demi Marie Obenour]

On 11/7/21 12:15 AM, Sumit Bhardwaj wrote:
> It is not always about speed. There are still plenty of places in the world
> where people are on limited data plans and to them using delta rpms makes a
> lot of sense. They can work with slow speeds but not with high data
> expenses. So i feel turning it on by default and having a setting to turn
> it off is still a sane choice. Just my 2 cents.
> 
> 
> Regards,
> Sumit Bhardwaj

I recommend that deltarpms be disabled by default as they increase attack
surface.  Users who need deltarpms to be enabled can turn them on manually.
In the future, deltarpms should be cryptographically signed, which would
mitigate these concerns.

Sincerely,
Demi Marie Obenour


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


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

Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora

[Andreas Schneider]

Hi,

there are several packages in the distribution which require FFMPEG 
(libavformat, libavcodec, etc.), one of them being chromium. The package could 
be created in a way that you can easily replace it with a version from 
rpmfusion to get to the full encoder/decoder set including H264 etc.

This is working fine with openSUSE and packages from Packman.

https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg

The Packman version always has a higher release version than the one in the 
distribution.

I'm interested in this, as I try to package electron for Fedora. The big 
problem is the included ffmpeg. With openSUSE I can just use the system 
ffmpeg, with Fedora I have to do some source code voodoo which I really would 
like to avoid.


Thanks for considering!


Best regards


Andreas

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

[Vít Ondruch]

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


Vít


Dne 07. 11. 21 v 19:27 Richard Shaw napsal(a):
I just upgraded to F35 and I'm trying to build a package via mock and 
I'm getting the following error:


/usr/bin/python3: /lib64/libc.so.6: version `GLIBC_2.34' not found 
(required by /var/tmp/tmp.mock.lxb87ex8/lib64/nosync.so)


Does it just need a rebuild or something?

Thanks,
Richard

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


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

Fedora-Cloud-35-20211108.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-35-20211107.0):

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

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

Automated formal verification of RPM packages

[Kamil Dudka]

Formal verification of RPM packages with CBMC, Divine, and Symbiotic is now
easier than ever before!  csmock plug-ins for these tools are now available
in stable Fedora releases.  The plug-ins are still experimental and they have
some technical limitations:

- They work only for source RPM packages that contain the %check section
  that directly or indirectly invokes the binaries produced in the %build
  section.

- The tools are known to work reliably only for programs written in C.

- Only one formal verification tool can be enabled in one run of csmock.

- Only *-x86_64 build roots are supported for now.

- The fedora-rawhide-x86_64 build root is not supported at the moment.


The plug-ins can be installed on a Fedora system using the following command:

$ sudo dnf install csmock-plugin-{cbmc,divine,symbiotic}

Then you can formally verify RPM packages of your choice:

$ csmock -r fedora-35-x86_64 -t ${tool} ${pkg}.src.rpm


These plug-ins were developed as part of the AUFOVER (Automation of Formal
Verification) research project:

https://research.redhat.com/blog/research_project/aufover-2/

Some useful tips can be found on the aufover/experiments wiki:

https://github.com/aufover/experiments


If you run into any issues please do not hesitate to reach out to us.
We welcome any feedback you may have as it will help us make further
improvements to the tools.

Kamil and the AUFOVER team

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