devel November 2020

devel@lists.fedoraproject.org

244 participants
344 discussions

Fedora-Cloud-32-20201125.0 compose check report
by Fedora compose checker 25 Nov '20

25 Nov '20

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-20201124.0): ID: 728703 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/728703 ID: 728710 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/728710 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

Fedora-Cloud-33-20201125.0 compose check report
by Fedora compose checker 25 Nov '20

25 Nov '20

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-20201124.0): ID: 728689 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/728689 ID: 728696 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/728696 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose

1 0

SRPM's with OS dependent source files
by Nico Kadel-Garcia 24 Nov '20

24 Nov '20

I'm staring at the chromium SRPM, and seeing a problem that I've seen before with tools like SuSE's kernels. The .spec file only includes specific source files if the SRPM is built on specific operating systems, such as various .ttf files only bein in the RPM for: %if 0%{?rhel} == 7 And others only being available if the SRPM is built on Fedora. This means the SRPM's cannot simply be brought over to CentOS or RHEL 7 and compiled there because it doesn't have the .ttf files in the SRPM. And "spectool -g chromium.spec" doesn't work, because the git repos cited for the original .ttf files no longer have them. It effectively turns an SRPM with 99% of the source, including tarballs, into a "nosrc" SRPM. Is there a guideline that forbids this behavior? Picking and choosing what source files is a pernicious problem and breaks "mock" based or normal rpmbuild based recompilation, even for testing. I used to see this a lot with various SuSE kernel .spec files, and I do believe they stopped doing it. Nico Kadel-Garcia

3 3

Fedora 34 Change: Rename libusb packages and deprecated old API (Self-Contained Change)
by Ben Cotton 24 Nov '20

24 Nov '20

https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecate… == Summary == Rename `libusb` to `libusb-compat` and `libusbx` to `libusb1`. Do '''not''' provide an automated update path for the old `libusb` build dependency as packages should–and likely can–be updated to use `libusb1`. == Owner == * Name: [[User:benzea|Benjamin Berg]] * Email: bberg(a)redhat.com == Detailed Description == Currently we have two related packages: * libusb: Containing a compatibility layer of the 0.1 API for libusb 1.0 * libusbx: Containing the libusb 1.0 API, where the name "libusbx" derives from a fork that existed for a while To make it clear that "libusb" should not be used anymore and as "libusbx" does not exist anymore, it makes sense to rename the packages as follows: * libusb-compat * libusb1 In order to ensure that no package is depending on the old `libusb` (i.e. `libusb-compat`) without a good reason, the plan is to '''not''' add the corresponding `Provides:` line for the `libusb-compat-devel` rename. == Benefit to Fedora == * We adhere more closely to the upstream naming scheme for libusb. * We begin sunsetting `libusb-compat` (i.e. current `libusb`). == Scope == * Proposal owners: Create new `libusb-compat` and `libusb1` packages based on the current ones. * Other developers: Review any package that uses `BuildRequires: libusb-devel`. Many of them will be able to switch to `libusb1-devel` but some may still require the compatibility layer, i.e. `libusb-compat-devel`. * Release engineering: N/A * Policies and guidelines: N/A (not needed for this change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == No impact is expected. == How To Test == No further testing is needed. == User Experience == [not provided] == Dependencies == [not provided] == Contingency Plan == Add `Provides: libusb-devel` to `libusb-compat-devel` if too many packages are not updated. * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

4 7

Fedora 31 End Of Life
by Mohan Boddu 24 Nov '20

24 Nov '20

Hello all, Fedora 31 will go end of life for updates and support on 24th of November 2020. No further updates, including security updates, will be available for Fedora 31 after the said date. All the updates of Fedora 31 being pushed to stable will be stopped as well. Fedora 32 will continue to receive updates until approximately one month after the release of Fedora 34. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [0]. The fedora Project wiki also contains instructions [1] on how to upgrade from a previous release of Fedora to a version receiving updates. Regards, Mohan Boddu. [0]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Sche… [1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades

1 1

Fedora 34 Change: kasumi-unicode (Self-Contained Change)
by Ben Cotton 24 Nov '20

24 Nov '20

https://fedoraproject.org/wiki/Changes/kasumi_unicode == Summary == kasumi-unicode will be generated newly with kasumi.spec in [https://src.fedoraproject.org/rpms/kasumi kasumi] project. == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == [https://src.fedoraproject.org/rpms/anthy-unicode anthy-unicode] has been forked from [https://src.fedoraproject.org/rpms/anthy anthy] since anthy was no longer maintained in upstream. [https://src.fedoraproject.org/rpms/kasumi kasumi] is one of the applications which link to the libraries of anthy. In case kasumi links to anthy, the private dictionary is located in `$HOME/.anthy` directory. In case kasumi links to anthy-unicode, the private dictionary is located at `$XDG_CONFIG_HOME/anthy`. I wish kasumi links to anthy-unicode newly but some other applications still use anthy. E.g. ibus-anthy uses anthy-unicode and `$XDG_CONFIG_HOME/anthy`. fcitx-anthy, scim-anthy, uim-anthy, gcim-anthy uses anthy and `$HOME/.anthy`. To keep the back compatibility while *-anthy will migrate to use anthy-unicode, kasumi.spec is going to generate kasumi twice to generate two kasumi binaries with different CFLAGS and LDFLAGS between anthy and anthy-unicode. kasumi-unicode will be generated to link to anthy-unicode. anthy-unicode enhances anthy for: # internal data EUC-JP to UTF-8 # user dic in $HOME/.anthy to $XDG_CONFIG_HOME/anthy == Benefit to Fedora == anthy-unicode saves the user dictionaries in the Freedesktop configuration directory $XDG_CONFIG_HOME. Contributers can develop anthy-unicode with UTF-8 words internally. == Scope == * Proposal owners: * Other developers: [[AkiraTagoh]] (Fedora maintaier of kasumi) * Release engineering: N/A * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == ibus-anthy will depend on anthy-unicode and kasumi-unicode instead of kasumi. == How To Test == # Enable ibus-anthy in your desktop # Run /usr/libexec/ibus-setup-anthy # Run kasumi-unicode from "Dictionary" tab in the dialog # Register some words with kasumi-unicode The user dictionary is saved in $XDG_CONFIG_HOME/anthy and ibus-anthy can use it. == User Experience == Users will run `anthy-unicode-dic-tool --migrate` in case that users need to migrate the user dictionary in $HOME/.anthy with one in $XDG_CONFIG_HOME/anthy. == Dependencies == ibus-anthy == Contingency Plan == * Contingency mechanism: Revert the change of kasumi.spec and ibus-anthy will depends on kasumi. * Contingency deadline: Beta freeze * Blocks release? No * Blocks product? No -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 0

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Joël Krähemann 24 Nov '20

24 Nov '20

why not to allow pipes as sinks? Like "/dev/null". On Tue, Nov 24, 2020 at 8:29 PM Reindl Harald (privat) <harry(a)rhsoft.net> wrote: > > > > Am 24.11.20 um 20:26 schrieb Joël Krähemann: > > What I can do with my software `gsequencer` all on top of ALSA. > > gsequencer is on the same layer the PA/pipewire > case closed > > > * save or open Advanced Gtk+ Sequencer XML files with XPath support > > * add or remove audio engines with adjustable audio channels and pads > > * link channels with property dialog > > * output panel, mixer, drum and matrix sequencer, soft synth and audio > > file player > > * piano roll with basic notation editing supporting copy & paste > > * adjustable BPM > > * LADSPA, DSSI and Lv2 support > > * export to WAV, FLAC, OGG, MP3, MP4, MKV and WEBM > > * multiple sinks/sources like JACK, ALSA, OSSv4, Pulseaudio, WASAPI > > and Core-Audio > > * automation editor with automation control and hide them to bypass > > * waveform editor with one track per audio channel > > * MIDI instrument playback > > * Standard MIDI File import/export > > * envelope editor per step sequencer or instrument > > * OSC content format support and listening server using IPv4/IPv6 over UDP/TCP > > * AGS-OSC-OVER-XMLRPC with libsoup-2.4 builtin XML login module for > > basic HTTP authentication > > * tic based system default max sync-rate upto 1000 Hz > > > > On Tue, Nov 24, 2020 at 8:16 PM Reindl Harald (privat) <harry(a)rhsoft.net> wrote: > >> > >> > >> > >> Am 24.11.20 um 20:06 schrieb Joël Krähemann: > >>>> That being said, I have spoken to a few audio engineers, and basically > >>>> none of them use ALSA directly. They can't because ALSA doesn't > >>>> support mixing properly, among other things. Most of them use JACK or > >>>> PulseAudio, depending on their requirements. PipeWire is intended to > >>>> simplify the pro audio case while bringing those benefits to casual > >>>> audiophiles who use PulseAudio. > >>> > >>> I really doubt that you listen to youtube while creating music > >> > >> who is talking about YouTube? > > > > This was just an example if you want to mix something while doing > > audio production. > > > >> > >>> What do you want to mix? > >> > >> just hear different audio-sources at the same time? > >> > > > > In `gsequencer` you can even configure multiple sound cards for > > playback or capture. It actually works quite well. > > > >>> Might be for some exotic JACK setup > >> > >> what is exotic in the simple fact that one has running sound from > >> different sources no matter jackaudio or not? > >> > > > > Again, I am talking about producing things like songs or a screencast. > > > >> the problem with pure alsa is that typically *one* software claims the > >> audio device and that's it while in many workloads you just have running > >> more than one sioruce no matter if they are all muted except one or > >> really play at the same time > > > > You basically ignore my arguments on latency. > > > > Stop alienating me and mixing unrelated things ... > > > > This is your very own sight of things, you should broaden your > > spectrum. > > > > Further, you can mix it all in GSequencer in any way you want to. Like > > bundling different JACK sources. > > > > The low latency MIDI experience will burst your experience on top of > > ALSA.

1 0

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Joël Krähemann 24 Nov '20

24 Nov '20

Hi, What I can do with my software `gsequencer` all on top of ALSA. * save or open Advanced Gtk+ Sequencer XML files with XPath support * add or remove audio engines with adjustable audio channels and pads * link channels with property dialog * output panel, mixer, drum and matrix sequencer, soft synth and audio file player * piano roll with basic notation editing supporting copy & paste * adjustable BPM * LADSPA, DSSI and Lv2 support * export to WAV, FLAC, OGG, MP3, MP4, MKV and WEBM * multiple sinks/sources like JACK, ALSA, OSSv4, Pulseaudio, WASAPI and Core-Audio * automation editor with automation control and hide them to bypass * waveform editor with one track per audio channel * MIDI instrument playback * Standard MIDI File import/export * envelope editor per step sequencer or instrument * OSC content format support and listening server using IPv4/IPv6 over UDP/TCP * AGS-OSC-OVER-XMLRPC with libsoup-2.4 builtin XML login module for basic HTTP authentication * tic based system default max sync-rate upto 1000 Hz On Tue, Nov 24, 2020 at 8:16 PM Reindl Harald (privat) <harry(a)rhsoft.net> wrote: > > > > Am 24.11.20 um 20:06 schrieb Joël Krähemann: > >> That being said, I have spoken to a few audio engineers, and basically > >> none of them use ALSA directly. They can't because ALSA doesn't > >> support mixing properly, among other things. Most of them use JACK or > >> PulseAudio, depending on their requirements. PipeWire is intended to > >> simplify the pro audio case while bringing those benefits to casual > >> audiophiles who use PulseAudio. > > > > I really doubt that you listen to youtube while creating music > > who is talking about YouTube? This was just an example if you want to mix something while doing audio production. > > > What do you want to mix? > > just hear different audio-sources at the same time? > In `gsequencer` you can even configure multiple sound cards for playback or capture. It actually works quite well. > > Might be for some exotic JACK setup > > what is exotic in the simple fact that one has running sound from > different sources no matter jackaudio or not? > Again, I am talking about producing things like songs or a screencast. > the problem with pure alsa is that typically *one* software claims the > audio device and that's it while in many workloads you just have running > more than one sioruce no matter if they are all muted except one or > really play at the same time You basically ignore my arguments on latency. Stop alienating me and mixing unrelated things ... This is your very own sight of things, you should broaden your spectrum. Further, you can mix it all in GSequencer in any way you want to. Like bundling different JACK sources. The low latency MIDI experience will burst your experience on top of ALSA. cheers, Joël

1 0

Bliss soname bump
by Jerry James 24 Nov '20

24 Nov '20

Bliss upstream has been inactive for awhile; the last release was over 5 years ago. The sagemath developers have created a fork of bliss and have been fixing bugs. I intend to switch the Fedora package over to this new upstream soon. This entails an soname bump. I will rebuild all dependent packages: - sagemath - sympol -- Jerry James http://www.jamezone.org/

1 0

Cryptominisat soname bump
by Jerry James 24 Nov '20

24 Nov '20

I will soon build cryptominisat 5.8.0 in Rawhide. This version comes with an soname bump. I maintain or comaintain all dependent packages and will take care of rebuilding them: - cvc4 - stp - yices -- Jerry James http://www.jamezone.org/

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
35
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2020