SRPM's with OS dependent source files
by Nico Kadel-Garcia
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 years, 6 months
Fedora 34 Change: Rename libusb packages and deprecated old API
(Self-Contained Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_depreca...
== 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
3 years, 6 months
Fedora 34 Change: kasumi-unicode (Self-Contained Change)
by Ben Cotton
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
3 years, 6 months
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Joël Krähemann
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.
3 years, 6 months
Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Joël Krähemann
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
3 years, 6 months
Bliss soname bump
by Jerry James
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/
3 years, 6 months
Cryptominisat soname bump
by Jerry James
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/
3 years, 6 months
