Fedora-Cloud-35-20220301.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-20220228.0):

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

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: Blender failed to build with ffmpeg enabled

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 2022/03/01 15:11:

Hello team,

Blender failed to build with enabled FFMPEG support using ffmpeg-free-devel at 
the following line:

'''

/builddir/build/BUILD/blender-3.0.1/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp:
 In member function 'void aud::FFMPEGReader::init(int)':
/builddir/build/BUILD/blender-3.0.1/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp:180:47:
 error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
   180 | AVCodec* aCodec = 
avcodec_find_decoder(m_formatCtx->streams[m_stream]->codecpar->codec_id);
   |   
^~~~
   |   |
   |   const AVCodec*
gmake[2]: *** [extern/audaspace/CMakeFiles/audaspace.dir/build.make:1549: 
extern/audaspace/CMakeFiles/audaspace.dir/plugins/ffmpeg/FFMPEGReader.cpp.o] 
Error 1

'''

Could someone handle the AVCodec issue please?
Available scratch-build result:
https://koji.fedoraproject.org/koji/taskinfo?taskID=83496011


Thanks in advance.



Change to const AVCodec* aCodec = avcodec_find_decoder(
ref:
https://github.com/blender/blender/commit/af6a1b08e3f0d0070ac9423868d2d3f81057717a

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

Blender failed to build with ffmpeg enabled

[Luya Tshimbalanga]

Hello team,

Blender failed to build with enabled FFMPEG support using 
ffmpeg-free-devel at the following line:


'''

/builddir/build/BUILD/blender-3.0.1/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp:
 In member function 'void aud::FFMPEGReader::init(int)':
/builddir/build/BUILD/blender-3.0.1/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp:180:47:
 error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
  180 | AVCodec* aCodec = 
avcodec_find_decoder(m_formatCtx->streams[m_stream]->codecpar->codec_id);
  |   
^~~~
  |   |
  |   const AVCodec*
gmake[2]: *** [extern/audaspace/CMakeFiles/audaspace.dir/build.make:1549: 
extern/audaspace/CMakeFiles/audaspace.dir/plugins/ffmpeg/FFMPEGReader.cpp.o] 
Error 1

'''

Could someone handle the AVCodec issue please?

Available scratch-build result:

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


Thanks in advance.

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: sphinx: Intention to orphan package

[Michal Schorm]

The ownership of the 'sphinx' package [1] has been transferred to me.

I've removed access for users 'brandfbb' and 'cdamian' to the package
(both had 'admin' privileges before) since there haven't been any
activity around the package from them for a _long_ time.
I've added user 'hhorak' with role 'admin' as a backup, should I be unreachable.

In the case anybody is interested to contribute, feel free to contact
me and I'll assign you the access rights accordingly - if needed at
all. (As I prefer PR workflow)

I do not intend to maintain the package once there will be no other
package depending on 'sphinx'.
However the decision and eventual deprecation and removal of the
Sphinx SE from the MariaDB server will take time (a ~ year ?), so I
don't expect it to be anytime soon.

[1] https://src.fedoraproject.org/rpms/sphinx

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Mon, Feb 28, 2022 at 11:38 AM Michal Schorm  wrote:
>
> 1/ Go to the package page:
> https://src.fedoraproject.org/rpms/sphinx
>
> 2/ Log in
>
> 3/ On top bar go to "Settings"
> (next to "Source", "Issues", "Pull Requests", "Stats")
>
> 4/ Left column "Give project"
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Mon, Feb 28, 2022 at 11:28 AM Sergio Arroutbi  wrote:
> >
> > It makes sense to hand it over to you. I am OK with it.
> >
> > Does anybody have a guide on how to do so?
> >
> > On Mon, Feb 28, 2022 at 10:18 AM Michal Schorm  wrote:
> >>
> >> Sorry for the delay.
> >> I checked with MariaDB upstream.
> >> 
> >> https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/Sphinx.20SE
> >>
> >> The upstream last updated the version they are using ~7 years ago to
> >> version 2.2.6 and since it isn't a very important storage engine, it
> >> might be best to deprecate and remove it in the future.
> >>
> >> I offer to take over the package myself, and put the best effort I'll
> >> find to keep it alive and orphan it once MariaDB stops using it or it
> >> just won't build anymore.
> >>
> >> Michal
> >>
> >> --
> >>
> >> Michal Schorm
> >> Software Engineer
> >> Core Services - Databases Team
> >> Red Hat
> >>
> >> --
> >>
> >> On Thu, Jan 13, 2022 at 2:17 PM Michal Schorm  wrote:
> >> >
> >> > MariaDB provides a Sphinx storage engine [1] which build is enabled in 
> >> > Fedora.
> >> > The 'mariadb' SPECfile mentions following requirements:
> >> >
> >> > BuildRequires:sphinx libsphinxclient libsphinxclient-devel
> >> > Requires: sphinx libsphinxclient
> >> >
> >> > I guess that orphaning all (C or Python) versions of Sphinx in Fedora
> >> > will make me unable to keep building this SE. (The fact that it is
> >> > available via Pip doesn't help me during a package build)
> >> >
> >> > I haven't looked at this piece of MariaDB in years, I have to check
> >> > both myself and with the MariaDB upstream - whether they are aware of
> >> > this situation or if they already have a plan.
> >> >
> >> > [1] http://mariadb.com/kb/en/about-sphinxse/
> >> >
> >> > --
> >> >
> >> > Michal Schorm
> >> > Software Engineer
> >> > Core Services - Databases Team
> >> > Red Hat
> >> >
> >> > --
> >> >
> >> > On Thu, Jan 13, 2022 at 1:48 PM Vitaly Zaitsev via devel
> >> >  wrote:
> >> > >
> >> > > On 13/01/2022 13:33, Sergio Arroutbi wrote:
> >> > > > Latest binary versions from previous link (for example, v3.4.1) link 
> >> > > > to
> >> > > > python base source code.
> >> > >
> >> > > Also they decided co close sources last year:
> >> > >
> >> > > > 3.0 and up sources are currently only available under a delayed FOSS 
> >> > > > or commercial licenses for several reasons; going back to regular 
> >> > > > plain old GPL is planned but timing is moot; so email us if you 
> >> > > > require the sources immediately.
> >> > > >
> >> > > > Sources for previous 2.x versions can be found either in the Archive 
> >> > > > below or on GitHub, github.com/sphinxsearch/sphinx
> >> > >
> >> > > --
> >> > > 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
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraprojec

Re: Why I get some random notifications from discourse?

[Otto Urpelainen]

Vít Ondruch kirjoitti 25.2.2022 klo 21.08:
Is that intentional that i get some random notifications from Discourse 
or what is going on? In past month, I was notified about following topics:



* Join us for the EPEL office hours every month [Fedora] epel

* It's #FedoraShareYourScreen week [Fedora] events


These two could explained by this from "From Navigating Fedora 
Discussion — Tags, Categories, and Concepts" [1]: " As a new site user, 
you’ll be set to Watching First Post for :category_news: News & 
Announcements, and to Tracking for the Podcast and Community Blog 
subcategories."


> * Self-intro glaringgibbon [Fedora] introductions
>
> * Tempted to switch full-time to Fedora, but I got some noob questions
> [Fedora] introductions

No idea why you got these two.

[1]: 
https://discussion.fedoraproject.org/t/navigating-fedora-discussion-tags-categories-and-concepts/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

List of long term FTBFS packages to be retired tomorrow

[Miro Hrončok]

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 36 approximately one week before branching.

However, 5 weekly reminders are required and I forgot to start this sooner,
hence the retirement will happen tomorrow, i.e. March 1st 2022.
Since this is after the Beta Freeze,
I will skip retiring components with depending packages.
Such components (if any) will be retired during the next release cycle,
and are included in this report for completeness.

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


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

This report is based on dist tags.

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

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


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

   Package   (co)maintainers
==
libicu65 pwalter
rubygem-cucumber-rails   orphan
rubygem-sup  dcallagh, jaruga, ruby-packagers-sig, shreyankg
tmux-top ttomecek

All listed packages are leaf packages, nothing depends on them.

Affected (co)maintainers
dcallagh: rubygem-sup
jaruga: rubygem-sup
pwalter: libicu65
ruby-packagers-sig: rubygem-sup
shreyankg: rubygem-sup
ttomecek: tmux-top

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

Re: VERY late notification emails

[Richard Shaw]

On Mon, Feb 28, 2022 at 11:25 AM Kevin Fenzi  wrote:

> On Mon, Feb 28, 2022 at 07:45:27AM -0600, Richard Shaw wrote:
> > I almost wrote this a week ago but decided not to as it's been recently
> > discussed but this is really annoying. 6 days later is more than useless.
> >
> > Previously it was blamed, at least partially, on the mass rebuild, but
> > clearly that should no longer be an issue by now?
>
> Well, I noted a number of reasons for it... one of them was that it
> sometimes crashes, but appears to be processing. This happened a few
> days ago and it was just restarted this morning. ;(
>
> Ahh. Ok. At least that explains it!
>



> > I know I can turn them off, but I actually LIKE the messages if they were
> > delivered promptly.
> >
> > Is there really nothing we can do about this?
>
> No, there's things we can do and are trying to do. ;)
>
> But of course more help welcome!
>
> We have a python3 port of it nearly ready to go, but I think it's
> CI/tests are not working, and we want to make sure those all work before
> we deploy it. I'll see if I can get more exact status...
>
> There's also been a lot of talk about re-writing it. Ryan just posted
> recently asking for folks use cases and pain points for that.
>
> I'll see about making it restart every day perhaps to make sure it's
> actually processing.


I've used this in a SystemD service file for a chromium based dashboard on
a RPi:

# Restart every 8 hours
RuntimeMaxSec=28800

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

Re: New tool - license-validate

[David Cantrell]

On Tue, Jan 11, 2022 at 11:32:12AM +0100, Fabio Valentini wrote:

On Mon, Jan 10, 2022 at 5:41 PM David Cantrell  wrote:


On Wed, Jan 05, 2022 at 02:59:33AM +0100, Miroslav Suchý wrote:
>Dne 04. 01. 22 v 21:03 David Cantrell napsal(a):
>>One of the difficult things with the Fedora abbreviations is that
>>tokens can have spaces in them.  For example, the Apache 2.0 license
>>in Fedora is called "ASL 2.0".  This makes it really hard to work with
>>in software.
>>
>>Likewise, we have historically allowed full expressions through that
>>contain otherwise forbidden licenses.  For example, many Perl module
>>packages use the License tag "GPL+ or Artistic" so in a way that
>>entire expression is treated as a token.
>>
>>This information is currently captured in this JSON file (not the
>>original author, but I make use of the file):
>>
>>https://github.com/rpminspect/rpminspect-data-fedora/blob/master/licenses/fedora.json
>>
>>rpminspect's license check uses this data to validate the License tag
>>in RPM headers based on the rules as they exist in the packaging
>>guidelines plus the assorted expressions we have historically allowed
>>through that would not otherwise validate.
>
>*nod*
>
>The string
>
> 'GPL+ or Artistic or MIT'
>
>evaluates license-validate as correct, while rpminspect results that as bad 
license.

But this expression is not valid.  It would be valid as

 (GPL+ or Artistic) or MIT


That's probably splitting hairs.
The "and" and "or" boolean connectives are associative, so the
parentheses can be dropped without losing information.
Something different would be mixing "and" and "or", then the
parentheses are necessary to preserve structural information.
But for a list of only-"or"-ed or only-"and"-ed licenses, no
parentheses are necessary.


Correct when taking the tokens individually.  I was basing my reply on the
fact that Fedora had approved "GPL+ or Artistic" as a single token.
Separately GPL+ is approved and Artistic is not approved.  Again, just looking
at the data as found in spec files and the approved license list.

Since this thread, this topic has been discussed and addressing the
inconsistency here is part of the license data cleanup effort.

Thanks,

--
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: Questions about new free-only FFMPEG in Fedora repos

[Robbie Harwood]

Neal Gompa  writes:

> And we're not the first to offer reduced functionality
> FFmpeg (both Debian and openSUSE do too, so we're in good company
> here).

I don't think that's an accurate characterization of what Debian does.
See
https://sources.debian.org/src/ffmpeg/7%3A4.4.1-3/debian/README.Debian/
which states that it's built with "as many features as possible" while
still being GPL-compatible.

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

Re: Release criteria proposal: networking requirements

[Adam Williamson]

On Fri, 2020-08-28 at 16:59 -0700, Adam Williamson wrote:
> On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
> > Hi folks!
> > 
> > So at this week's blocker review meeting, the fact that we don't have
> > explicit networking requirements in the release criteria really started
> > to bite us. In the past we have squeezed networking-related issues in
> > under other criteria, but for some issues that's really difficult,
> > notably VPN issues. So, we agreed we should draft some explicit
> > networking criteria.
> 
> Update: here's a second draft with feedback so far incorporated, thanks
> to everyone. Still mulling over whether/how to split it more across
> milestones.
> 
> === Network requirements ===
> 
> Each of these requirements apply to both installer and installed system
> environments. For any given installer environment, the 'default network
> configuration tools' are considered to be those the installer documents
> as supported ways to configure networking (e.g. for anaconda-based
> environments, configuration via kernel command line options, a
> kickstart, or interactively in anaconda itself are included).
> 
>  Basic networking 
> 
> It must be possible to establish both IPv4 and IPv6 network connections
> using both typical router-provided addressing systems (e.g. DHCP on
> IPv4 or SLAAC or IPv6) and static addressing. The default network
> configuration tools for the console, for release-blocking desktops and
> for installer environments must work well enough to allow typical
> network connection configuration operations without major workarounds.
> Standard network functions such as address resolution and connections
> with common protocols such as ping, HTTP and ssh must work as expected.
> 
> Footnote titled "Supported hardware": Supported network hardware is
> hardware for which the Fedora kernel includes drivers and, where
> necessary, for which a firmware package is available. If support for a
> commonly-used piece or type of network hardware that would usually be
> present is omitted, that may constitute a violation of this criterion,
> after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
> issues|normal factors for hardware-dependent issues]]. Similarly,
> violations of this criteria that are hardware or configuration
> dependent are, as usual, subject to consideration of those factors when
> determining whether they are release-blocking
> 
>  VPN connections 
> 
> Using the default network configuration tools for the console and for
> release-blocking desktops, it must be possible to establish a working
> connection to common OpenVPN, openconnect-supported and vpnc-supported
> VPN servers with typical configurations.
> 
> Footnote titled "Supported servers and configurations": As there are
> many different VPN server applications and configurations, blocker
> reviewers must use their best judgment in determining whether
> violations of this criterion are likely to be encountered commonly
> enough to block a release, and if so, at which milestone. As a general
> principle, the more people are likely to use affected servers and the
> less complicated the configuration required to hit the bug, the more
> likely it is to be a blocker.

So, uh, we sorta forgot about this. Kamil approved this draft, but
nobody else gave any feedback on it. This topic is still relevant and
we have a proposed VPN blocker today, so...any more feedback on this
draft?
-- 
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: VERY late notification emails

[Kevin Fenzi]

On Mon, Feb 28, 2022 at 07:45:27AM -0600, Richard Shaw wrote:
> I almost wrote this a week ago but decided not to as it's been recently
> discussed but this is really annoying. 6 days later is more than useless.
> 
> Previously it was blamed, at least partially, on the mass rebuild, but
> clearly that should no longer be an issue by now?

Well, I noted a number of reasons for it... one of them was that it
sometimes crashes, but appears to be processing. This happened a few
days ago and it was just restarted this morning. ;( 

> 
> I know I can turn them off, but I actually LIKE the messages if they were
> delivered promptly.
> 
> Is there really nothing we can do about this?

No, there's things we can do and are trying to do. ;) 

But of course more help welcome!

We have a python3 port of it nearly ready to go, but I think it's
CI/tests are not working, and we want to make sure those all work before
we deploy it. I'll see if I can get more exact status... 

There's also been a lot of talk about re-writing it. Ryan just posted
recently asking for folks use cases and pain points for that. 

I'll see about making it restart every day perhaps to make sure it's
actually processing. 

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: [Test-Announce] 2022-02-28 @ 16:00 UTC - Fedora QA Meeting

[Luna Jernberg]

Did attend this week

On Sat, Feb 26, 2022 at 4:01 AM Adam Williamson 
wrote:

> # Fedora Quality Assurance Meeting
> # Date: 2022-02-28
> # Time: 16:00 UTC
> (https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
> # Location: #fedora-meeting on irc.libera.chat
>
> Greetings testers!
>
> It's been a while since we met, so let's get together and see where
> we're at for Fedora 36 and so on.
>
> If anyone has any other items for the agenda, please reply to this
> email and suggest them! Thanks.
>
> == Proposed Agenda Topics ==
>
> 1. Previous meeting follow-up
> 2. Fedora 36 status
> 3. Current criteria / test case proposals
> 4. Test Day / community event status
> 5. Open floor
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
> ___
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20220228.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/15 (aarch64)

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

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

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

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

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-36-20220227.0):

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

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

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.16 to 0.43
Previous test data: https://openqa.fedoraproject.org/tests/1151176#downloads
Current test data: https://openqa.fedoraproject.org/tests/1152728#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-36-20220228.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 9/229 (x86_64), 14/161 (aarch64)

New failures (same test not failed in Fedora-36-20220227.n.0):

ID: 1152255 Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1152255
ID: 1152284 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1152284
ID: 1152336 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/1152336
ID: 1152357 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1152357
ID: 1152359 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/1152359
ID: 1152387 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1152387
ID: 1152397 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1152397
ID: 1152436 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1152436
ID: 1152446 Test: x86_64 universal install_blivet_with_swap
URL: https://openqa.fedoraproject.org/tests/1152446
ID: 1152477 Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/1152477

Old failures (same test failed in Fedora-36-20220227.n.0):

ID: 1152266 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1152266
ID: 1152270 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1152270
ID: 1152293 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1152293
ID: 1152315 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1152315
ID: 1152335 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/1152335
ID: 1152358 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1152358
ID: 1152384 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1152384
ID: 1152435 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1152435
ID: 1152449 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1152449
ID: 1152468 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1152468
ID: 1152524 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1152524
ID: 1152536 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1152536
ID: 1152542 Test: aarch64 universal install_shrink_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1152542

Soft failed openQA tests: 12/161 (aarch64), 15/229 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 1152545 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1152545
ID: 1152563 Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1152563

Old soft failures (same test soft failed in Fedora-36-20220227.n.0):

ID: 1152254 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1152254
ID: 1152291 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1152291
ID: 1152299 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1152299
ID: 1152386 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1152386
ID: 1152398 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1152398
ID: 1152420 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1152420
ID: 1152423 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1152423
ID: 1152443 Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1152443
ID: 1152444 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/1152444
ID: 1152445 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/1152445
ID: 1152453 Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/1152453
ID: 1152463 Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/1152463
ID: 1152473 Test: x86_64 universal upgrade_2

Re: RPM question: How to get the package VR from a dependency generator

[Panu Matilainen]

On 2/28/22 16:32, Richard W.M. Jones wrote:

On Mon, Feb 28, 2022 at 04:26:02PM +0200, Panu Matilainen wrote:

On 2/28/22 16:12, Richard W.M. Jones wrote:

On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:


I'm writing a simple provides generator.  The documentation is a bit
light on detail:

   
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html

How do I get the version-release of the package currently being built?
At the moment I can only print simple provides like:

   Provides: foo

but I want to include the version of the package being built, eg:

   Provides: foo = 1.2-3.fc36

In theory it seems like the environment variables $RPM_PACKAGE_VERSION
and $RPM_PACKAGE_RELEASE should be set in the dependency generator,
but I just confirmed they are not set.


I dumped out the environment from the dependency generator and the
only RPM-specific environment variable is $RPM_BUILD_ROOT.  I could
get the version from that, but it would be a bit of a hack.


Name, epoch, version and release are available as macros in the
.attr file so you can pass what you need from there, eg to pass
version and release as arguments to the provides generator, you can
do:

%__my_provides /path/to/my/depgen %{version} %{release}

This seems to be missing in the docs, will fix.


Ah nice, I didn't realise you could add parameters there.


Yup, what's in there is entirely up to you, rpm only cares about the 
output. Those lines are macro-expanded at the time of launching the 
script and can have arbitrarily complex macros in them.  In fact you can 
nowadays generate dependencies directly from macro where it makes sense 
("parametric macro generators" in the docs)


And actually the per-package exported macros *are* documented (just 
above parametric generators), it just doesn't explain how to use them. 
Something to fix anyway :)


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

Re: RPM question: How to get the package VR from a dependency generator

[Florian Weimer]

* Panu Matilainen:

> On 2/28/22 16:12, Richard W.M. Jones wrote:
>> On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:
>>>
>>> I'm writing a simple provides generator.  The documentation is a bit
>>> light on detail:
>>>
>>>
>>> https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
>>>
>>> How do I get the version-release of the package currently being built?
>>> At the moment I can only print simple provides like:
>>>
>>>Provides: foo
>>>
>>> but I want to include the version of the package being built, eg:
>>>
>>>Provides: foo = 1.2-3.fc36
>>>
>>> In theory it seems like the environment variables $RPM_PACKAGE_VERSION
>>> and $RPM_PACKAGE_RELEASE should be set in the dependency generator,
>>> but I just confirmed they are not set.
>> I dumped out the environment from the dependency generator and the
>> only RPM-specific environment variable is $RPM_BUILD_ROOT.  I could
>> get the version from that, but it would be a bit of a hack.
>
> Name, epoch, version and release are available as macros in the .attr
> file so you can pass what you need from there, eg to pass version and 
> release as arguments to the provides generator, you can do:
>
> %__my_provides /path/to/my/depgen %{version} %{release}
>
> This seems to be missing in the docs, will fix.

Please also document the uppercase variants (issue 1736).  Thanks. 8-)

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: RPM question: How to get the package VR from a dependency generator

[Richard W.M. Jones]

On Mon, Feb 28, 2022 at 04:26:02PM +0200, Panu Matilainen wrote:
> On 2/28/22 16:12, Richard W.M. Jones wrote:
> >On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:
> >>
> >>I'm writing a simple provides generator.  The documentation is a bit
> >>light on detail:
> >>
> >>   
> >> https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
> >>
> >>How do I get the version-release of the package currently being built?
> >>At the moment I can only print simple provides like:
> >>
> >>   Provides: foo
> >>
> >>but I want to include the version of the package being built, eg:
> >>
> >>   Provides: foo = 1.2-3.fc36
> >>
> >>In theory it seems like the environment variables $RPM_PACKAGE_VERSION
> >>and $RPM_PACKAGE_RELEASE should be set in the dependency generator,
> >>but I just confirmed they are not set.
> >
> >I dumped out the environment from the dependency generator and the
> >only RPM-specific environment variable is $RPM_BUILD_ROOT.  I could
> >get the version from that, but it would be a bit of a hack.
> 
> Name, epoch, version and release are available as macros in the
> .attr file so you can pass what you need from there, eg to pass
> version and release as arguments to the provides generator, you can
> do:
> 
> %__my_provides /path/to/my/depgen %{version} %{release}
> 
> This seems to be missing in the docs, will fix.

Ah nice, I didn't realise you could add parameters there.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: RPM question: How to get the package VR from a dependency generator

[Panu Matilainen]

On 2/28/22 16:12, Richard W.M. Jones wrote:

On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:


I'm writing a simple provides generator.  The documentation is a bit
light on detail:

   
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html

How do I get the version-release of the package currently being built?
At the moment I can only print simple provides like:

   Provides: foo

but I want to include the version of the package being built, eg:

   Provides: foo = 1.2-3.fc36

In theory it seems like the environment variables $RPM_PACKAGE_VERSION
and $RPM_PACKAGE_RELEASE should be set in the dependency generator,
but I just confirmed they are not set.


I dumped out the environment from the dependency generator and the
only RPM-specific environment variable is $RPM_BUILD_ROOT.  I could
get the version from that, but it would be a bit of a hack.


Name, epoch, version and release are available as macros in the .attr 
file so you can pass what you need from there, eg to pass version and 
release as arguments to the provides generator, you can do:


%__my_provides /path/to/my/depgen %{version} %{release}

This seems to be missing in the docs, will fix.

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

Re: RPM question: How to get the package VR from a dependency generator

[Richard W.M. Jones]

On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:
> 
> I'm writing a simple provides generator.  The documentation is a bit
> light on detail:
> 
>   
> https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
> 
> How do I get the version-release of the package currently being built?
> At the moment I can only print simple provides like:
> 
>   Provides: foo
> 
> but I want to include the version of the package being built, eg:
> 
>   Provides: foo = 1.2-3.fc36
> 
> In theory it seems like the environment variables $RPM_PACKAGE_VERSION
> and $RPM_PACKAGE_RELEASE should be set in the dependency generator,
> but I just confirmed they are not set.

I dumped out the environment from the dependency generator and the
only RPM-specific environment variable is $RPM_BUILD_ROOT.  I could
get the version from that, but it would be a bit of a hack.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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-20220228.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

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

Failed openQA tests: 30/231 (x86_64), 27/161 (aarch64)

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

ID: 1151822 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1151822
ID: 1151823 Test: x86_64 Workstation-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1151823
ID: 1151831 Test: x86_64 Workstation-live-iso desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1151831
ID: 1151834 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1151834
ID: 1151836 Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/1151836
ID: 1151837 Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/1151837
ID: 1151864 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1151864
ID: 1151910 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/1151910
ID: 1151911 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/1151911
ID: 1151926 Test: aarch64 Server-dvd-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1151926
ID: 1151934 Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/1151934
ID: 1151984 Test: x86_64 Workstation-upgrade unwanted_packages
URL: https://openqa.fedoraproject.org/tests/1151984
ID: 1151992 Test: x86_64 Workstation-upgrade desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1151992
ID: 1151993 Test: x86_64 Workstation-upgrade evince
URL: https://openqa.fedoraproject.org/tests/1151993
ID: 1152012 Test: aarch64 Workstation-upgrade unwanted_packages@uefi
URL: https://openqa.fedoraproject.org/tests/1152012
ID: 1152030 Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/1152030
ID: 1152076 Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/1152076
ID: 1152124 Test: aarch64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/1152124
ID: 1152133 Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1152133
ID: 1152164 Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1152164

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

ID: 1151792 Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/1151792
ID: 1151810 Test: x86_64 Workstation-live-iso evince
URL: https://openqa.fedoraproject.org/tests/1151810
ID: 1151814 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1151814
ID: 1151824 Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/1151824
ID: 1151827 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1151827
ID: 1151829 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1151829
ID: 1151830 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1151830
ID: 1151833 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1151833
ID: 1151866 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1151866
ID: 1151912 Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/1151912
ID: 1151932 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1151932
ID: 1151933 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1151933
ID: 1151951 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1151951
ID: 1151952 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1151952
ID: 1151954 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1151954
ID: 1151959 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1151959
ID: 1151961 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1151961
ID: 1151962 Test: aarch64 Workstation-raw_xz-raw.xz

Fedora-IoT-37-20220228.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

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

New failures (same test not failed in Fedora-IoT-37-20220227.0):

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

Old failures (same test failed in Fedora-IoT-37-20220227.0):

ID: 1152564 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1152564
ID: 1152565 Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1152565
ID: 1152580 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1152580
ID: 1152589 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/1152589

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

Skipped non-gating openQA tests: 13 of 31

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
Used mem changed from 181 MiB to 223 MiB
System load changed from 0.38 to 0.63
Previous test data: https://openqa.fedoraproject.org/tests/1151145#downloads
Current test data: https://openqa.fedoraproject.org/tests/1152581#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

RPM question: How to get the package VR from a dependency generator

[Richard W.M. Jones]

I'm writing a simple provides generator.  The documentation is a bit
light on detail:

  
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html

How do I get the version-release of the package currently being built?
At the moment I can only print simple provides like:

  Provides: foo

but I want to include the version of the package being built, eg:

  Provides: foo = 1.2-3.fc36

In theory it seems like the environment variables $RPM_PACKAGE_VERSION
and $RPM_PACKAGE_RELEASE should be set in the dependency generator,
but I just confirmed they are not set.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

VERY late notification emails

[Richard Shaw]

I almost wrote this a week ago but decided not to as it's been recently
discussed but this is really annoying. 6 days later is more than useless.

Previously it was blamed, at least partially, on the mass rebuild, but
clearly that should no longer be an issue by now?

I know I can turn them off, but I actually LIKE the messages if they were
delivered promptly.

Is there really nothing we can do about this?

Thanks,
Richard

-- Forwarded message -
From: 
Date: Sun, Feb 27, 2022 at 6:09 PM
Subject: hobbes1069's mingw-fltk-1.3.8-1.fc36 completed
To: 


Notification time stamped 2022-02-21 13:42:00 UTC

hobbes1069's mingw-fltk-1.3.8-1.fc36 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=1921324
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Questions about new free-only FFMPEG in Fedora repos

[Neal Gompa]

On Mon, Feb 28, 2022 at 7:39 AM Vitaly Zaitsev via devel
 wrote:
>
> On 28/02/2022 13:35, Neal Gompa wrote:
> > Fortunately, that's where we can bring value to the ecosystem, as
> > we're supposed to be capable enough to work with upstreams to fix
> > broken code
>
> Feel free to start with Telegram Desktop[1]. :-)
>
> [1]: https://github.com/telegramdesktop/tdesktop
>

Seems that they have a wrapper function already, so it should be
straightforward for someone to adjust it:
https://github.com/telegramdesktop/tdesktop/blob/ca21b7efaed21b83ae5a75343f0567db141c9eba/Telegram/SourceFiles/ffmpeg/ffmpeg_utility.cpp#L157-L162



-- 
真実はいつも一つ！/ 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: Questions about new free-only FFMPEG in Fedora repos

[Vitaly Zaitsev via devel]

On 28/02/2022 13:35, Neal Gompa wrote:

Fortunately, that's where we can bring value to the ecosystem, as
we're supposed to be capable enough to work with upstreams to fix
broken code


Feel free to start with Telegram Desktop[1]. :-)

[1]: https://github.com/telegramdesktop/tdesktop

--
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-Cloud-34-20220228.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-20220227.0):

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

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: Questions about new free-only FFMPEG in Fedora repos

[Neal Gompa]

On Mon, Feb 28, 2022 at 7:11 AM Vitaly Zaitsev via devel
 wrote:
>
> On 28/02/2022 03:45, Ian McInerney via devel wrote:
> > How are these removed codecs handled in the library?
>
> ffmpeg is a monolithic library.
>

ffmpeg is a set of libraries. The libavcodec library is a monolithic
library of compiled-in codec code.

> > Can we link an upstream application against FFMPEG in Fedora now and have 
> > it gracefully fail when it tries to access a non-free codec that was 
> > removed, or does the removal of these codecs create a different API that 
> > upstream applications would have to code around?
>
> Applications need to use a special API to check if the codec is
> available before attempting to use it. Otherwise, the application will
> instantly crash.
>

It's not a special API, it's how you're supposed to use libavcodec.

If you know you need a specific codec, you're supposed to use
avcodec_find_decoder()/avcodec_find_encoder() and check if it's even
available and before trying to initialize it, since you need the
AVCodec struct for the codec to pass into the initializer function. If
those functions return NULL, then you're supposed to gracefully fail.

And if you want to know what codecs are provided by FFmpeg, you are
supposed to use av_codec_iterate() to identify all the registered
codecs in libavcodec that are functional and use that to populate what
your application can work with. This lets you collect AVCodec structs
for all the codecs built in FFmpeg for you to do something with it.

Most applications will probably want to do the latter and do their own
prioritization/handling of codec alternatives, because that lets
applications expose hardware acceleration options.

Applications not doing this properly are broken, because this is
literally how you're supposed to use libavcodec.

> > 2) Is there an easily accessible list of the enabled codecs we can point 
> > upstreams to when talking about this?
> Most upstream developers don't want to deal with such situations: "Use
> our binary/snap/flatpak. It works fine".

Fortunately, that's where we can bring value to the ecosystem, as
we're supposed to be capable enough to work with upstreams to fix
broken code. And we're not the first to offer reduced functionality
FFmpeg (both Debian and openSUSE do too, so we're in good company
here).



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

Fedora 36 compose report: 20220228.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-36-20220227.n.0
NEW: Fedora-36-20220228.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Questions about new free-only FFMPEG in Fedora repos

[Vitaly Zaitsev via devel]

On 28/02/2022 03:45, Ian McInerney via devel wrote:

How are these removed codecs handled in the library?


ffmpeg is a monolithic library.


Can we link an upstream application against FFMPEG in Fedora now and have it 
gracefully fail when it tries to access a non-free codec that was removed, or 
does the removal of these codecs create a different API that upstream 
applications would have to code around?


Applications need to use a special API to check if the codec is 
available before attempting to use it. Otherwise, the application will 
instantly crash.



2) Is there an easily accessible list of the enabled codecs we can point 
upstreams to when talking about this?
Most upstream developers don't want to deal with such situations: "Use 
our binary/snap/flatpak. It works fine".


--
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: sphinx: Intention to orphan package

[Michal Schorm]

1/ Go to the package page:
https://src.fedoraproject.org/rpms/sphinx

2/ Log in

3/ On top bar go to "Settings"
(next to "Source", "Issues", "Pull Requests", "Stats")

4/ Left column "Give project"

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Mon, Feb 28, 2022 at 11:28 AM Sergio Arroutbi  wrote:
>
> It makes sense to hand it over to you. I am OK with it.
>
> Does anybody have a guide on how to do so?
>
> On Mon, Feb 28, 2022 at 10:18 AM Michal Schorm  wrote:
>>
>> Sorry for the delay.
>> I checked with MariaDB upstream.
>> 
>> https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/Sphinx.20SE
>>
>> The upstream last updated the version they are using ~7 years ago to
>> version 2.2.6 and since it isn't a very important storage engine, it
>> might be best to deprecate and remove it in the future.
>>
>> I offer to take over the package myself, and put the best effort I'll
>> find to keep it alive and orphan it once MariaDB stops using it or it
>> just won't build anymore.
>>
>> Michal
>>
>> --
>>
>> Michal Schorm
>> Software Engineer
>> Core Services - Databases Team
>> Red Hat
>>
>> --
>>
>> On Thu, Jan 13, 2022 at 2:17 PM Michal Schorm  wrote:
>> >
>> > MariaDB provides a Sphinx storage engine [1] which build is enabled in 
>> > Fedora.
>> > The 'mariadb' SPECfile mentions following requirements:
>> >
>> > BuildRequires:sphinx libsphinxclient libsphinxclient-devel
>> > Requires: sphinx libsphinxclient
>> >
>> > I guess that orphaning all (C or Python) versions of Sphinx in Fedora
>> > will make me unable to keep building this SE. (The fact that it is
>> > available via Pip doesn't help me during a package build)
>> >
>> > I haven't looked at this piece of MariaDB in years, I have to check
>> > both myself and with the MariaDB upstream - whether they are aware of
>> > this situation or if they already have a plan.
>> >
>> > [1] http://mariadb.com/kb/en/about-sphinxse/
>> >
>> > --
>> >
>> > Michal Schorm
>> > Software Engineer
>> > Core Services - Databases Team
>> > Red Hat
>> >
>> > --
>> >
>> > On Thu, Jan 13, 2022 at 1:48 PM Vitaly Zaitsev via devel
>> >  wrote:
>> > >
>> > > On 13/01/2022 13:33, Sergio Arroutbi wrote:
>> > > > Latest binary versions from previous link (for example, v3.4.1) link to
>> > > > python base source code.
>> > >
>> > > Also they decided co close sources last year:
>> > >
>> > > > 3.0 and up sources are currently only available under a delayed FOSS 
>> > > > or commercial licenses for several reasons; going back to regular 
>> > > > plain old GPL is planned but timing is moot; so email us if you 
>> > > > require the sources immediately.
>> > > >
>> > > > Sources for previous 2.x versions can be found either in the Archive 
>> > > > below or on GitHub, github.com/sphinxsearch/sphinx
>> > >
>> > > --
>> > > 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
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/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
>
>
>
> --
> Sergio Arroutbi Braojos
> Software Engineer at Red Hat - Special Projects (SECENGSP)
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
htt

Re: sphinx: Intention to orphan package

[Sergio Arroutbi]

It makes sense to hand it over to you. I am OK with it.

Does anybody have a guide on how to do so?

On Mon, Feb 28, 2022 at 10:18 AM Michal Schorm  wrote:

> Sorry for the delay.
> I checked with MariaDB upstream.
>
> https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/Sphinx.20SE
>
> The upstream last updated the version they are using ~7 years ago to
> version 2.2.6 and since it isn't a very important storage engine, it
> might be best to deprecate and remove it in the future.
>
> I offer to take over the package myself, and put the best effort I'll
> find to keep it alive and orphan it once MariaDB stops using it or it
> just won't build anymore.
>
> Michal
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Thu, Jan 13, 2022 at 2:17 PM Michal Schorm  wrote:
> >
> > MariaDB provides a Sphinx storage engine [1] which build is enabled in
> Fedora.
> > The 'mariadb' SPECfile mentions following requirements:
> >
> > BuildRequires:sphinx libsphinxclient libsphinxclient-devel
> > Requires: sphinx libsphinxclient
> >
> > I guess that orphaning all (C or Python) versions of Sphinx in Fedora
> > will make me unable to keep building this SE. (The fact that it is
> > available via Pip doesn't help me during a package build)
> >
> > I haven't looked at this piece of MariaDB in years, I have to check
> > both myself and with the MariaDB upstream - whether they are aware of
> > this situation or if they already have a plan.
> >
> > [1] http://mariadb.com/kb/en/about-sphinxse/
> >
> > --
> >
> > Michal Schorm
> > Software Engineer
> > Core Services - Databases Team
> > Red Hat
> >
> > --
> >
> > On Thu, Jan 13, 2022 at 1:48 PM Vitaly Zaitsev via devel
> >  wrote:
> > >
> > > On 13/01/2022 13:33, Sergio Arroutbi wrote:
> > > > Latest binary versions from previous link (for example, v3.4.1) link
> to
> > > > python base source code.
> > >
> > > Also they decided co close sources last year:
> > >
> > > > 3.0 and up sources are currently only available under a delayed FOSS
> or commercial licenses for several reasons; going back to regular plain old
> GPL is planned but timing is moot; so email us if you require the sources
> immediately.
> > > >
> > > > Sources for previous 2.x versions can be found either in the Archive
> below or on GitHub, github.com/sphinxsearch/sphinx
> > >
> > > --
> > > 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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
>


-- 
Sergio Arroutbi Braojos
Software Engineer at Red Hat - Special Projects (SECENGSP)
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: CPU does not support x86-64-v2?

[Kevin Kofler via devel]

Gary Buhrmaster wrote:
> Just as with the elimination of 32-bit support
> (both x86, and the upcoming arm retirement)
> there will come a time for moving the baseline
> to x86-64-v2

I do not see the practical benefit of that. Performance-critical software 
can and should use runtime detection or ld.so runtime .so file selection.

> On the other hand, I would think that moving
> x86-64-v1 to be an alternative architecture
> (rather than primary) for those that need
> legacy support to be a potentially viable way
> forward.

That did not work for i686, so why would it work for x86_64 v1?

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

Fedora rawhide compose report: 20220228.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220227.n.0
NEW: Fedora-Rawhide-20220228.n.0

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

Size of added packages:  52.97 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.50 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20220228.n.0.aarch64.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: ansible-collection-community-rabbitmq-1.1.0-1.fc37
Summary: RabbitMQ collection for Ansible
RPMs:ansible-collection-community-rabbitmq
Size:52.97 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  alexandria-0.7.9-1.fc37
Old package:  alexandria-0.7.8-6.fc36.2
Summary:  Book collection manager
RPMs: alexandria
Size: 2.35 MiB
Size change:  -10.95 KiB
Changelog:
  * Sun Feb 27 2022 Mamoru TASAKA  - 0.7.9-1
  - 0.7.9


Package:  bottles-2022.2.28-1.fc37
Old package:  bottles-2022.2.14-1.fc37
Summary:  Easily manage Wine prefix in a new way
RPMs: bottles
Size: 330.92 KiB
Size change:  19.77 KiB
Changelog:
  * Sun Feb 27 2022 Artem Polishchuk  - 2022.2.28-1
  - chore(update): 2022.2.28


Package:  btrbk-0.32.1-1.fc37
Old package:  btrbk-0.32.0-1.fc36
Summary:  Tool for creating snapshots and remote backups of btrfs 
sub-volumes
RPMs: btrbk
Size: 127.63 KiB
Size change:  -17 B
Changelog:
  * Sun Feb 27 2022 Juan Orti Alcaine  - 0.32.1-1
  - Version 0.32.1 (#2058899)


Package:  dqlite-1.9.1-1.fc37
Old package:  dqlite-1.9.0-2.fc36
Summary:  Embeddable, replicated and fault tolerant SQL engine
RPMs: dqlite dqlite-devel
Size: 438.88 KiB
Size change:  74.41 KiB
Changelog:
  * Sun Feb 27 2022 Reto Gantenbein  - 1.9.1-1
  - Update to 1.9.1


Package:  dummy-test-package-gloster-0-7401.fc37
Old package:  dummy-test-package-gloster-0-7386.fc37
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 449.00 KiB
Size change:  960 B
Changelog:
  * Sun Feb 27 2022 packagerbot  - 0-7387
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7388
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7389
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7390
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7391
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7392
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7393
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7394
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7395
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7396
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7397
  - rebuilt

  * Sun Feb 27 2022 packagerbot  - 0-7398
  - rebuilt

  * Mon Feb 28 2022 packagerbot  - 0-7399
  - rebuilt

  * Mon Feb 28 2022 packagerbot  - 0-7400
  - rebuilt

  * Mon Feb 28 2022 packagerbot  - 0-7401
  - rebuilt


Package:  dunst-1.8.0-1.fc37
Old package:  dunst-1.7.3-3.fc36
Summary:  Lightweight and customizable notification-daemon
RPMs: dunst
Size: 516.54 KiB
Size change:  15.73 KiB
Changelog:
  * Sun Feb 27 2022 Aleksei Bavshin  - 1.8.0-1
  - Update to 1.8.0
  - Change default configuration path to /etc/xdg/dunst/ (only on f36 or later)


Package:  gcompris-qt-2.3-1.fc37
Old package:  gcompris-qt-2.2-1.fc37
Summary:  Educational software suite for children aged 2 to 10
RPMs: gcompris-qt gcompris-qt-activities
Size: 78.48 MiB
Size change:  -2.37 KiB
Changelog:
  * Sun Feb 27 2022 Andrea Musuruane  - 2.3-1
  - Updated to new upstream release


Package:  gpaste-3.42.6-1.fc37
Old package:  gpaste-3.42.5-1.fc37
Summary:  Clipboard management system
RPMs: gnome-shell-extension-gpaste gpaste gpaste-devel gpaste-libs 
gpaste-ui
Size: 1.57 MiB
Size change:  1.68 KiB
Changelog:
  * Sun Feb 27 2022 Mohamed El Morabity  - 
3.42.6-1
  - Update to 3.42.6


Package:  gpxsee-10.4-1.fc37
Old package:  gpxsee-10.2-1.fc36
Summary:  GPS log file viewer and analyzer
RPMs: gpxsee
Size: 4.87 MiB
Size change:  4.17 KiB
Changelog:
  * Mon Feb 21 2022 Nikola Forr??  - 10.4-1
  - Update to version 10.4
resolves: #2050236


Package:  igt-gpu-tools-1.26-1.20220227git5704955.fc37
Old package:  igt-gpu-tools-1.26-1.20220121gitf73008b.fc36
Summary:  Test suite and tools for DRM drivers
RPMs: igt-gpu-tools igt-gpu-tools-devel igt-gpu-tools-docs
Size: 14.86 MiB
Size change:  63.12 KiB
Changelog:
  * Sun Feb 27 2022 Lyude Paul  - 1.26-1.20220227git5704955
  - New git snapshot


Package:  indi-3rdparty-drivers-1.9.4-3.fc37
Old package:  indi-3rdparty-drivers-1.9.4-2.fc36
Summary:  INDI 3rdparty drivers
RPMs: indi-3rdparty-aagcloudwatcher-ng 
indi-3rdparty

Re: Next Open NeuroFedora Meeting: 1300 UTC on Monday, 28 February (Today)

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 28th
February (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=20220228T13&p1=%3A&ah=1

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

- New introductions and roll call.
- Tasks from last meeting: 
https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2022-02-14-13.00.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

Re: sphinx: Intention to orphan package

[Michal Schorm]

Sorry for the delay.
I checked with MariaDB upstream.

https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/Sphinx.20SE

The upstream last updated the version they are using ~7 years ago to
version 2.2.6 and since it isn't a very important storage engine, it
might be best to deprecate and remove it in the future.

I offer to take over the package myself, and put the best effort I'll
find to keep it alive and orphan it once MariaDB stops using it or it
just won't build anymore.

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Thu, Jan 13, 2022 at 2:17 PM Michal Schorm  wrote:
>
> MariaDB provides a Sphinx storage engine [1] which build is enabled in Fedora.
> The 'mariadb' SPECfile mentions following requirements:
>
> BuildRequires:sphinx libsphinxclient libsphinxclient-devel
> Requires: sphinx libsphinxclient
>
> I guess that orphaning all (C or Python) versions of Sphinx in Fedora
> will make me unable to keep building this SE. (The fact that it is
> available via Pip doesn't help me during a package build)
>
> I haven't looked at this piece of MariaDB in years, I have to check
> both myself and with the MariaDB upstream - whether they are aware of
> this situation or if they already have a plan.
>
> [1] http://mariadb.com/kb/en/about-sphinxse/
>
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Thu, Jan 13, 2022 at 1:48 PM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 13/01/2022 13:33, Sergio Arroutbi wrote:
> > > Latest binary versions from previous link (for example, v3.4.1) link to
> > > python base source code.
> >
> > Also they decided co close sources last year:
> >
> > > 3.0 and up sources are currently only available under a delayed FOSS or 
> > > commercial licenses for several reasons; going back to regular plain old 
> > > GPL is planned but timing is moot; so email us if you require the sources 
> > > immediately.
> > >
> > > Sources for previous 2.x versions can be found either in the Archive 
> > > below or on GitHub, github.com/sphinxsearch/sphinx
> >
> > --
> > 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20220228.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-20220227.0):

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

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: Questions about new free-only FFMPEG in Fedora repos

[Vít Ondruch]

Dne 28. 02. 22 v 7:06 Andreas Schneider napsal(a):

On Monday, February 28, 2022 3:45:55 AM CET Ian McInerney via devel wrote:

I noticed in the electron thread that we now have FFMPEG 5.0 in the
official Fedora repos, but this will of course mean that certain codecs are
removed due to legal concerns. This prompts a few questions though:

1) How are these removed codecs handled in the library? Can we link an
upstream application against FFMPEG in Fedora now and have it gracefully
fail when it tries to access a non-free codec that was removed, or does the
removal of these codecs create a different API that upstream applications
would have to code around? e.g. does it mean they have to add conditional
compilation for the specific codecs they need to use from FFMPEG instead of
just around FFMPEG itself?

FFMPEG has an API to query if support for a codec is compiled in or not.
Applications should check if the codec they want to use is available. If an
application just crashes, bugs should be reported that they should make
correct use of the FFMPEG API.


2) Is there an easily accessible list of the enabled codecs we can point
upstreams to when talking about this?

Applications should not care about our lists as it might change in future.
They should use the API of ffmpeg to check if a codec is available or not.


I hope that helps :-)



Shouldn't there be something like `Provides: ffmpeg-codec(foo)`? Not 
sure if that would be useful.



Vít




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