Re: Stepping down as Fedora Jam maintainer

[Erich Eickmeyer]

On Monday, April 12, 2021 7:52:24 AM PDT Matthew Miller wrote:
> On Sun, Apr 11, 2021 at 11:38:40PM -, JT Pennington wrote:
> 
> > I'd like to volunteer to pick up the Fedora Jam project and maintain it.
> 
> 
> Awesome -- thanks JT!
> 
> -- 
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List
> Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

Thanks for stepping-up, JT!

JT is someone I'm very familiar with, as we have even shared a hotel room at 
Linux Fest Northwest back in 2014. If there's anybody who has capable hands 
about handling a spin/lab, it's him.

I've gone-ahead and handed-over the two Fedora Jam pagure repos to him, and 
I'm sure he'll be able to take-on the rest in due time.

I'll be sticking around as a resource to help in whatever way I can, and I'm 
even keeping some packages so that I can stay familiar with RPM packaging.

Thanks for doing this, JT! Let me know if you need anything.

Erich

signature.asc
Description: This is a digitally signed message part.
___
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

Stepping down as Fedora Jam maintainer

[Erich Eickmeyer]

Hello all,

A little over a year ago, I came to the Fedora project to revive and 
modernize the Fedora Jam project. I have successfully done that. My 
vision was that it would be a great way to help develop and test the 
most recent advancements in Linux audio.


Unfortunately, or fortunately, life has a way of changing for the good 
or the bad. Back in November, I was offered an opportunity that I could 
not pass-up: becoming the User Experience Director for the Kubuntu 
Focus brand of laptops made by MindShareManagement. Since then, I have 
become an integral member of that team, directly reporting to the CTO, 
CEO, and President, working directly with the PR and Sales and 
Marketing directors. It has been a blast, and is a project that works 
directly with Ubuntu and Debian to create, as we put it, the "Ultimate 
Linux Laptop". As a MOTU for Ubuntu, this was a perfect fit.


I didn't come here to be a shill for Ubuntu or to advertise my work, 
but rather, to illustrate the level of involvement. It has taken up a 
majority of my time, and my work with Ubuntu Studio is directly 
involved with the project as well as both Ubuntu Studio and the Kubuntu 
Focus laptop have similar synergies.


Because of the amount of time involved in these projects, something has 
to give. For that reason, I must step-down as Fedora Jam maintainer. My 
plan is to continue to maintain certain packages within Fedora (which, 
admittedly, I've been slacking on), but I am orphaning the vast 
majority of my packages. Here's the list:


Add64
dssi
dssi-vst
fedora-jam-backgrounds*
fedora-jam-kde-theme*
fluidsynth
fluidsynth-dssi
freqtweak
gnome-guitar
harmony-seq
hexter-dssi
jackctlmmc
jmeters
libinstpatch
lv2-c++-tools
lv2-fabla
lv2-ll-plugins
lv2-mdaEPiano
lv2-newtonator
lv2-sorcer
lv2-swh-plugins
lv2-vocoder-plugins
meterbridge
non-daw
portmidi
radium-compressor
realTimeConfigQuickScan
whysynth-dssi
xsynth-dssi

*These packages have pagure repos which I'd be happy to hand over to 
whoever takes these.


I do want to thank everyone for the opportunity, including Matthew 
Miller, Ben Cotton, Neal Gompa, and many others that helped me revive 
this project. I'm sad to let it go, and I'm not sure what's going to 
happen to it, but I hope someone who has a passion for the latest 
technologies in Linux Audio and music production can take it over.


Thanks,
Erich Eickmeyer

___
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: Needing Some Maintenance Help

[Erich Eickmeyer]

Hi Guido,

On Thu, 2021-01-14 at 20:38 +0100, Guido Aulisi wrote:
> I'm involved in audio/music packaging too, and I have some experience
> with lv2 plugins, so I can comaintain your lv2 packages.
> I don't know dssi enough, so I can't maintain dssi packages.
> I can also help maintain jmeters, meterbridge and soundtracker.
> 
> My FAS account is tartina
> 

I added you to everything beginning with lv2, jmeters, and meterbridge. It 
turns out
I'm not the main for Soundtracker, so I listed that one by mistake.

As for dssi, it's pretty much dead as the upstream hasn't seen development in 
years. The package is pretty much in maintenance mode at this point and will 
likely get retired at the first signn of a FTBFS, which luckily for people that 
use dssi, hasn't happened yet. 
 
--
Erich Eickmeyer
Project LeaderUbuntu Studio
Council MemberUbuntu Community Council
MaintainerFedora Jam
___
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

Needing Some Maintenance Help

[Erich Eickmeyer]

Hi All,

Over the course of the past few months, I have become employed by a
company to provide their user software experience. This has limited the
time that I have, and, unfortunately, my involvement in Fedora has, and
needs to, decrease.

I currently maintain the Fedora Jam lab, and would like some help with
that. Just last night, while I was trying to relax after my day, I was
CC'd on two bug reports only because I'm Jam's maintainer, when really
the responsibility for the issues in question (pipewire related in
Rawhide) lie on the change owner(s) for the Pipewire-By-Default change.

I fixed a couple of packages only as a courtesy that were related to
the issue (unable to install the @audio group), but that responsibility
lies with the change owner(s), of which I'm not a part due to time
restrictions. I removed myself from the bug report after that and had
explained that they needed to add the change owner(s).

This same person that CC'd me on that decided to then file a bug report
against Jam 34 which is currently FTBFS due to the aforementioned issue
with the @audio group. Since we (spin/lab maintainers) get automated
emails about these things, I told them not to file bug reports against
spins/labs in the future and closed it as errata. I realize this person
was only trying to help, but it caused me some undo stress.

This made me realize that I need to take a step back. Not only have I
gained employment with a company that is using Ubuntu as their base
(specifically Kubuntu with Ubuntu Studio partnership), but I've also
become a MOTU with Ubuntu ("Master Of The Universe [repository]", much
like a proven packager here). As such, Fedora isn't exactly integral to
what I do, but I'd like to keep my rpm packaging skills somewhat
sharpened, which is why I'll be keeping certain packages that I have
direct involvement upstream with (e.g. studio-controls).

So, here's what I'm looking for:

* Someone to help me maintain Jam
  * Including fedora-jam-backgrounds and fedora-jam-kde-theme packages

* Co-maintainers and/or new maintainers for the following packages:

* Add64
* dssi
* dssi-vst
* fluidsynth
* fluidsynth-dssi
* freqtweak
* giada
* gnome-guitar
* harmonyseq
* hexter-dssi
* jackctlmmc
* jmeters
* libinstpatch
* lv2-c++-tools
* lv2-fabla
* lv2-ll-plugins
* lv2-mdaEPiano
* lv2-newtonator
* lv2-sorcer
* lv2-swh-plugins
* lv2-vocoder-plugins
* meterbridge
* python-alsaaudio
* python-jack-client
* radium-compressor
* realTimeConfigQuickScan
* soundtracker
* whysynth-dssi
* xsynth-dssi

Simply let me know which package you'd like and if you'd like to
maintain or co-maintain along with your fas username. 

Thanks in advance,
Erich

--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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: Should we retire ardour5 in rawhide?

[Erich Eickmeyer]

On 12/22/20 1:55 AM, Guido Aulisi wrote:

Hi,
ardour5 fails to build in rawhide and it has been obsoleted by ardour6.

Should we retire it in rawhide?

Nils, if you can give me commit access to ardour6 I can help build the
new version as they are released.

My FAS account: tartina

Thanks

Ciao
Guido


Yes, Guido, I completely agree that ardour5 should be retired in rawhide 
for the reasons you mentioned.


--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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: Route all Audio to PipeWire (System-Wide Change)

[Erich Eickmeyer]

On 12/5/20 12:39 PM, Naheem Zaffar wrote:


I understand the need for replacing pulseaudio package when upgrading, 
but it should be possible to have both installed and have the service 
from only one activated? Atleast for current fedora that will make it 
easier to test and switch between implementations.


The point is you don't want/shouldn't have both pipewire and pulseaudio 
installed simultaneously since pipewire-pulseaudio is a drop-in replacement.


So no, that would be a bad idea.

--
Erich Eickmeyer
Maintainer
Fedora Jam

___
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: video meeting to discuss Matrix/Element and IRC

[Erich Eickmeyer]

On 11/27/20 5:49 PM, Kevin Kofler via devel wrote:

As I understand it, the Matrix-IRC bridge is "bidirectional" in the sense
that it relays messages both ways, but not in the sense that an IRC user
would be able to connect to an arbitrary Matrix channel with an IRC client
the way it allows a Matrix user to connect to an arbitrary IRC channel with
a Matrix client.

Nope. Each individual Matrix user shows up as an individual IRC user. :)

--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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: video meeting to discuss Matrix/Element and IRC

[Erich Eickmeyer]

On 11/27/20 4:53 AM, Kevin Kofler via devel wrote:

Considering that Matrix can bridge to IRC channels and not the opposite, I
also think that moving to native Matrix mainly just degrades
interoperatibility.

False. The bridges are bidirectional.

--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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: Route all Audio to PipeWire (System-Wide Change)

[Erich Eickmeyer]

On 11/22/20 10:26 AM, James Szinger wrote:

2. No native management tools.  The change proposal says to test the
usual pulseaudio and JACK tools (patcl, pavucontrol, catia, carla,
qjackctl), but does not mention any native tools.  This is a problem
because the PA and JACK tools will manage different subsets of
pipewire, potentially causing much confusion and wailing.

Actually, it's completely transparent between PulseAudio and JACK tools: 
they see each other the way they normally would. In fact, the JACK tools 
can see each individual PulseAudio application as a separate JACK 
client, which eliminates the need for a PulseAudio-JACK bridge.


--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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: Route all Audio to PipeWire (System-Wide Change)

[Erich Eickmeyer]

On 11/20/20 8:36 AM, Vitaly Zaitsev via devel wrote:
IMO, too early. PipeWire is too unstable yet. I suggest postpone this 
proposal to Fedora 35.


The person who wrote the change proposal is the lead developer of 
Pipewire. He believes it is stable enough (or will be) by the time F34 
branches. And to be honest, it won't get enough testing without being 
*at least* submitted to Rawhide.


With my Fedora Jam hat on (read: professional audio), I believe it's the 
right move. It's stable *enough* and needs to be tested by the public. 
If it's still too unstable, then there's a contingency plan. BUT, if we 
don't move forward *now* we'll wait another decade, and be in the same 
situation that Wayland is in.


The time to move forward is *now*. If we keep being scared, we'll never 
get anywhere.


--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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: video meeting to discuss Matrix/Element and IRC

[Erich Eickmeyer]

On 11/19/20 12:32 PM, Dominik 'Rathann' Mierzejewski wrote:

I don't know how Matrix works exactly...

Then I suggest educating yourself. Go to element.io and check it out.

If you don't know what it is or how it works, then why chime-in? That 
adds nothing to the conversation if you don't know what you're talking 
about.


--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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: RPM review: jack-mixer

[Erich Eickmeyer]

Hi Yann,

On 10/11/2020 10:11 AM, Yann Collette wrote:
> Hello
>
> I see that you have a "Requires: jack-audio-connection-kit".
>
> I feel because of this, your package will not work with pipewire-jack.
>
> Am I wrong ?
>
> Best regards,
>
> Yann
>
That is 100% incorrect. In fact, pipewire-jack has a "Provides:
jack-audio-connection-kit" line just to deal with this since it's a
drop-in replacement. Unfortunately, it's not being honored by packages
building with jack and relying on Autorequires to deal with the
dependencies.

The problem we're having with packages that don't include the "Requires:
jack-audio-connection-kit" line currently and are depending on
Autorequires to complete that for them is that they're explicitly
requiring the libjack.so.0 file and not the package, which doesn't exist
for pipewire-jack. By being explicit with the Requires, that takes care
of that problem.

In fact, I'm going to be filing bug reports against all applications
that have a "BuildRequires: jack-audio-connection-kit-devel" and tell
them that they need to explicitly require it in order for pipewire-jack
to transition. If this is going to require a change proposal, then so be it.

Thanks,
Erich

-- 
Erich Eickmeyer
Maintainer
Fedora Jam

___
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

RPM review: jack-mixer

[Erich Eickmeyer]

Hi all,

I've brought-over another package from Ubuntu, this time it's Jack
Mixer. This is an excellent program that provides a simple mixer that
works with MIDI and allows for plugins to be patched-in using Carla.
This is a great alternative to having a full-fledged DAW running while
trying to do live audio, as would be my use case.

Either way, here's the BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1887091

Would really appreciate a review on this, and would even do a review
swap if your package is simple enough for my little brain. :)

Best regards,
Erich

-- 
Erich Eickmeyer
Maintainer
Fedora Jam

___
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: F34 Change proposal: DNS Over TLS (System-Wide Change)

[Erich Eickmeyer]

On 10/8/20 2:24 PM, Björn Persson wrote:

Michael Catanzaro wrote:

On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters  wrote:

I agree for two reasons. One, the FESCO decision to postpone making
systemd-resolvd the default resolver. I would like to ensure this
change happens properly and securely for f34.

Well it's too late, since we are now in final freeze. FESCo reaffirmed
the systemd-resolved change just last week, so it's clearly not going
to be postponed. I agree that this DNSSEC problem with systemd-resolved
is unfortunate, and I'm sure the systemd developers would appreciate
help fixing it. Anyway, the best time to deal with this would have been
six months ago, when the change was proposed

The DNSsec problem was brought up by Florian Weimer and Tom Hughes six
months ago, when the change was proposed. Fesco or the change owners
could have chosen to "deal with" the problem then, if they cared about
DNSsec. You Michael replied to Florian and called DNSsec-aware clients
"a quite specialized use-case", so you can't claim that you were unaware
of the issue. "It's too late" rings hollow coming from someone who had
the chance to do something when it wasn't too late.

Björn Persson


Or how about we stick to the Friends Foundation and not make it personal?

--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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 32/33 livedisks do not boot on M$ system(s)

[Erich Eickmeyer]

On 9/30/2020 8:17 AM, Chris Murphy wrote:
> On Wed, Sep 30, 2020 at 2:05 AM Marius Schwarz  wrote:
>> Hi,
>>
>> the livecds from F32 and F33 are suffering from a problem not booting on
>> Microsoft device(s)
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1879921
>> https://bugzilla.redhat.com/show_bug.cgi?id=1883593
>>
>> F31 is booting fine, the newer ones not. Looks like a GrubBootloader
>> issue to me, as not even grub comes up.
> That suggests the scary region of firmware, hybrid ISO, shim, and boot loader.
>
> The bug reports have the wrong component set on them, and aren't
> discrete actionable bug reports. It's just saying "this doesn't work"
> but the people most likely to figure out what *is* happening are those
> with this specific hardware.
>
>> An instant reset back into the bios happens if a usb boot is tried.
> Sounds like both a regression and a firmware bug. Maybe we'll be lucky
> and someone on the list has an idea already. But if not, someone with
> the hardware will have to do the tedious work of figuring out exactly
> where it's getting tripped up.
>
>
>> Unfortunatly the assignee is not reacting and i would really miss my
>> linux surface after upgrading to F32 :D
> I have no idea what the LiveCD component is, but the bug report
> contains so little information I also don't know what I'd reassign it
> to. Asking about it on devel is probably the right thing to do for
> now.

I can confirm this bug does exist. Attempting to boot on my Surface Pro
4 requires secure boot to be momentarily shut-off. SB actually is
reporting a secure boot violation for whatever reason. I have reason to
believe that the UEFI files are missing correct signing, or that signing
needs to be updated.

I have also seen SB failures with my Dell laptop with SB enabled, but
those are easier to work around than going nuclear on a Surface Pro and
shutting-off secure boot.

F31 and F32 are unaffected, this appears to have started with F33.

-- 
Erich Eickmeyer
Project Leader Ubuntu Studio
Maintainer Fedora Jam



pEpkey.asc
Description: application/pgp-keys
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Erich Eickmeyer]

This entire discussion is generating enough emails per hour to be an IRC
discussion. Could we please move this discussion to #fedora-devel or
someplace more appropriate?

-- 
Erich Eickmeyer
Maintainer
Fedora Jam

___
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: Please update Darktable to latest stable on Fedora 33

[Erich Eickmeyer]

On Thursday, September 24, 2020 11:15:36 PM PDT Johannes Lips wrote:
> In defense of the maintainers, these build dates are right around f33
> branching on August 11th, so perhaps that is the reason, why they've missed
> f33.
 
Which is precisely why I said:

On Thu, 2020-09-24 at 14:41 -0700, Erich Eickmeyer wrote:
>
> Looks to me like whoever did the build forgot to do the bohdi update
> for 33, probably because it had branched just prior to that update.
>

:)

--
Erich Eickmeyer
Fedora Jam Maintainer

signature.asc
Description: This is a digitally signed message part.
___
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: Please update Darktable to latest stable on Fedora 33

[Erich Eickmeyer]

On Thursday, September 24, 2020 11:39:51 PM PDT Luya Tshimbalanga wrote:
> I initially planned to file a bug report but it was already
> automatically done on
> https://bugzilla.redhat.com/show_bug.cgi?id=1863394 and
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED
> lassification=Fedora=darktable_id=11382514=Fedora
> duct=Fedora%20EPEL
> 
> Rather than duplicating the ticket, asking a question for updates on the
> mailing list seems quicker. Maybe some proven packagers can land their
> hands addressing the bugs.

Ok, that's 100% fair. Hopefully it's not a situation where we have a non-
responsive maintainer, in which case, it might be worth invoking that 
procedure.

--
Erich Eickmeyer
Fedora Jam Maintainer



signature.asc
Description: This is a digitally signed message part.
___
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: Please update Darktable to latest stable on Fedora 33

[Erich Eickmeyer]

On Thu, Sep 24, 2020 at 4:02 pm, Michel Alexandre Salim 
 wrote:

On Thu, 2020-09-24 at 14:41 -0700, Erich Eickmeyer wrote:



 On Thu, Sep 24, 2020 at 2:39 pm, Luya Tshimbalanga <
 l...@fedoraproject.org <mailto:l...@fedoraproject.org>> wrote:
 >
 > When upgrading from Fedora 32 to 33 beta, I notice Darktable is on
 > 3.0. 3.2.1-1.fc32. Will it be possible to push to the latest
 > version before Fedora 33 release?
 >

 Looks to me like whoever did the build forgot to do the bohdi update
 for 33, probably because it had branched just prior to that update.


Do we no longer do N-V-R checks when higher releases have older
packages than older releases?




I don't know what that means, but I almost always do my initial 
building in rawhide followed by builds and updates to all currently 
supported Fedora releases.


A cursory glance at https://src.fedoraproject.org/rpms/darktable shows 
that F32 and F31 indeed have a newer version of Darktable than F33. F33 
doesn't even have a build currently in testing, so I find this to be 
highly problematic that builds aren't getting pushed to F33.


This type of question really needs to be a bug report against the 
darktable package, not a conversation in this list. Looks like @madko 
is listed as the maintainer and @germano was the last person to build 
push an update, but neglected F33. Such oversight does not seem very 
good.


--
Erich Eickmeyer
Fedora Jam 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

Re: Please update Darktable to latest stable on Fedora 33

[Erich Eickmeyer]

On Thu, Sep 24, 2020 at 2:39 pm, Luya Tshimbalanga 
 wrote:
When upgrading from Fedora 32 to 33 beta, I notice Darktable is on 
3.0. 3.2.1-1.fc32 
<https://koji.fedoraproject.org/koji/buildinfo?buildID=1587996>. Will 
it be possible to push to the latest version before Fedora 33 release?


Thanks

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer


Looks to me like whoever did the build forgot to do the bohdi update 
for 33, probably because it had branched just prior to that update.


--
Erich Eickmeyer
Fedora Jam 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

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Erich Eickmeyer]

Hi all

On Tue, Sep 8, 2020 at 08:56, Erich Eickmeyer 
 wrote:

Hi Ben,

On 9/8/2020 8:28 AM, Ben Cotton wrote:
 <https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma>

<https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma>

== Summary ==
Change the default session selection in SDDM to prefer the
Wayland-based KDE Plasma Desktop session over the X11-based one.

== Owner ==
* Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
[[User:Jgrulich|Jan Grulich]]
* Email: ngomp...@gmail.com <mailto:ngomp...@gmail.com>, 
rdie...@gmail.com <mailto:rdie...@gmail.com>, jgrul...@redhat.com 
<mailto:jgrul...@redhat.com>

* Product: KDE Spin
* Responsible WG: KDE SIG


== Detailed Description ==

With KDE Plasma 5.20, the KDE Plasma desktop environment has reached 
a

point where nearly all commonly used features in the desktop and all
major applications function in the Plasma Wayland environment on all
major GPUs (including NVIDIA with the proprietary driver). Starting
with Plasma 5.20 in Fedora 34, we will change the default
configuration for Wayland and X11 Plasma sessions so that Wayland is
preferred and used by default, while permitting the X11 session to be
selected as the alternative desktop environment option.

== Feedback ==

 Is Wayland ready? 
Wayland has been used by default for Fedora Workstation (which uses
GNOME) since Fedora 25. And while it was somewhat immature initially,
today it is a very rock-solid experience on virtually everything
Fedora Workstation runs on. The change in Fedora 25 kickstarted the
drive to get everything working on Wayland, and the Workstation team
succeeded beyond their wildest dreams. Firefox has been 
Wayland-native

by default since Fedora 31 as well.

On the KDE side, serious work into supporting Wayland started shortly
after GNOME switched to Wayland by default. Unlike GNOME, KDE has a
much broader stack in its toolkit, and it has taken longer to get to 
a

usable state. With the Plasma 5.20 release, the Wayland protocol for
screencasting as well as middle-click paste finally are supported,
completing the required feature set for switching to Wayland by
default.

 What about NVIDIA? 
Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary
driver on Wayland. It needs to be manually activated, which will be
taken care of by the kwin-wayland-nvidia package. So the
expectation is that all major GPUs will work just fine.

 Why not keep using X11? 
The fact of the matter is, Xorg is in
[<https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/>
"hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and
development on it has basically stopped beyond the most critical of
fixes. Combined with the rapid maturation of the Wayland session in
KDE Plasma, this is the best time to make the switch and push things
over the edge for the KDE ecosystem in the same way that Fedora
Workstation did for the GNOME ecosystem.

== Benefit to Fedora ==
Fedora has long been a leader in advancing the adoption of the 
Wayland

protocol as part of the overall strategy to improve the Linux
graphical software stack. Much of the quality of Wayland for GNOME 
can
be attributed to the work done by the Fedora Workstation WG as part 
of

advancing the GNOME platform. It is now the KDE SIG's turn to do the
same for the KDE platform. By making this change, we are helping push
the adoption forward for newer, more streamlined, and overall more
actively developed graphics technology for the KDE ecosystem.

== Scope ==
* Proposal owners:
** Modify {{package|kwin}} to switch to Wayland
*** Split out /usr/bin/kwin_x11 to the
kwin-x11 subpackage.
*** Make {{package|kwin}} require kwin-wayland and
recommend kwin-x11
*** Add kwin-wayland-nvidia subpackage which contains
/usr/lib/environment.d/10-kwin-wayland-nvidia.conf to 
set
$KWIN_DRM_USE_EGL_STREAMS to 1. This 
package

will have have a Supplements dependency (kwin-wayland and
kmod-nvidia).
** Modify {{package|plasma-workspace}} to switch to Wayland
*** Rename /usr/share/xsessions/plasma.desktop to
/usr/share/xsessions/plasma-xorg.desktop, subpackage it
out as plasma-workspace-xorg, and have it require
kwin-x11
*** Rename 
/usr/share/wayland-sessions/plasmawayland.desktop

to /usr/share/wayland-sessions/plasma.desktop
*** Make {{package|plasma-workspace}} require
plasma-workspace-wayland and recommend
plasma-workspace-xorg
** Modify @kde-desktop comps group for Fedora 34 to
include plasma-workspace-xorg for the media.

* Other developers: N/A (not applicable for this Change)
* Release engineering: [<https://pagure.io/releng/issue/9741> #9741]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not applicable for this Change)

== Upgrade/compatibility impact ==
Systems using certain (very old) graphics hardware or graphi

Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Erich Eickmeyer]

onfiguring
displays, etc. Things should work the same way under Wayland as they
used to under X.

== User Experience ==
The user experience should not change noticeably.

== Dependencies ==
This mainly affects the {{package|plasma-workspace}} and
{{package|kwin}} packages, and details for the changes for those
packages are described in the Scope section.

== Contingency Plan ==
* Contingency mechanism: Revert the file renames and switch
plasma-workspace-xorg to be the required package instead
of plasma-workspace-wayland
* Contingency deadline: beta freeze
* Blocks release? Yes
* Blocks product? KDE Spin

== Documentation ==
Some upstream documents about Wayland
* https://community.kde.org/Plasma/Wayland
* https://community.kde.org/KWin/Wayland

There is currently no coherent up to date documentation about Plasma Wayland.

== Release Notes ==
The KDE Plasma Desktop is using the Wayland display system now. X
applications will continue to run transparently through XWayland.


Since Fedora Jam directly depends on the Fedora KDE Spin kickstart and 
carries most of its defaults, I wish someone would've talked to me about 
this before this became a full-fledged change proposal and officially 
posted. For the btrfs-by-default change, Neal was gracious enough to 
reach out to me and ask if I thought it would benefit Jam. As I agreed, 
he put my name on the list of change owners and now btrfs is the 
default. In this case, I have not been given the same amount of courtesy.


I have done some (albiet limited) testing of Wayland, and from my tests, 
aside from some potential theming issues where the theme is not 
supporting Wayland (really Ubuntu Studio's default theme, but that isn't 
in use here), it seems to be mostly solid. Even the High DPI scaling 
does a better job on Wayland.


I see no real issues with this, and would've otherwise agreed to this 
and been one of the change owners if one had simply asked me, but right 
now I'm feeling a bit of tepidness since this change directly affects 
Fedora Jam and I was not asked prior to it becoming an official change 
proposal. Perhaps there were reasons for that, but I don't know why that 
wouldn't be considered. Perhaps the thought process was that the change 
to the display compositor wouldn't affect audio, but the reality is that 
anything that even potentially affects CPU/GPU usage affects lowlatency 
and realtime audio performance and recording since the kernel can and 
sometimes does take time away from audio to do video-related processes.


So with that, I'm really on the fence on this one. I guess I need more 
time to test. But, again, I wish somebody would've asked me first.


--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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 Jam 33 Beta - Possible Blocker?

[Erich Eickmeyer]

HI all,

On Wed, Sep 2, 2020 at 2:36 pm, Matthew Miller 
 wrote:

On Wed, Sep 02, 2020 at 02:25:25PM -0400, Neal Gompa wrote:
 There's a FBR (freeze break request) to patch all the builders to 
fix

 this problem[1], but I don't know if it has been applied yet.

 [1]: 



Ah, yeah, looks like it has been. And I see a Jam image built. So 
hopefully

this is good to go?



So far as I can tell, this has indeed been sorted. Thanks to everyone 
involved!


Erich

___
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 Jam 33 Beta - Possible Blocker?

[Erich Eickmeyer]

Hi Adam,

On 8/27/20 2:18 PM, Adam Williamson wrote:

Unfortunately, as Jam isn't a release-blocking image, it can't by
definition block the Beta release. Even if it doesn't build at all.

As Neal suggested, I'd recommend requesting the fix be backported to
our Koji by filing a ticket with the infra team.


Already done. [1]

This is just very disappointing [3]. Unless there is a huge delay in the 
beta timeline due to *actual* blockers, we've got no beta to test since 
this is 1-2 weeks out due to further testing needed [2]. So, unless this 
minor Koji release gets expedited, I've done a ton of hard work and 
nothing to show for it.


[1] https://pagure.io/fedora-infrastructure/issue/9271
[2] https://pagure.io/koji/issue/2437
[3] I just can't win, can I?

--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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 Jam 33 Beta - Possible Blocker?

[Erich Eickmeyer]

Hi Neal,

On 8/26/2020 7:43 PM, Neal Gompa wrote:

On Wed, Aug 26, 2020 at 10:08 PM Erich Eickmeyer
 wrote:

HI all,

Since the release of Koji 1.22, there has been a bug [1] blocking any
Fedora Jam 33 or Rawhide iso images from being spun. As you can imagine,
this is making me quite nervous. As it turns out, I'm waiting for Koji
1.22 to be released so that images can start building again. If this
isn't done in time for beta, then that means Fedora Jam will be unable
to participate in beta testing.


If you'd like this fix backported to Fedora's Koji instance ASAP, you
should file a ticket with the infrastructure team here:
https://pagure.io/fedora-infrastructure/issues

I did this for the Btrfs stuff a while back:
https://pagure.io/fedora-infrastructure/issue/9138


Ok, will do.


The issue in question is caused because Jam adds "threadirqs" as a boot
argument in addition to the normal boot arguments. This is a way to add
some low-latency characteristics to a kernel that isn't otherwise a
lowlatency kernel and is known to cut-down on xruns in audio production.

However, one question came up as to if threadirqs is a default in the
kernel configuration, but nobody could answer that. I was wondering if
anyone on this list knew?


threadirqs are not default in the Fedora kernel, as far as I recall.

Contrary to popular belief, CONFIG_IRQ_FORCED_THREADING=y does not
default to threaded IRQs. It only enables the ability to turn them on
by passing "threadirqs" as a kernel parameter. Yes, I know this is
stupid and makes no sense, but Kconfigs are not designed to make
sense...


BIG facts.


I don't know if there's a good reason for them _not_ to be on by
default, though. It doesn't really cause a significant impairment in
almost every case I can think of...
Exactly. It is something I've been considering passing as a parameter in 
Ubuntu Studio as well since that it seems to solve a lot of xrun issues.

I'm also going to be a little more intentional with working with the
pipewire developers on figuring out jack compatibility issues during the
F34 release cycle.


Isn't the idea that PipeWire would replace JACK and PulseAudio for
most, if not all, cases in the Fedora 34 timeframe? The pace of
development there seems to indicate some very intentional drive toward
that.

Yes, that's the goal. Unfortunately, there are multiple instances where 
packages that use JACK are looking specifically for the .so and aren't 
finding it, then throwing dnf errors when they don't find what they're 
looking for. I'm not sure it there needs to be some sort of symbolic 
link for compatibility reasons, but that's something I'm planning on 
exploring with the PipeWire team.


--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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 Jam 33 Beta - Possible Blocker?

[Erich Eickmeyer]

HI all,

Since the release of Koji 1.22, there has been a bug [1] blocking any 
Fedora Jam 33 or Rawhide iso images from being spun. As you can imagine, 
this is making me quite nervous. As it turns out, I'm waiting for Koji 
1.22 to be released so that images can start building again. If this 
isn't done in time for beta, then that means Fedora Jam will be unable 
to participate in beta testing.


The issue in question is caused because Jam adds "threadirqs" as a boot 
argument in addition to the normal boot arguments. This is a way to add 
some low-latency characteristics to a kernel that isn't otherwise a 
lowlatency kernel and is known to cut-down on xruns in audio production.


However, one question came up as to if threadirqs is a default in the 
kernel configuration, but nobody could answer that. I was wondering if 
anyone on this list knew?


I'm also going to be a little more intentional with working with the 
pipewire developers on figuring out jack compatibility issues during the 
F34 release cycle.


Thanks,
Erich

[1] https://pagure.io/koji/issue/2437

--
Erich Eickmeyer
Maintainer
Fedora Jam
___
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

Orphaning fst

[Erich Eickmeyer]

Hello all,

fst is a VST bridge for Windows VST plugins for wine only for i686 and
hasn't seen a commit since 2011-01-31[1]. With the F33 mass rebuild, the
day finally has come where fst is FTBFS due to bit rot.

Since there are newer solutions now, such as Carla, that do a good job
of bridging, I don't see any reason for this package to be maintained
anymore. Honestly, it should probably be retired.

[1] https://repo.or.cz/w/fst.git


Erich Eickmeyer
Fedora Jam Maintainer



pEpkey.asc
Description: application/pgp-keys
___
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 33 Mass Rebuild

[Erich Eickmeyer]

On 8/3/2020 9:42 AM, Neal Gompa wrote:
> On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster
>  wrote:
>> On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes  wrote:
>>
>>> Most of those are the libcroco->gettext breakage, no?
>> From a very cursory scan (not at all scientific),
>> some percentage are the cmake macro changes.
> CMake macros are documented in the packaging guidelines:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/
>
> Here's an example of how to adjust it:
> https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f

Indeed, using this example appears to have fixed at least one of my
packages.


Erich Eickmeyer
Fedora Jam Maintainer




pEpkey.asc
Description: application/pgp-keys
___
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 33 Mass Rebuild

[Erich Eickmeyer]

On 8/3/2020 9:38 AM, Gary Buhrmaster wrote:
> On Mon, Aug 3, 2020 at 4:24 PM Peter Robinson  wrote:
>
>> There's also a bunch of CMake related ones and I'm not even sure how
>> to deal with that.
> The proposal owners stated that:
>
> Existing packages can (and most likely will) become FTBFS, but
> proposal owners will fix as many Fedora packages as possible.
>
> I interpret that as the proposal owners are about to push
> a bunch of fixes RSN and rebuild the impacted packages.

I certainly hope so. All of my FTBFS packages are due to the cmake
issue. This is not good, and I have zero knowledge of how to fix them.

-
Erich Eickmeyer
Fedora Jam Maintainer



pEpkey.asc
Description: application/pgp-keys
___
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 flatpaks on non-x86 architectures

[Erich Eickmeyer]

On 7/25/2020 3:39 PM, John M. Harris Jr wrote:
> The solution is to run the following command:
>
> `dnf install $package`. This will install your arch's version of the package 
> you're looking for.

John,

This is neither helpful, nor warranted. It is clear that you don't like
the direction that Fedora is going, so perhaps it's time that you left
the project and stop commenting in the mailing list. Your needs and
wants are completely different than the direction Fedora is going and
you are attempting to impede progress by nay-saying every single change
that comes across and then poo-pooing newer technologies such as flatpak.

I suggest you move project that doesn't move as quickly so that you can
keep things the way you like it, such as Debian, or perhaps even Devuan
since you seem to have a disdain for systemd as well. Either way, you
need to stop posting to this list.

Your comment shows that you don't like flatpaks, and that's fine and you
can have that opinion, but you didn't need to respond at all.

Thank you very much for reading this, but you really need to go.


Erich Eickmeyer
Fedora Jam Maintainer



pEpkey.asc
Description: application/pgp-keys
___
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

Review Swaps: new-session-manager

[Erich Eickmeyer]

Hi all,

I know I unretired non-daw, but the Linux Audio community has developed
a drop-in replacement for non-session-manager as a fork called
new-session-manager. I've packaged it for both Ubuntu and now Fedora.

If anybody would be so kind as to review this package, the bug is at
https://bugzilla.redhat.com/show_bug.cgi?id=1853780.

I'd be glad to review another package in exchange, but bear in mind that
if it's not a relatively simple package I might not be able to be much help.

Thanks,
Erich

Erich Eickmeyer
Fedora Jam mainainer




pEpkey.asc
Description: application/pgp-keys
___
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

Intent to retire/remove lv2-artyfx-plugins

[Erich Eickmeyer]

Hi all,

I packaged lv2-artyfx-plugins for Ubuntu recently. While it was
undergoing review by the archive admins (they review all of the
copyright headers in the source files for compliance in addition to
other items, they're basically the gatekeepers of the Ubuntu
repositories), it was pointed out to me that these plugins create a
binary that is combined from sources using both GPL-3+ and GPL-2 (not
GPL-2+ as would be indicated with the "or later version" clause).

Because of this, it turns out that this package, while the source
files can be redistributed, the binaries cannot because the source
files licensed as GPL-2 (again, not GPL-2+) are not compatible with
GPL-3 since it is a later version.

So with that, I intend to retire this package, and I believe it would
be in the best interest of the project if the package can be removed
from the repositories as the binaries are basically an illegal
redistribution in many countries.

Thanks,
Erich
----
Erich Eickmeyer
Fedora Jam
___
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 Jam switch to GNOME

[Erich Eickmeyer]

Hello everyone,

After lengthy consideration, I have decided *not* to move Fedora Jam to
GNOME from Plasma for the time being. However, I'd appreciate a lot of
testing with pipewire on both Workstation and Jam, as would the pipewire
team.

Remember, the Jam packages can be installed regardless of desktop
environment by running "sudo dnf groupinstall 'Audio Production'". Also,
available in the repos is Studio Controls which does all of the tweaking
for Jack and real-time/lowlatency audio access automatically. This is
the upstreamed version of "Ubuntu Studio Controls". The only tweak it
does not make is adjusting swappiness to 10, which I have set as default
in Jam.

Thanks for all of the feedback!

-Erich

Erich Eickmeyer
Fedora Jam





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Jam switch to GNOME

[Erich Eickmeyer]

Hi Yann,

On 6/11/20 10:50 AM, Yann COLLETTE wrote:
> Hello,
>
> I have a repository with a real time kernel I use for music.
> https://copr.fedorainfracloud.org/coprs/ycollet/linuxmao/
>
> With this kernel, I can 128 samples buffer at 48kHz and 5 ms latency
> without Xruns.
> I use "a lot" of applications to perform guitar (guitarix + tuxguitar).
> I also can record video "live".
>
> Here's an example:
> https://www.youtube.com/watch?v=HPL-iNg42Ag
>
> Best regards,
>
> YC
>
Sounds great, but you might think about making it a lowlatency kernel
instead. Real-time kernels have a plethora of security implications when
used on desktop systems. Real Time kernels are meant for embedded
systems, and using one in your desktop system to reduce latency isn't
worth the security risk. See
https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel

Other than that, I wouldn't mind having you on the Fedora Jam team. :)

-Erich

___
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 Jam switch to GNOME

[Erich Eickmeyer]

On 6/11/20 10:33 AM, Jonathan Wakely wrote:
>
> "The beatings will continue until morale improves" ?
>
No. The only way to provide feedback to improve something is to actually
*use* the product. Yelling and screaming if you're not actually using it
does nothing to improve it.





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Install gparted to Live installers

[Erich Eickmeyer]

On 6/4/20 11:37 AM, Adam Williamson wrote:
> On Thu, 2020-06-04 at 11:32 -0700, Samuel Sieb wrote:
>> On 6/4/20 9:52 AM, Michael Catanzaro wrote:
>>> I don't think we actually have the technical capability to ship it
>>> in 
>>> live media without also installing it by default on the installed
>>> system.
>>>
>>> It currently has to run as root, which is not acceptable, so would 
>>> require some work to split out privileged operations into a
>>> separate 
>>> backend process and use polkit for authentication. I think it would
>>> make 
>>> more sense to focus on improving Disks to do what you need rather
>>> than 
>>> rewriting GParted.
>> As far as I can tell, it's already using polkit.  It asks for 
>> authentication before running.  On the live image, the user doesn't
>> have 
>> a password, so you might not see the dialog.  (There was a bug with
>> that 
>> previously.)
> Well, it does actually use polkit, but it doesn't do the important
> thing - it just uses polkit to authorize running *the entire app* as
> root. The /usr/bin/gparted wrapper is more or less functionally
> equivalent to just doing 'sudo gpartedbin'. The way this is 'supposed
> to be done' is that the app would run as a regular user, and use polkit
> to authorize only running the *specific operations* that require root
> privileges as root.

Interestingly enough, this is the way partitionmanager (a KDE app) works.

I'll be sure to dodge the KDE hate.


Erich Eickmeyer
Fedora Jam

___
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

Review Swap and/or simple review: studio-controls and mudita24

[Erich Eickmeyer]

Hi all,

I would like to get a couple of packages reviewed, and maybe do a review
swap, but I'm not sure how much help I would be on other packages since
I still feel pretty new to this.

First up is studio-controls:
https://bugzilla.redhat.com/show_bug.cgi?id=1836542

Studio Controls is formerly known as Ubuntu Studio Controls. It is the
bread-and-butter of the audio setup in Ubuntu Studio that makes it so
simple to work with Jack and work with multiple audio devices with Jack
which is not possible with other utilities, namely qjackctl. Recently,
the main developer and I made this a true upstream project. I wish to
bring this application to Fedora.

Next is mudita24: https://bugzilla.redhat.com/show_bug.cgi?id=1836540

mudita24 is a modification of envy24control in alsa-tools. envy24control
has some limitations and is known for being extremely buggy. This
application fills a lot of the shortcomings that envy24control has.

Let me know if you have any questions.

Erich

Erich Eickmeyer
Fedora Jam





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning soundtracker

[Erich Eickmeyer]

Hi all,

soundtracker is FTBFS and is basically gnome 1 software that
necro-limped along like a zombie for a few years (read: decades). As it
FTBFS and is dead upstream, I believe it's suffering bitrot so it's
probably time to let it die.

As such, I'm orphaning this package, and it will probably be retired.

Thanks,
Erich

Erich Eickmeyer
Fedora Jam




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Erich Eickmeyer]

On Thursday, April 2, 2020 4:56:33 PM PDT Adam Williamson wrote:
> Correction here: the decision process *was* actually initiated quite
> publicly. It was announced in January, in a thread titled "Git Forge
> Requirements: Please see the Community Blog", which (as you'd guess)
> linked to a Community Blog post announcing that a decision was to be
> made under the Open Decision Framework:
> 
> https://communityblog.fedoraproject.org/git-forge-requirements/

Ok, I stand corrected then. :)

> thus far, I'd say that was an example of good process, on the face of
> it.

Yes, on the face, and with good intentions nonetheless. :)

> It can be argued that things went wrong later. 

I agree 100% with that. Either way, Jeremy should not have been made to feel 
the way he is feeling, and I would guess that applies to many people in this 
thread. My point still stands that there was a failure at the leadership 
level.

Erich

signature.asc
Description: This is a digitally signed message part.
___
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: CPE Git Forge Decision

[Erich Eickmeyer]

Hi all. I'm a relative newcomer here and came to take-up the Fedora Jam 
project. I've been following this discussion very closely, and I've got to 
say, that I'm quite disappointed at the way this has been handled.

I'm not a software engineer by trade. I'm an audio engineer with 26 years of 
experience and a degree in leadership. That leadership degree is the hat that 
I want to chime-in with here, and the lens through which I'm viewing this.

On Thursday, April 2, 2020 4:25:53 PM PDT Jeremy Cline wrote:
> On Thu, 2020-04-02 at 11:52 +0100, Leigh Griffin wrote:
> 
> > 
> > The number of active developers on Fedora initiatives has gone up
> > drastically since I joined the team in 2019. You are possibly not
> > seeing that as the team have moved from a model of siloed work on
> > multiple apps, swimming against the tid working 16 hour days, to
> > working on team oriented initiatives to add real value to the
> > ecosystem. So the noise of working on multiple small things at once
> > is not as loud as it was in 2018 which is giving that illusion.
> 
> 
> I'd always suspected my work added no real value, but never had the
> proof. I appreciate the validation .
> 

Jeremy's comment here struck me to the core. If anybody on any team that I had 
led had mentioned this, I'd be broken-hearted. This is the sign of a complete 
failure at the leadership level. No volunteer or employee should *ever* be 
made to feel this way. Full stop. I have the feeling that Neal is feeling the 
same way. All of that hard work these people have done is being thrown away in 
their faces, and they have nothing to say about it. That is a complete 
leadership failure.

It is apparent in this discussion that the CPE (and especially Leigh) has 
failed in a leadership role. It's very possible that the Fedora Council has 
failed too for allowing this situation to happen. I don't care about the 
technical merits, I simply care about how this is being handled and how people 
are being treated in having their voices taken away from them. I think this 
goes against the whole "Friends" foundation.

The root of this leadership failure seems to be that the discussion happened 
mostly behind closed doors without any announcement *to this list* that this 
was being discussed. Transparency is *key* in leadership.

Honestly, this is making me, someone who came to this project only two months 
ago, wonder if it was, indeed, the right choice. I hope I'm not made to feel 
the same way as Jeremy, and I certainly hope I never make anyone I lead feel 
that way.


Erich Eickmeyer
Fedora Jam





signature.asc
Description: This is a digitally signed message part.
___
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: Orphaned packages looking for new maintainers

[Erich Eickmeyer]

On 3/30/20 11:38 AM, Scott Talbert wrote:
> On Mon, 30 Mar 2020, Emmanuel Seyman wrote:
>
>> * Miro Hrončok [30/03/2020 20:24] :
>>>
>>> perl-Data-Validate-Domain orphan   1
>>> weeks ago
>>
>> I've maintained this package for years now. Why is it considered it
>> orphaned?
>
> Because the maintainer (normunds) was non-responsive.  I don't see any
> commits from you??
>
> https://src.fedoraproject.org/rpms/perl-Data-Validate-Domain/commits/master
>
I just took lv2-ll-plugins, but it looks dead upstream. If it starts to
ftbfs, I'll likely just retire it.

___
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: Unretiring non-daw

[Erich Eickmeyer]

On Sunday, March 8, 2020 5:03:04 PM PDT Erich Eickmeyer wrote:
> Hello all,
> 
> I plan to unretire non-daw. The reason for retirement was FTBFS, and I
> managed  to get a successful local build and a successful copr build. I will
> be filing the review request ticket shortly.
 
Here's the review ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1811485
And the releng issue: https://pagure.io/releng/issue/9307

I might be dropping the review for RaySession depending on the outcome of 
this. I have received a lot of flack from the Linux Audio community regarding 
my having packaged RaySession and included it in Ubuntu Studio. They are of 
the opinion that it has the same functionality as Non-Session-Manager (part of 
non-daw) and is fragmenting by its nature of merely existing.

So, with that, I hope we can unretire non-daw.

Thanks,
Erich

Erich Eickmeyer
Fedora Jam

signature.asc
Description: This is a digitally signed message part.
___
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: Unretiring non-daw

[Erich Eickmeyer]

On Sunday, March 8, 2020 5:03:04 PM PDT Erich Eickmeyer wrote:
> Hello all,
> 
> I plan to retire non-daw. 

Of course, by retire I mean unretire.

Words are hard, and I have a headache.

-Erich

signature.asc
Description: This is a digitally signed message part.
___
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

Unretiring non-daw

[Erich Eickmeyer]

Hello all,

I plan to retire non-daw. The reason for retirement was FTBFS, and I managed to 
get a successful local build and a successful copr build. I will be filing the 
review request ticket shortly.

Thanks,
Erich

Erich Eickmeyer
Fedora Jam
___
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

Non-Responsive Maintainer: bsjones

[Erich Eickmeyer]

Hello all,

I have had zero success in contacting Brendan Jones per the non-responsive 
maintainer checks I filed in Bugzilla:

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

Additionally, I attempted a pull request on fedora-jam-backgrounds that got 
met with no response.

As these attempts were over a week ago, I guess my next step is to submit a 
FESCo issue with the bug links. However, since this is my first post 
specifically looking for bsjones unlike my previous post, perhaps I should 
give it another week? Or, does my previous post looking to adopt fedora-jam-
backgrounds and fedora-jam-kde-theme count for that? If not, I'll err on the 
side of giving it another week.

Thanks,
Erich

Erich Eickmeyer
Fedora Jam

signature.asc
Description: This is a digitally signed message part.
___
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: Adopting fedora-jam-kde-theme and fedora-jam-backgrounds

[Erich Eickmeyer]

Hi Ankur,

On Saturday, February 22, 2020 1:34:40 AM PST Ankur Sinha wrote:
> On Fri, Feb 21, 2020 17:40:53 -0800, Erich Eickmeyer wrote:
> [snip]
> 
> If Brendan is non-responsive you can follow the non-responsive
> maintainer policy to take over the packages:
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_
> maintainers/

Done. :)

> A proven packager can help in the meantime:
> https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/
> 
> > I understand that I still need to be sponsored into the packager
> > group, and I still have 3 other packages undergoing review (all of
> > which I have corrected per comments).
> 
> I'm sure you'll be sponsored soon, so that isn't a problem. Is a sponsor
> already looking at your reviews?

I have had a few people looking at my reviews. After I made corrections and 
posted that info, I have had zero responses on my bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1801352
https://bugzilla.redhat.com/show_bug.cgi?id=1803945
https://bugzilla.redhat.com/show_bug.cgi?id=1804307

All three packages are building and test well, and I have a copr opened at 
https://copr.fedorainfracloud.org/coprs/eeickmeyer/Jam-Incoming/packages/ for 
packages I intend to include in Jam eventually. I'm not sure if there's 
anything further I need to do, but perhaps you have more info.

Thanks,
Erich

Erich Eickmeyer
Fedora Jam

___
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

Non-responsive maintainer: Brendan Jones (bsjones)

[Erich Eickmeyer]

I have filed the following non-responsive maintainer checks for bsjones 
regarding packages fedora-jam-kde-theme and fedoar-jam-backgrounds:

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

Here is the fedora-active-user output:

Last login in FAS:
   bsjones 2020-02-03

Last action on koji:
   Sat, 11 Jan 2020 tag_package_owners entry revoked by oscar

Last package update on bodhi:
   2019-10-14 07:30:03 on package drumkv1-0.9.10-1.fc30 qtractor-0.9.10-1.fc30 
samplv1-0.9.10-1.fc30 synthv1-0.9.10-1.fc30
Last actions performed according to fedmsg:
  - oget.fed...@gmail.com updated 'cc' on RHBZ#1706391 'hexter gui doesn´t 
start' on 2020-02-21 19:09:22
  - releng updated 'flag.needinfo' on RHBZ#1799338 'fedora-jam-kde-theme: FTBFS 
in Fedora ra...' on 2020-02-15 20:34:29
  - releng updated 'flag.needinfo' on RHBZ#1799338 'fedora-jam-kde-theme: FTBFS 
in Fedora ra...' on 2020-02-15 20:34:28
  - releng updated 'flag.needinfo' on RHBZ#1799944 'python-poppler-qt4: FTBFS 
in Fedora rawh...' on 2020-02-15 20:30:27
  - releng updated 'flag.needinfo' on RHBZ#1799944 'python-poppler-qt4: FTBFS 
in Fedora rawh...' on 2020-02-15 20:30:27
  - releng updated 'flag.needinfo' on RHBZ#1799981 'rosegarden4: FTBFS in 
Fedora rawhide/f32' on 2020-02-15 20:28:40
  - releng updated 'flag.needinfo' on RHBZ#1799981 'rosegarden4: FTBFS in 
Fedora rawhide/f32' on 2020-02-15 20:28:40
  - releng updated 'flag.needinfo' on RHBZ#1799863 'phat: FTBFS in Fedora 
rawhide/f32' on 2020-02-15 20:26:55
  - releng updated 'flag.needinfo' on RHBZ#1799863 'phat: FTBFS in Fedora 
rawhide/f32' on 2020-02-15 20:26:55
  - releng updated 'flag.needinfo' on RHBZ#1799678 'nekobee-dssi: FTBFS in 
Fedora rawhide/f3...' on 2020-02-15 20:25:14

As you can see, they have only been responsive by maintaining certain packages, 
but appear to have abandoned several packages.

If anybody knows a way to contact Brendan, please do. Otherwise, I believe it 
is safe to say the two packages I would like to adopt (fedora-jam-kde-theme, 
fedoara-jam-backgrounds) have been abandoned along with all the other packages 
listed in the output above.

Thanks,
Erich

Erich Eickmeyer
Fedora Jam
___
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

Adopting fedora-jam-kde-theme and fedora-jam-backgrounds

[Erich Eickmeyer]

Hi all,

While working on getting Fedora Jam a bit more modernized for F33 (the 
backgrounds and themes haven't been touched since 2013!), I found that 
my predecessor (Brendan Jones) still has fedora-jam-kde-theme and 
fedora-jam-backgrounds. I think it's safe to say that since he 
abandoned Jam that these two packages are now orphaned.


I have already moved the sources of both packages to pagure since they 
were formerly on his fedorahosted page. Additionally, I have simplified 
both packages into separate sources (used to be one git source) so I 
believe it's safe to say the .sh files from both srpms can be dropped. 
I just now opened a PR, but it appears as though Brendan is the owner 
and would have to accept that PR. Unfortunately, I believe that's not 
going to happen as he was unresponsive with Ben Cotton's keepalive 
request for Jam, which is why I stepped-in.


With that, I'd like to adopt both of these packages. I understand that 
I still need to be sponsored into the packager group, and I still have 
3 other packages undergoing review (all of which I have corrected per 
comments).


Thank you,
Erich

Erich Eickmeyer
Fedora Jam
Ubuntu Studio

___
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: Packages for Fedora Jam

[Erich Eickmeyer]

Hi Elliott,

On Tuesday, February 18, 2020 5:48:21 PM PST Elliott Sales de Andrade wrote:
> Hi Erich,
> 
> On Tue, 18 Feb 2020 at 12:10, Erich Eickmeyer 
> wrote:
> > I have filed bugzilla reports for each one and blocked FE-NEEDSPONSOR for
> > each
 one. I'd like to get these sponsored as soon as possible.
> >
> >
> 
> 
> To clarify, it is not the packages that need to be sponsored, it is *you*.
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_S
> ponsored

Thank you so much for that clarification. Still relatively new to this, in 
Ubuntu it's the packages that get sponsored, not the person. So, it's just a 
bit of a change of a change in mentality when it comes to sponsorship. :) 

Erich


___
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

Packages for Fedora Jam

[Erich Eickmeyer]

Hello everyone!

In my efforts to bring over tools from Ubuntu Studio that we've been using, I 
noticed we were missing some dependencies of studio-controls. With that in 
mind, I have packaged said dependencies (one of which was in UnitedRPMs that I 
simply took the .spec from and gave it some Fedora standardization).

https://bugzilla.redhat.com/show_bug.cgi?id=1803945 (zita-ajbridge, allows 
ALSA devices to become JACK clients)
https://bugzilla.redhat.com/show_bug.cgi?id=1804307 (python3-jack-client, a 
JACK client library for Python3)

Additionally, and to get familiar with Fedora's packaging, I did this one 
first:

https://bugzilla.redhat.com/show_bug.cgi?id=1801352 (raysession, an audio 
application session manager, replaces Non Session Manager and LADISH for 
functionality)

I have filed bugzilla reports for each one and blocked FE-NEEDSPONSOR for each 
one. I'd like to get these sponsored as soon as possible.

I'd appreciate your help!
Erich

Erich Eickmeyer
Fedora Jam
Ubuntu Studio

___
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 Jam failing compose

[Erich Eickmeyer]

On Wed, Feb 12, 2020 at 10:44 pm, Ankur Sinha  
wrote:

On Wed, Feb 12, 2020 14:00:26 -0800, Erich Eickmeyer wrote:

 Hi all,


Hi Erich,



 I've introduced myself as the new maintainer of the Fedora Jam 
audio lab.


Thanks again for taking it up!


 I'm looking at the compose log and they're failing[1]. I'm not sure
 why, but it appears as though carla didn't branch to F32 for 
whatever

 reason. I know it was failing to build, but that got sorted as of
 February 7th[2].

 Can someone tell me what's going on [3]?


I *think* the package needs to be "Carla", with a capital "c". DNF
doesn't find "carla" with a small "c" either.



Yes, Kevin and Ankur, you're both absolutely right. I just fixed it and 
sent a pull request for master and f32's branch of the kickstarts. Now, 
if someone would be so kind as to approve the pull request, that would 
be dandy. :)


Thanks,
Erich

___
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 Jam failing compose

[Erich Eickmeyer]

Hi all,

I've introduced myself as the new maintainer of the Fedora Jam audio 
lab. I'm looking at the compose log and they're failing[1]. I'm not 
sure why, but it appears as though carla didn't branch to F32 for 
whatever reason. I know it was failing to build, but that got sorted as 
of February 7th[2].


Can someone tell me what's going on [3]?

Thanks,
Erich

[1] 


[2] 
[3] Please? Pretty please?

___
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: Erich Eickmeyer

[Erich Eickmeyer]

Hello all!

I'm Erich, the current project leader of Ubuntu Studio, the creativity-oriented 
flavor of Ubuntu. I've been leading that project for the past two years.

In that time, my team and I have taken Ubuntu Studio strides from where it was. 
However, due to some circumstances I will not mention here, we are looking for 
an alternative, and Fedora, with the Fedora Jam lab and with CCRMA's attention, 
seemed to be the perfect place to land. That said, it seems as though the Jam 
lab is dead, so I am here to revive it with mattdm's blessing.

We revamped a tool called Ubuntu Studio Controls 
(https://help.ubuntu.com/community/UbuntuStudio/UbuntuStudioControls), which 
makes audio configuration for Jack super simple. We wish to port that tool to 
Fedora, so I, with the help of another, will be working on packaging that, 
possibly naming it Studio Controls or Jam Controls.

I bring with me a team of people, including the primary developer of Ubuntu 
Studio Controls. We intend to make Jam a great project for musicians and audio 
engineers alike. I've been doing audio engineering for nearly 26 years, so this 
is an area that's completely within my wheelhouse.

In order to do the Self-Contained Change Request required, I need to be CLA+1, 
so that's the motivation behind joining the packaging group or whatever other 
group anyone feels is relevant to this project.

Thanks for reading!
Erich Eickmeyer
___
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