Fedora-Cloud-33-20210102.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210101.0): ID: 749623 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/749623 ID: 749630 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/749630 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
On Fri, Jan 1, 2021 at 7:59 PM Chris Murphy wrote: >Given this possibility, I think level 1 is the best > choice as a default for Fedora. ^ for the fstab mount option way of doing this for the entire file system. If one day there's 'btrfs property' support for levels, it's easy to imagine doing something like zstd:5 for /usr and /var/lib/flatpak because the limiting factor is not write performance but download bandwidth. Since there's effectively a wait for the download (slow no matter what from the cpu perspective) why not compress more? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2021-01-02 - 93% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/02/report-389-ds-base-1.4.4.9-1.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: thinking journal retention timelimits
Once upon a time, Chris Murphy said: > On Fri, Jan 1, 2021 at 4:54 PM Kevin Kofler via devel > wrote: > > I don't think we should be destroying data by default. There should be no > > expiry by default. > > Indirectly they already expire by default. It's just a different > expiration date for everyone, because the current policy depends on a > combination of free space remaining and maximum number of files. For systems with rsyslog installed, there's also already a default from logrotate, so setting a default expiration has plenty of precedent. And having a defined period would be MUCH better for consistency. Maybe I would add a note wherever that default is set that lower disk space could mean a shorter time though. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
On Fri, Jan 1, 2021 at 11:31 AM Artem Tim wrote: > > It's faster. Here is some benchmark with different zstd compression ratios > https://lkml.org/lkml/2019/1/28/1930. Could be outdated a little bit though. > > But for HDD it makes sense to increase it probably. And IIRC Chris wrote > about such plans. There are ideas but it's difficult because the kernel doesn't expose the information we really need to make an automatic determination. sysfs commonly misreports rotational devices as being non-rotational and vice versa. Since this is based on the device self-reporting, it's not great. I use zstd:1 for SSD/NVMe. And zstd:3 (which is the same as not specifying a level) for HDD/USB sticks/eMMC/SD Card. For the more archive style of backup, I use zstd:7. But these can all be mixed and matched, Btrfs doesn't care. You can even mix and match algorithms. Anyway, compress=zstd:1 is a good default. Everyone benefits, and I'm not even sure someone with a very fast NVMe drive will notice a slow down because the compression/decompression is threaded. I expect if we get the "fast" levels (the negative value levels) new to zstd in the kernel, that Btrfs will likely remap its level 1 to one of the negative levels, and keep level 3 set to zstd 3 (the default). So we might actually see it get even faster at the cost of some compression ratio. Given this possibility, I think level 1 is the best choice as a default for Fedora. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
A few more things: * btrfs-progs tools don't yet have a way to report compression information. While 'df' continues to report correctly about actual blocks used and free, both regular 'du' (coreutils) and 'btrfs filesystem du' will report uncompressed values. * 'compsize' will report compression information and is in Fedora repo for a while. But it requires privilege. * 'filefrag' misreports fragmentation, it always over reports fragments. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: OpenEXR + ilmbase = (new) openexr
All builds have completed in a side tag with the exception of gmic which looks to be failing for gcc 11 related issues? But only on 32-bit arches. https://koji.fedoraproject.org/koji/taskinfo?taskID=58753095 Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: thinking journal retention timelimits
On Fri, Jan 1, 2021 at 4:54 PM Kevin Kofler via devel wrote: > > Matthew Miller wrote: > > Right now, we don't set MaxRetentionSec, so journal expiry on Workstation > > is entirely based on disk usage. > > > > Logs can accidentally contain sensitive data, and it's just plain faster > > to work with them when there's less. I propose we set this to something > > like six months by default. > > I don't think we should be destroying data by default. There should be no > expiry by default. Indirectly they already expire by default. It's just a different expiration date for everyone, because the current policy depends on a combination of free space remaining and maximum number of files. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 15 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599 openjpeg2-2.3.1-10.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7c91badc19 guacamole-server-1.2.0-2.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ab8d229496 awstats-7.8-2.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a8b2c928f5 dia-0.97.3-16.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing nohang-0.2.0-1.el7 xrdp-0.9.15-2.el7 Details about builds: nohang-0.2.0-1.el7 (FEDORA-EPEL-2021-df7ebfb03d) Sophisticated low memory handler for Linux Update Information: Update to v0.2.0 ChangeLog: * Fri Jan 1 2021 Artem Polishchuk - 0.2.0-1 - build(update): 0.2.0 xrdp-0.9.15-2.el7 (FEDORA-EPEL-2020-606155a763) Open source remote desktop protocol (RDP) server Update Information: Release notes for xrdp v0.9.15 (2020/12/28) New features - Allow token sign in without autologon for SSO (#1667 #1668) - Norwegian keyboard support (#1675) - Improved config support for chansrv (#1635) - Unified chansrv, sesman and libxrdp logging (#1633 #1708 #1738) - thanks to @aquesnel - Support SUSE move to /usr/etc (#1702) - Parameters may now be specified for user-specified shell (#1270 #1695) - xrdp executables now allow alternative config files to be specified with -c (#1588 #1650 #1651) - sesrun improvements (#1741) - Drive redirection location can now be specified (#1048) - Now compiles on RISC-V (#1761) Bug fixes - Additional buffer overflow checks (#1662) - FUSE support now builds on 32-bit platforms (#1682) - genkeymap array size conflict fixed (#1691) - Buffering issue with neutrinordp over a slow link fixed (#1608 1634) - Various documentation fixes (#1704 #1741 #1755 #1759) - Prevent PAM info message from causing authentication failure (#1727) - Cosmetic fixes for minor issues (#1751 #1755 #1749) - Try harder to clean up socket files on session exit (#1740 #1756) - xrdp-chansrv become defunct in docker while file copy (#1658) Internal changes - Compilation warnings with newer compilers (#1659 #1680) - Continuation Integration checks on 32-bit platforms now include FUSE support (#1682) - Continuation Integration builds now default to the Ubuntu Focal platform (#1666) - FUSE type tidy-ups (#1686) - Switch from Travis CI to GitHub Actions (#1728 #1732) - Easier to set up console logging for utilities (#1711) ChangeLog: * Fri Jan 1 2021 Bojan Smojver - 1:0.9.15-2 - Use /usr/libexec/Xorg or Xorg session of Fedora and RHEL8+ * Tue Dec 29 2020 Bojan Smojver - 1:0.9.15-1 - Bump up to 0.9.15 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: thinking journal retention timelimits
On Fri, Jan 1, 2021 at 7:02 PM Matthew Miller wrote: > > On Sat, Jan 02, 2021 at 12:53:52AM +0100, Kevin Kofler via devel wrote: > > > Logs can accidentally contain sensitive data, and it's just plain faster > > > to work with them when there's less. I propose we set this to something > > > like six months by default. > > > > I don't think we should be destroying data by default. There should be no > > expiry by default. > > "Destroying data" seems a bit dramatic. We clean up temp files and so on all > the time. And the logs, of course, get trimmed if disk space is tight, so > there's already that. Keeping data forever just because isn't necessarily > inherently better. At $formeremployer, we had a policy of not keeping > anything longer than a year unless mandated to for regulatory reasons. There are religious wars about this over in the source control world. To some, the history is more important than the current state of the system. Convincing some advocates of this, that the history itself is also a program that is amenable to editing and modification, is sometimes quite an adventure. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: thinking journal retention timelimits
On Sat, Jan 02, 2021 at 12:53:52AM +0100, Kevin Kofler via devel wrote: > > Logs can accidentally contain sensitive data, and it's just plain faster > > to work with them when there's less. I propose we set this to something > > like six months by default. > > I don't think we should be destroying data by default. There should be no > expiry by default. "Destroying data" seems a bit dramatic. We clean up temp files and so on all the time. And the logs, of course, get trimmed if disk space is tight, so there's already that. Keeping data forever just because isn't necessarily inherently better. At $formeremployer, we had a policy of not keeping anything longer than a year unless mandated to for regulatory reasons. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: thinking journal retention timelimits
Matthew Miller wrote: > Right now, we don't set MaxRetentionSec, so journal expiry on Workstation > is entirely based on disk usage. > > Logs can accidentally contain sensitive data, and it's just plain faster > to work with them when there's less. I propose we set this to something > like six months by default. I don't think we should be destroying data by default. There should be no expiry by default. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: can't install package pipewire-jack-audio-connection-kit
On Fri, Jan 1, 2021 at 8:02 PM Michael Schwendt wrote: > > On Fri, 1 Jan 2021 06:58:43 -0500, Neal Gompa wrote: > > > > Explicit "Conflicts" here, at least, in > > > pipewire-jack-audio-connection-kit: > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970 > > > > > > Conflicts in distribution packages are bad, bad, bad and typically a dead > > > end when someone runs into them due to dependencies. > > > > PipeWire replaces libjack and the JACK daemon, so the Conflicts are correct. > > Replacing packages is done via "Obsoletes", so depsolving tools can do > the right thing automatically. As can be seen on above koji page, the > "Obsoletes" tag is empty. No. The pipewire subpackages don't *replace* the Jack and PulseAudio packages, they are an *alternative* implementation - which is why Conflicts are correct, and Obsoletes / Provides are not. When / If the pipewire implementations are to actually replace Jack and PulseAudio on all systems, using Obsoletes and Conflicts will be the appropriate thing to do. Until then, they will both be available for users to install. It's a bit more tricky to set up correctly in the packaging, but it actually lets users switch between the two (which would not work at all if one of them Obsoleted the other). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: can't install package pipewire-jack-audio-connection-kit
On Fri, 1 Jan 2021 10:26:13 -0500, Nico Kadel-Garcia wrote: > > Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit: > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970 > > > > Conflicts in distribution packages are bad, bad, bad and typically a dead > > end when someone runs into them due to dependencies. > > They're commonplace for packages that use the same binary or config file > names. > or when one package obsoletes another. This is happening right now > with "createrepo" and the renamed package "createrepo_c". createrepo_c has NEVER done that via conflicts! It has followed the packaging guidelines to replace the createrepo package via a pair of Obsoletes/Provides tags. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: can't install package pipewire-jack-audio-connection-kit
On Fri, 1 Jan 2021 06:58:43 -0500, Neal Gompa wrote: > > Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit: > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970 > > > > Conflicts in distribution packages are bad, bad, bad and typically a dead > > end when someone runs into them due to dependencies. > > PipeWire replaces libjack and the JACK daemon, so the Conflicts are correct. Replacing packages is done via "Obsoletes", so depsolving tools can do the right thing automatically. As can be seen on above koji page, the "Obsoletes" tag is empty. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
It's faster. Here is some benchmark with different zstd compression ratios https://lkml.org/lkml/2019/1/28/1930. Could be outdated a little bit though. But for HDD it makes sense to increase it probably. And IIRC Chris wrote about such plans. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to easily automate test builds in a COPR project
On Thu, 31 Dec 2020 at 14:59, Richard Shaw wrote:
>
> I maintain a suite of ham radio related packages. The developer is very
> active and often creates test versions adding and incrementing the "tweak"
> part of the version which is removed for the full releases and the patch
> level incremented.
>
> Currently I'm just trying to keep up with them by hand using pagure forks of
> the official repos so I don't accidentally pollute SCM with the changes and
> build them in COPR.
>
> Things I need to manage automagically:
> 1. Monitor the test URLs to look for new versions.
>
> I could write a bash script for this and add a cron or systemd timer but I
> was hoping for something that took less time as I don't have a lot of that :)
>
> Would it be permissible to create a -testing entry in
> release-monitoring.org?
>
>
> 2. Trigger a "fedpkg clone" and add a tweak version.
>
> This could probably be managed with macros easy enough, %{?tweak}, or
> something like that. And then use a script to substitute into "%global tweak
> ..."
>
>
> 3. I need to download the files from a different location.
>
> %if %{?tweak}
> ... use difference Source0?
>
>
> 4. Build the packages in COPR.
>
> Easy enough using a bash script but is there a better way?
There would be a very neat way if "Enable Spec File preprocessing"
change was accepted but it looks like it won't happen. There are still
some options but they require keeping a spec file (template) outside
of Fedora DistGit (which should normally be the source for the spec
file). Actually, also rpkg-3 would be needed in Copr (currently rpkg-2
is there). So with rpkg-3, you could:
- have the spec file template e.g. in Pagure
- configure rpkg SCM method by using https URL of the spec file in
pagure and clone url of upstream (this is a thing currently
unsupported by rpkg-2)
- either ask the upstream developer to configure a webhook for you to
trigger a build in COPR upon a new commit or tag or configure
release-monitoring for that
With the aforementioned Fedora change, you could have just a single
spec file in Fedora DistGit and use it for official Fedora builds as
well as for upstream builds. But without that change, it is not
possible so you would need to take rendered spec files from the
template and load them into DistGit with an upstream version that you
would like to release into Fedora. That breaks Fedora DisGit
canonicity but it's the best way and many people do it anyway.
You can actually implement this workflow even today without rpkg-3 in
COPR by using COPR's custom srpm build method. There you could specify
a snippet which installs rpkg-3 into the chroot and then invokes
`rpkg` command on the spec in the pagure (again specified as https
URL) while operating on the upstream cloned repo. Of course, you could
also avoid using rpkg-3 and do something more manual on your own
(e.g. invoking git archive and sedding your spec file with the
produced sourcename).
Well, I probably didn't help you much
Anyway, best regards
clime
>
> Thanks,
> Richard
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to easily automate test builds in a COPR project
On Thu, Dec 31, 2020 at 8:41 AM Till Maas wrote: > Hi, > > On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote: > > > 4. Build the packages in COPR. > > > > Easy enough using a bash script but is there a better way? > > packit allows to create test builds in COPR based on GitHub PRs and > probably also releases. Maybe this can make it easier for you, too: > https://packit.dev/ I only looked at it briefly but upstream does not use github so I'm not sure this would work. Thanks for the tip though. 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
thinking journal retention timelimits
As we start a new year, I'm thinking about data retention in general. :) In my experience, it's pretty rare on an end-user laptop or desktop system for logs from much more than the previous boot to be interesting. Maybe I occasionally want to look back a little while to see if a problem just started. It's exceedingly rare that I need (or want) to look back more than a month. Right now, we don't set MaxRetentionSec, so journal expiry on Workstation is entirely based on disk usage. Logs can accidentally contain sensitive data, and it's just plain faster to work with them when there's less. I propose we set this to something like six months by default. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Otto Urpelainen
On Fri, Jan 01, 2021 at 11:50:55AM -0500, Matthew Miller wrote: > > as such. Reading the documentation, contributing a whole new package > > is no the first thing I can do for Fedora, requiring a sponsor and > > so on, so I suppose I should start by contributing version updates > > for my applications' dependencies or such easier tasks. > > Yeah, that's definitely the easier way to get started. And, I should add, also very helpful to the project! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction: Otto Urpelainen
On Fri, Jan 01, 2021 at 10:46:29AM +0200, Otto Urpelainen wrote: > I am a Fedora user since 2013. I have also been following Fedora > development for some years, mostly by checking the Accepted Changes Hi Otto! Always great to see long-time Fedorans get more involved! > as such. Reading the documentation, contributing a whole new package > is no the first thing I can do for Fedora, requiring a sponsor and > so on, so I suppose I should start by contributing version updates > for my applications' dependencies or such easier tasks. Yeah, that's definitely the easier way to get started. -- 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
Fedora-Rawhide-20210101.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 11/180 (x86_64), 4/122 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201231.n.0): ID: 749312 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/749312 ID: 749313 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/749313 ID: 749326 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/749326 ID: 749357 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/749357 Old failures (same test failed in Fedora-Rawhide-20201231.n.0): ID: 749338 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/749338 ID: 749345 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/749345 ID: 749355 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/749355 ID: 749364 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/749364 ID: 749366 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/749366 ID: 749378 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/749378 ID: 749443 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/749443 ID: 749518 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/749518 ID: 749545 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/749545 ID: 749572 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/749572 ID: 749581 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/749581 Soft failed openQA tests: 21/180 (x86_64), 15/122 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20201231.n.0): ID: 749347 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/749347 ID: 749396 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/749396 ID: 749415 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/749415 Old soft failures (same test soft failed in Fedora-Rawhide-20201231.n.0): ID: 749284 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/749284 ID: 749285 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/749285 ID: 749292 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/749292 ID: 749296 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/749296 ID: 749300 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/749300 ID: 749301 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/749301 ID: 749314 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/749314 ID: 749323 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/749323 ID: 749343 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/749343 ID: 749386 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/749386 ID: 749395 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/749395 ID: 749404 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/749404 ID: 749421 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/749421 ID: 749435 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/749435 ID: 749439 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/749439 ID: 749462 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/749462 ID: 749463 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/749463 ID: 749478 Test: x86_64 universal
Fedora-IoT-34-20210101.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 3/16 (x86_64), 7/15 (aarch64) New failures (same test not failed in Fedora-IoT-34-20201231.0): ID: 749597 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/749597 ID: 749601 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/749601 ID: 749613 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/749613 ID: 749616 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/749616 Old failures (same test failed in Fedora-IoT-34-20201231.0): ID: 749593 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/749593 ID: 749602 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/749602 ID: 749604 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/749604 ID: 749605 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/749605 ID: 749607 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/749607 ID: 749611 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/749611 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20201231.0): ID: 749586 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/749586 Passed openQA tests: 12/16 (x86_64), 8/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.31 to 0.44 Previous test data: https://openqa.fedoraproject.org/tests/749242#downloads Current test data: https://openqa.fedoraproject.org/tests/749603#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
[Bug 1911914] New: perl-Future-0.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1911914 Bug ID: 1911914 Summary: perl-Future-0.47 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Future Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.47 Current version/release in rawhide: 0.46-1.fc34 URL: http://search.cpan.org/dist/Future/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/11795/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: can't install package pipewire-jack-audio-connection-kit
On Fri, Jan 1, 2021 at 10:29 AM Leigh Scott wrote: > > > On Fri, Jan 1, 2021 at 5:07 AM Michael Schwendt > wrote: > > > > PipeWire replaces libjack and the JACK daemon, so the Conflicts are correct. > > How? > > $ rpm -q --requires libavdevice |grep jack > libjack.so.0()(64bit) > > > $ dnf whatprovides 'libjack.so.0()(64bit)' > [sudo] password for leigh: > Last metadata expiration check: 2:31:36 ago on Fri 01 Jan 2021 12:54:04 GMT. > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 : The Jack Audio Connection Kit > Repo: @System > Matched from: > Provide: libjack.so.0()(64bit) > > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 : The Jack Audio Connection Kit > Repo: fedora > Matched from: > Provide: libjack.so.0()(64bit) > This is apparently only fixed in Fedora 34. On Fedora 33, there are still filtered Provides... The spec file really should just be synced from Rawhide to Fedora 33... 臘 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: can't install package pipewire-jack-audio-connection-kit
> On Fri, Jan 1, 2021 at 5:07 AM Michael Schwendt wrote: > > PipeWire replaces libjack and the JACK daemon, so the Conflicts are correct. How? $ rpm -q --requires libavdevice |grep jack libjack.so.0()(64bit) $ dnf whatprovides 'libjack.so.0()(64bit)' [sudo] password for leigh: Last metadata expiration check: 2:31:36 ago on Fri 01 Jan 2021 12:54:04 GMT. jack-audio-connection-kit-1.9.14-5.fc33.x86_64 : The Jack Audio Connection Kit Repo: @System Matched from: Provide: libjack.so.0()(64bit) jack-audio-connection-kit-1.9.14-5.fc33.x86_64 : The Jack Audio Connection Kit Repo: fedora Matched from: Provide: libjack.so.0()(64bit) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: can't install package pipewire-jack-audio-connection-kit
On Fri, Jan 1, 2021 at 5:07 AM Michael Schwendt wrote: > > On Thu, 31 Dec 2020 16:26:15 +0100, Matthias Runge wrote: > > > On 31/12/2020 16:10, Martin Gansser wrote: > > > this means that jack-audio-connection-kit has been replaced by > > > pipewire-jack-audio-connection-kit ? > > > > >- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 > > > conflicts with jack-audio-connection-kit provided by > > > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 > > > > > > This messes with i686 and x86_64? Usually that means, something else is > > broken. > > Personally, I'd try to get rid of the 32bit binary as quickly as > > possible. Either by rpm -e --nodeps && dnf install > > to get the 64 bit version instead of 32 bit. > > Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit: > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970 > > Conflicts in distribution packages are bad, bad, bad and typically a dead > end when someone runs into them due to dependencies. They're commonplace for packages that use the same binary or config file names. or when one package obsoletes another. This is happening right now with "createrepo" and the renamed package "createrepo_c". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
HEADS UP: Intent to update python-mysql to 2.0.3
Looks like we've missed a few releases... Current version in Fedora is 1.4.6. I also found reference to a 1 yo pull request to trytond[1] which appears to be abandoned. Affected packages are: $ dnf repoquery --repoid=rawhide --whatrequires "MySQL-python3" trytond-mysql-0:4.0.4-15.fc33.noarch $ dnf repoquery --repoid=rawhide --whatrequires "python3-mysql" dmlite-shell-0:1.14.2-1.fc34.x86_64 holland-mysql-0:1.2.2-1.fc34.noarch holland-xtrabackup-0:1.2.2-1.fc34.noarch python3-biopython-0:1.78-2.fc34.x86_64 python3-mysql-debug-0:1.4.6-5.fc34.x86_64 python3-sqlobject-0:3.3.0-13.fc33.noarch trytond-mysql-0:4.0.4-15.fc33.noarch While there is a major version bump looking at the changelog nothing drastic jumps out at me. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)
On Wed, 30 Dec 2020 at 19:53, Ben Cotton wrote: > ** Update anaconda to perform the installation using mount -o > compress=zstd:1 > Any reason behind compression level of 1 rather than the default of 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
Fedora rawhide compose report: 20210101.n.0 changes
OLD: Fedora-Rawhide-20201231.n.0 NEW: Fedora-Rawhide-20210101.n.0 = SUMMARY = Added images:68 Dropped images: 0 Added packages: 5 Dropped packages:4 Upgraded packages: 83 Downgraded packages: 0 Size of added packages: 2.09 MiB Size of dropped packages:96.56 MiB Size of upgraded packages: 1.05 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -1.48 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20210101.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20210101.n.0.iso Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20210101.n.0.iso Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20210101.n.0.iso Image: LXDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20210101.n.0-sda.raw.xz Image: KDE live x86_64 Path: Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20210101.n.0.iso Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20210101.n.0-sda.raw.xz Image: Server dvd armhfp Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-Rawhide-20210101.n.0.iso Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-Rawhide-20210101.n.0.aarch64.raw.xz Image: Server raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-Rawhide-20210101.n.0.armhfp.raw.xz Image: Server boot aarch64 Path: Server/aarch64/iso/Fedora-Server-netinst-aarch64-Rawhide-20210101.n.0.iso Image: Server boot x86_64 Path: Server/x86_64/iso/Fedora-Server-netinst-x86_64-Rawhide-20210101.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20210101.n.0.iso Image: Server boot armhfp Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-Rawhide-20210101.n.0.iso Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20210101.n.0.iso Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20210101.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20210101.n.0.iso Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20210101.n.0-sda.raw.xz Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20210101.n.0.x86_64.vagrant-virtualbox.box Image: Cloud_Base qcow2 aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20210101.n.0.aarch64.qcow2 Image: Cloud_Base qcow2 x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20210101.n.0.x86_64.qcow2 Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20210101.n.0.aarch64.tar.xz Image: Xfce_Appliance raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-armhfp-Rawhide-20210101.n.0-sda.raw.xz Image: Container_Minimal_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20210101.n.0.x86_64.tar.xz Image: Server dvd ppc64le Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20210101.n.0.iso Image: LXQt live x86_64 Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20210101.n.0.iso Image: Server boot ppc64le Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20210101.n.0.iso Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20210101.n.0.iso Image: Server_Appliance raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-armhfp-Rawhide-20210101.n.0-sda.raw.xz Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20210101.n.0.iso Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20210101.n.0.x86_64.vagrant-libvirt.box Image: Everything boot x86_64 Path: Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20210101.n.0.iso Image: Everything boot armhfp Path: Everything/armhfp/iso/Fedora-Everything-netinst-armhfp-Rawhide-20210101.n.0.iso Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20210101.n.0.x86_64.vagrant-virtualbox.box Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20210101.n.0.iso Image: Server dvd aarch64 Path: Server/aarch64/iso/Fedora-Server-dvd-aarch64-Rawhide-20210101.n.0.iso Image: Server dvd x86_64 Path: Server/x86_64/iso/Fedora-Server-dvd-x86_64-Rawhide-20210101.n.0.iso Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20210101.n.0.iso Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20210101.n.0.iso Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-Rawhide-20210101.n.0.aarch64.tar.xz Image: Container_Base docker x86_64
Re: can't install package pipewire-jack-audio-connection-kit
On Fri, Jan 1, 2021 at 5:07 AM Michael Schwendt wrote: > > On Thu, 31 Dec 2020 16:26:15 +0100, Matthias Runge wrote: > > > On 31/12/2020 16:10, Martin Gansser wrote: > > > this means that jack-audio-connection-kit has been replaced by > > > pipewire-jack-audio-connection-kit ? > > > > >- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 > > > conflicts with jack-audio-connection-kit provided by > > > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 > > > > > > This messes with i686 and x86_64? Usually that means, something else is > > broken. > > Personally, I'd try to get rid of the 32bit binary as quickly as > > possible. Either by rpm -e --nodeps && dnf install > > to get the 64 bit version instead of 32 bit. > > Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit: > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970 > > Conflicts in distribution packages are bad, bad, bad and typically a dead > end when someone runs into them due to dependencies. PipeWire replaces libjack and the JACK daemon, so the Conflicts are correct. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: can't install package pipewire-jack-audio-connection-kit
On Thu, 31 Dec 2020 16:26:15 +0100, Matthias Runge wrote: > On 31/12/2020 16:10, Martin Gansser wrote: > > this means that jack-audio-connection-kit has been replaced by > > pipewire-jack-audio-connection-kit ? > > >- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 > > conflicts with jack-audio-connection-kit provided by > > jack-audio-connection-kit-1.9.14-5.fc33.x86_64 > > > This messes with i686 and x86_64? Usually that means, something else is > broken. > Personally, I'd try to get rid of the 32bit binary as quickly as > possible. Either by rpm -e --nodeps && dnf install > to get the 64 bit version instead of 32 bit. Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit: https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970 Conflicts in distribution packages are bad, bad, bad and typically a dead end when someone runs into them due to dependencies. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Deprecate xemacs, xemacs-packages-base, xemacs-packages-extra, and neXtaw (Self-Contained Change proposal)
Jerry James writes: > On Thu, Dec 31, 2020 at 5:37 AM Zbigniew Jędrzejewski-Szmek > wrote: > > Normally, I'd be in favour of "dragging out" the removal a bit, but > > in this case I think we don't need to, because of the relatively > > close replacement and the small number of users. It's not a very close replacement. Mostly in favor of GNU Emacs, which has a large number of features (and regular maintenance) that XEmacs does not. I would expect that most Emacsen users have moved to Emacs for that reason. However, XEmacs has a number of unique features, most important being the ability to load .so libraries in an XEmacs-specific "module" format. Any C-level support for external libraries is likely to require a fair amount of work to port to Emacs, as XEmacs and Emacs internal implementations are fairly divergent. On the other hand, we never distributed any such things (we do distribute a few accelerator modules but as far as I know all of those implement features that GNU Emacs has natively), so most users will be folks who implemented them themselves and have the necessary skills to do ports to Emacs if they're still using them. I don't recall hearing of any that were widely distributed (eg, in a corporate environment). > I honestly have no idea how many users there are. I have gotten bug > reports from time to time over the years, but it is possible that the > number of users has shrunk down to near zero, in which case I might be > worrying for nothing. I don't know either, and apparently we lost the mailing list membership lists when Aidan took them over, so there's no easy way for us to ask. Bugs do occasionally get reported upstream, there are a few folks who did sign up again. But I don't know if any of the known users of XEmacs depend on Fedora. FYI. I'm sad to see XEmacs support removed from various distributions, but the logic is clear. Steve -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20210101.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20201231.0): ID: 749276 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/749276 ID: 749283 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/749283 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction: Otto Urpelainen
Greetings, I am a Fedora user since 2013. I have also been following Fedora development for some years, mostly by checking the Accepted Changes wiki pages, sometimes also by reading the mailing list discussions. Lately, I have discovered some useful applications that are not available in Fedora package repositories. Currently the list includes yle-dl and gnomecast. I would like to contribute to the project by packaging and maintaining them. Both happen to be Python applications, though I do not have any affiliation with the language as such. Reading the documentation, contributing a whole new package is no the first thing I can do for Fedora, requiring a sponsor and so on, so I suppose I should start by contributing version updates for my applications' dependencies or such easier tasks. Regards, Otto Urpelainen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
