[HEADS UP] update of kiss-fft library with added shared versions

[Guido Aulisi]

Hi,

kiss-fft library was a static only library, but recently added the
possibility to build shared versions too. The current version is
131.1.0
The shared versions are multiple, because they are compiled with
different number types.
We are upgrading this library adding the shared vwersions, but
maintaining the static version for now.
Ardour is a client of this library.

I could not find which packages requires this static library for
building, it's only a BR dependency.

Please users of this library let us know if we can safely upgrade this
library.

Thanks

Guido

FAS: tartina
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Guido Aulisi]

Hi,

> Il giorno 10 mag 2022, alle ore 15:29, Ben Cotton  ha 
> scritto:
> 
> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> This is initial step to move JDKs to be more like other JDKs, to build
> proper transferable images, and to lower certification burden of each
> binary. Long storyshort, first step in:
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> 
> This first step will move, one by one, individual JDKs in F37 to be
> built `--with-stdc++lib=static` and against in-tree (bundeld)
> libraries:  `--with-zlib="bundled"  --with-freetype="bundled"
> --with-libjpeg="bundled"  --with-giflib="bundled"
> --withlibpng="bundled"  --with-lcms="bundled"
> --with-harfbuzz="bundled" `
> 

-1 here, we should avoid bundled libraries


> We already made a heavy testing of the behavior, and user should not
> face negative experience. I'm not sure if this is
> 
> == Owner ==
> * Name: [[User:jvanek| Jiri Vanek]]
> * Email: jva...@redhat.com
> 
> 
> == Detailed Description ==
> Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> for whole picture
> 
> Please see 
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JDKs_in_RPMs_to_become_portable
> for this particular step. I would rather keep the details  in the main
> page then here.
> 
> == Feedback ==
> According to short investigations, there are already precedents, where
> certification is a reason to build once, certificate, and repack.
> 
> According to developers, the non-portbale JDK is  causing upredicted
> behavior different from other JDK vendors
> 
> According to JDK packagers and testers, there is to much JDKs now, and
> the 
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fedora_JDKs_to_become_single-built.2C_portable.2C_ordinary_JDKs.2C_while_keeping_comfortable.2C_usual_system_integration
> is the only way out
> 
> == Benefit to Fedora ==
> Please see 
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation
> for whole picture.
> 
> This particular proposal's main benefit will be that Fedora's JDKs as
> packed in RPMs will again start to resemble upstream JDKs and other
> vendors build, and some platform specific issues disappear, while JDKs
> remain same in view of system integration and user experience
> 
> == Scope ==
> * Proposal owners: push improved version of
> https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#request_diff
> to all JDKs - one by one from latest, over 17 to 11 and 8. Once
> settled down in F37 the backport to F36 is expected.
> 
> * Other developers: really, nothing. If there will be unexpected
> impact to other developers, the
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may
> need rework
> 
> * Release engineering: N/A [https://pagure.io/releng/issues #Releng
> issue number]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
> 
> 
> == Upgrade/compatibility impact ==
> The compatibility and upgrade path should remain completely smooth.
> 
> 
> == How To Test ==
> Install system JDK (java-17-openjdk) and ru your favorite application
> or development. No regression should be noted.
> 
> 
> == User Experience ==
> 
> Because of in-tree  libraries, minimal image or font rendering
> differences canbe spotted after very detailed investigations -
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_effects
> - still, no of th e
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_issues
> should be hit by this proposal.
> 
> 
> == Dependencies ==
> No dependent packages should notice the change.
> 
> 
> == Contingency Plan ==
> * Contingency mechanism: Revert the patches and rework
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> * Contingency deadline: before f37 release
> * Blocks release? Unless the java-stack will become completely borked then no.
> 
> 
> == Documentation ==
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> 
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___

I don’t agree with this proposal, a big -1 for this

FAS: tartina

Ciao
___
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: 

Re: soname bump on fluidsynth-libs in f32

[Guido Aulisi]

Il giorno mar, 11/05/2021 alle 13.56 +0200, Christoph Karl ha scritto:
> Hi!
Hi

> Trying to fix two security issues
> https://bugzilla.redhat.com/show_bug.cgi?id=194953
> and
> https://bugzilla.redhat.com/show_bug.cgi?id=1955611
> I made an unintended soname bump in f32.
> As far as I have seen, this is only in f32.
> Carl Georg help me and already rebuild:
> 
> audacious-plugins-3.10.1-8.fc32
> Carla-2.2.0-2.fc32
> csound-6.15.0-2.fc32
> denemo-2.4.0-2.fc32
> drumstick-1.1.3-3.fc32
> gstreamer1-plugins-bad-free-1.16.2-4.fc32
> minuet-20.08.3-2.fc32
> openttd-1.11.2-2.fc32
> prboom-plus-2.5.1.4-19.fc32
> qsynth-0.9.2-2.fc32
> scummvm-2.2.0-3.fc32
> tuxguitar-1.5.3-3.fc32
> 
> The following are not building OK:
> ardour5-5.12.0-19.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67397828
> 
if I remeber well ardour5 is not compatible with latest fluidsynth.
Ardour5 has been obsoleted by Ardour6 in f33+.

> fluidsynth-dssi-1.0.0-22.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67398025
> lmms-1.1.3-16.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67398113
> muse-3.0.2-10.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67398110
> swami-2.0.0-22.20110806svn386.fc32 -
> https://koji.fedoraproject.org/koji/taskinfo?taskID=67398310
> 
> I will try to find out why.
> 
> Best Regards
> Christoph
> ___
> 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



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

Re: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)

[Guido Aulisi]

Il giorno lun, 03/05/2021 alle 10.23 +0200, Miro Hrončok ha scritto:
> (The subject line referes to
> https://www.youtube.com/watch?v=E3418SeWZfQ)
> 
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise
> your
> package will fail to install and/or build when the affected package
> gets retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2021-05-03.txt
> grep it for your FAS username and follow the dependency chain.
> 
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
> 

I took these packages, I was comaintainer of most of them.

Add64
dssi
jmeters
lv2-fabla  
lv2-ll-plugins
lv2-mdaEPiano
lv2-newtonator
lv2-sorcer 
lv2-swh-plugins
lv2-vocoder-plugins
meterbridge

I tried to take also lv2-c++-tools, but this doesn't work on pagure,
maybe for the presence of ++?

Fas: tartina

Ciao
Guido


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

Re: So long for now...

[Guido Aulisi]

> Il giorno 19 feb 2021, alle ore 09:14, T.J. Yang  ha 
> scritto:
> 
> Hi Martin and Stephen
> 
> Thank you for maintaining  the pkgs for all these years. 
> Since I am using the Nagios rpms at my dayjob , I for one will spend time on 
> rpms producing matter.  
> But I am fedora EPEL rpm workflow  newbie and I don't maintain any existing 
> rpm.
> 
>  Are there experienced ones out there interested to  adopt these nagios pkgs 
> ?   

I took nagios and nagios-plugins because I use them.
I welcome co-maintainers

My FAS account is tartina

Ciao
Guido

> 
> On Sun, Feb 14, 2021 at 10:28 AM Stephen John Smoogen  
> wrote:
> 
> 
> On Sat, 6 Feb 2021 at 13:29, Martin Jackson  wrote:
> Hello everyone,
> 
> I've had some changes recently at my day job, and while I was hoping I 
> would have more time to take care of my Fedora (and EPEL) packages, that 
> seems to not be in the immediate future for me. I'm sorry to those who 
> depend on these.
> 
> I have orphaned:
> 
> pipx
> 
> git-up
> 
> (git up may not really be needed, it's a leaf package and now that git 
> can rebase and pull at the same it may be redundnant)
> 
> nagios
> 
> nrpe
> 
> nagios-plugins
> 
> I've also removed myself from dkms and nagios-plugins-check_updates.
> 
> I am maintaining my FAS account, and I hope to return - but I'm kidding 
> myself (and the users of these packages) if I represent that I'm really 
> taking care of them.
> 
> 
> Thank you for your work in taking many of these from me earlier. I appreciate 
> the work and understand how much 'real' life makes handling these packages 
> hard.  
> 
> -- 
> Stephen J Smoogen.
> 
> ___
> 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
> 
> 
> -- 
> T.J. Yang
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Proven Packagers: update Audacity

[Guido Aulisi]

Il giorno mar, 09/02/2021 alle 18.21 +, Ian McInerney ha scritto:
> On Tue, Feb 9, 2021 at 5:58 PM Germano Massullo <
> germano.massu...@gmail.com> wrote:
> > Can anybody please help updating Audacity package? I cannot help
> > this
> > time. Despite this package has 2 maintainers, the software is no
> > up-to-date and is highly unstable and crashes every time you use it
> > https://bugzilla.redhat.com/show_bug.cgi?id=1836497
> > 
> 
> 
> Speaking as a maintainer of it, the short answer is that I have not
> had time to untangle the mess that is the most recent upstream 2.4.2
> release. Upstream has made many changes that are becoming unfriendly
> to packagers in the recent release that I haven't had the day or so
> it would probably take to sort through them (they completely removed
> their autotools build system in a patch release - with no deprecation
> warning and without a fully working CMake build system that can use
> system libraries, they are switching to their own fork of wxWidgets
> and are starting to enforce its usage by build system checks, etc.).
> 
> I basically took the package to make sure it didn't get retired
> during the FTBFS after GCC 10 landed, but I am not a daily user of
> it. If you want to help maintain the package, just let me know and I
> can add you.

I can help too, I'm a user of many audio packages, and Audacity is one
of the most important.
My FAS user is tartina

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

[Guido Aulisi]

Hi Erich,

Il giorno gio, 14/01/2021 alle 10.14 -0800, Erich Eickmeyer ha scritto:
> 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

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

> 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

Thanks for your work for Jam Lab

> --
> Erich Eickmeyer
> Maintainer
> Fedora Jam

Ciao
Guido


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: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)

[Guido Aulisi]

Hi,

Il giorno mer, 13/01/2021 alle 13.46 -0700, Chris Murphy ha scritto:
> On Tue, Jan 12, 2021 at 8:48 PM Michel Alexandre Salim
>  wrote:

... snip

> There are separate issues.
> 
> grubenv is "OK" on ext4 and XFS. The issue is that none of the file
> systems developers like anything other than kernel code doing writes.
> One idea for this is a new MBR and GPT partition type, functionally
> identical to the GPT "BIOS Boot" type, that's exclusively for the
> bootloader to use however it wants. On BIOS it'd include core.img and
> grubenv. On UEFI it'd just be used for grubenv. This issue needs to
> be
> taken upstream to sort out the details, so it should be set aside as
> it relates to this proposal.

IMHO boot loaders should not write to filesystems, if this is needed to
hide the GRUB menu when boot is successful, then let's display it
always as it was one time. I don't think it we should follow Windows or
MacOS style here, the boot menu is useful.

> The issue with journaled file systems is that GRUB's file system
> drivers have no ability to do journal replay. Therefore there is a
> small risk the file system is rendered unbootable in a crash, because
> the bootloader only sees the no-replay state of the file system used
> for /boot. e.g. the bootloader can see grub.cfg, bls snippets, or
> even
> the kernel as either missing or as 0 length files, until the journal
> has been replayed. Small risk, big penalty. My suggestion for
> mitigation is to use FAT for /boot in simple cases, and Btrfs in less
> simple cases. It's just an idea, it's not urgent, but if things are
> being reconsidered for simplification anyway, this makes sense to me.
> 
> Ergo the idea for a "bootloader partition that is exclusively owned
> by
> the bootloader" is separate from "bootloaders don't do journal replay
> and therefore can have the wrong view of things, and fail to boot in
> rare cases following a crash."

Yet another partition needed to boot the OS. What when there are no
available paritions in BIOS mode, because other OSes used all the
available 4 partitions?

... snip

Ciao
Guido


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: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Guido Aulisi]

Il giorno ven, 20/11/2020 alle 11.26 -0500, Ben Cotton ha scritto:
> https://fedoraproject.org/wiki/Changes/DefaultPipeWire
> 
> == Summary ==
> This change proposal is to route all audio from PulseAudio and JACK
> to
> the PipeWire Audio
> daemon by default.
> 
> == Owner ==
> * Name: [[User:Wtaymans| Wim Taymans]]
> * Email: wim.taym...@gmail.com
> 
> 
> == Detailed Description ==
> Currently, all desktop audio is handled by the PulseAudio daemon.
> Applications make use of the
> PulseAudio client library to communicate with the PulseAudio daemon
> that mixes and manages the audio streams from the clients.
> 
> The desktop shell (gnome-shell) and the control panel
> (gnome-control-panel) both use the
> Pulseaudio client libraries to manage the volume and configuration of
> the PulseAudio daemon.
> 
> This proposal is to replace the PulseAudio daemon with a functionally
> compatible implementation
> based on PipeWire. This means that all existing clients using the
> PulseAudio client library
> will continue to work as before, as well as applications shipped as
> Flatpak.
> 
> All PRO audio is handled with the JACK client library, which talks to
> the JACK server. This
> proposal will install a JACK client library replacement that talks
> directly to PipeWire. All
> existing PRO audio jack applications will then work on top of
> PipeWire.

For pro audio we should test very deeply with clients like ardour,
audacity, rosegarden, hydrogen and so on.
Pro audio is very sensible to latency and real time scheduling, and
jack is very mature in handling these requirements.
IMHO pipewire is too young to accomplish these tasks.
I think this should be an opt-in or out and that jack should remain as
an alternative to pipewire's jack module.

Ciao
Guido

... snip


___
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: Bodhi down?

[Guido Aulisi]

Hello,

Il giorno sab, 02/01/2021 alle 09.16 -0600, Richard Shaw ha scritto:
> I tried to push an update but got the following:
> 
> Builds : Unable to create update. Bodhi failed to get a resource from
> PDC at the following URL " 
> https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=true_path=true=global_component=f33_size=100=rpm_component=OpenImageIO
> ". The status code was "500".

I think there's a problem in git pushing too, I got this error about
sqlalchemy:

remote: conn = _connect(dsn, connection_factory=connection_factory, 
**kwasync)
remote: sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) FATAL:  
remaining connection slots are reserved for non-replication superuser 
connections

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

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

Re: can't install package pipewire-jack-audio-connection-kit

[Guido Aulisi]

Il giorno ven, 01/01/2021 alle 20.01 +0100, Michael Schwendt ha
scritto:
> On Fri, 1 Jan 2021 06:58:43 -0500, Neal Gompa wrote:
> 
> > > Explicit "Conflicts" here, at least, in pipewire-jack-audio-
> > > connection-kit:
> > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970
> > > 
> > > Conflicts in distribution packages are bad, bad, bad and
> > > typically a dead
> > > end when someone runs into them due to dependencies.  
> > 
> > PipeWire replaces libjack and the JACK daemon, so the Conflicts are
> > correct.
> 
> Replacing packages is done via "Obsoletes", so depsolving tools can
> do
> the right thing automatically. As can be seen on above koji page, the
> "Obsoletes" tag is empty.
> ___
> 

Jack is still in use for professional audio and it cannot be replaced
by pipewire, and it is still actively developed.
Pipewire just provides another implementation and you can choose which
one to use.

Ciao
Guido


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: Stale proven packagers

[Guido Aulisi]

Il giorno sab, 26/12/2020 alle 23.53 +0100, Björn Persson ha scritto:
> Gary Buhrmaster wrote:
> > Arguably those with elevated access (provenpackagers(*))
> > should be required to use a hardware token such
> > as a FIDO2 authenticators with biometrics and/or
> > PIN required
> 
> I'm in favor of complementing the FAS passphrase with a second
> factor.
> 
> I'm against any attempt to require biometrics. These are my reasons:

I totally agree with you, for the reasons you explained below.

> · Biometric identifiers aren't cleanly separated from identity. They
> are more akin to your username than to your passphrase. A random key
> or
> a passphrase can be revoked and replaced if it gets out. Fingers and
> faces are very difficult to replace. And yes they can get out. Once
> your fingerprint has been scanned and turned into data, those data
> can
> be copied like any other secret. You also leave your fingerprints on
> everything you touch.
> 
> · Such a requirement is unenforceable. A client can never prove to a
> server that it has a certain piece of hardware. It can only prove
> that
> it knows a certain secret – or two secrets since we're talking about
> two-factor authentication. Whether the secrets are stored on a hard
> disk, in a Yubikey, in somebody's brain or in somebody's retina, is
> unknown to the server. Before authentication it must be assumed that
> the client may be an attacker who is lying about everything they can
> lie about. Some protocol might allow the client to claim that it used
> a
> fingerprint reader, but as far as the server knows the attacker might
> just be using a stored scan of the real user's fingerprint.
> 
> · Biometrics is low-grade security for use where convenience takes
> precedence. If somebody can't remember a good PIN, then it's better
> for
> them to unlock their phone with their fingerprint than to choose
> ""
> for their PIN. Strong crypto keys and hardware tokens are better
> where
> security requirements are higher, like in two-factor authentication.
> Requiring biometrics is effectively the same as prohibiting stronger
> authentication methods, which is a stupid thing to do.

Guido Aulisi


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

Should we retire ardour5 in rawhide?

[Guido Aulisi]

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




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

HEADS UP -- Hydrogen SONAME bump

[Guido Aulisi]

Hi,
I'm updating Hydrogen drum machine to the latest version in rawhide.
It bumps SONAME in libhydrogen-core.so

To my knowledge nothing requires this library, it seems an internal use
only lib.

Ciao

Guido

FAS: tartina


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: Problems upgrading to f33 cloud edition

[Guido Aulisi]

Il giorno ven, 18/12/2020 alle 22.42 +0100, Marius Schwarz ha scritto:
> Am 18.12.20 um 20:37 schrieb Guido Aulisi:
> > 
> > Yes, but I found an issue regarding this list:
> > Package hwdata in F32 is newer than the one in F33.
> > 
> > hwdata-0.342-1.fc32 | hwdata-0.341-1.fc33
> 
> This happens with different packages from time to time and is nothing
> special.
> 
> Try this for your upgrade and see what happens ( add the -x exclude
> if 
> still needed )
> 
> rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-$(uname -i)
> dnf --allowerasing --releasever=33 --setopt=deltarpm=false distro-
> sync
> 
> If a dependency blocks you, you can simply erase the package manually
I succeeded in upgrading the system, but I had to remove NetworkManager
and reinstall it later.
The strange thing is that I didn't have console-login-helper-messages
installed in f32, maybe it's pulled in by some group in f33.

Thaks for help.

Guido

> before you upgrade, an reinstall it later.
> 
> 
> best regards,
> Marius
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

Re: Problems upgrading to f33 cloud edition

[Guido Aulisi]

Il giorno ven, 18/12/2020 alle 10.33 -0700, stan via devel ha scritto:
> On Fri, 18 Dec 2020 10:25:30 +0100
> Guido Aulisi  wrote:
> 
> > Hi, sorry for posting here if this is not correct.
> 
> Probably more appropriate for the user list.

Yes, but I found an issue regarding this list:
Package hwdata in F32 is newer than the one in F33.

hwdata-0.342-1.fc32 | hwdata-0.341-1.fc33

> > I'm upgraing a f32 cloud edition to f33 and I found this problem
> > which
> > I can't solve:
> > 
> > $ sudo dnf system-upgrade --releasever 33 --skip-broken
> > --allowerasing -vvv download
> > 
> > I get this response:
> > 
> > Error: 
> >  Problem: conflicting requests
> >   - package
> > console-login-helper-messages-issuegen-0.20.3-1.fc33.noarch
> > requires
> > NetworkManager, but none of the providers can be installed
> >   - package
> > console-login-helper-messages-issuegen-0.20.1-1.fc33.noarch
> > requires
> > NetworkManager, but none of the providers can be installed
> 
> It seems that something wants to install
> console-login-helper-messages-issuegen
> but the NetworkManager packages the only available versions can use
> cannot be installed, probably because there is a later version being
> installed.
> 
> > I don't have console-login-helper-messages installed in f32.
> 
> You could try
> 
> $ sudo dnf -x console-login-helper-messages-issuegen system-upgrade
> --releasever 33 --skip-broken --allowerasing -vvv download
> 
> so that it skips the install of whatever is requiring
> console-login-helper-messages-issuegen. At the least that should show
> you what the chain of dependencies is that is dragging in
> console-login-helper-messages.
> ___
> 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



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

Problems upgrading to f33 cloud edition

[Guido Aulisi]

Hi, sorry for posting here if this is not correct.
I'm upgraing a f32 cloud edition to f33 and I found this problem which
I can't solve:

$ sudo dnf system-upgrade --releasever 33 --skip-broken --allowerasing -vvv 
download

I get this response:

Error: 
 Problem: conflicting requests
  - package console-login-helper-messages-issuegen-0.20.3-1.fc33.noarch
requires NetworkManager, but none of the providers can be installed
  - package console-login-helper-messages-issuegen-0.20.1-1.fc33.noarch
requires NetworkManager, but none of the providers can be installed

I don't have console-login-helper-messages installed in f32.

Thanks for you help

Guido Aulisi


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: The Future of the Java Stack (also regarding ELN and RHEL)

[Guido Aulisi]

> Il giorno 10 set 2020, alle ore 16:53, Vitaly Zaitsev via devel 
>  ha scritto:
> 
> On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
>> Flatpak is way better suited for our use case and in addition gives us
>> access to a way bigger install base.
> 
> Flathub is a third-party repository and not related to Fedora at all.
> 
>> And the involvement on Java packaging in Fedora is so low that we literally 
>> have to maintain whole other stacks including jetty, lucene and etc. - not 
>> feasible work in any way.
> 
> Fedora Modularity team destroyed the entire Java stack in Fedora after
> moving ant/maven to modules.
> 
> I think FESCo should completely forbid modules without packaged
> non-modular versions.

I totally agree

> -- 
> Sincerely,
>  Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Ciao
Guido
___
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: Removing a branch created by mistake

[Guido Aulisi]

Il giorno mer, 09/09/2020 alle 15.57 +0200, Jun Aruga ha scritto:
> On Wed, Sep 9, 2020 at 3:28 PM Mikolaj Izdebski 
> wrote:
> > On Wed, Sep 9, 2020 at 3:15 PM Jun Aruga  wrote:
> > > Yesterday I created the "wip/2.7" branch on modules/ruby dist-git
> > > repository by mistake. ;-<
> > > https://src.fedoraproject.org/modules/ruby/branches
> > > 
> > > I remember the current rule is we can not remove the branch we
> > > created, right?
> > 
> > The branch can be removed as long as commits in the branch are
> > reachable from another branch.
> > See https://pagure.io/fesco/issue/2340#comment-628281
> 
> OH! Great news for people who created a wrong branch like me!
> Thanks.

I think there's a hook that doesn't permit git branch -d, but I never
tried myself.

Guido
Ciao


> -- 
> Jun | He - His - Him
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Guido Aulisi]

Hi,

> Il giorno 9 set 2020, alle ore 00:19, Fabio Valentini  
> ha scritto:
> 
> Hi everybody,
> 
> So, after some recent FESCo decisions (no default module streams in
> fedora, new Module Policy for fedora and ELN modules), it's time to
> ask this question again:
> 
> What's the future of the Java Stack in fedora, and by extension, in
> ELN (and possibly RHEL)?

… snip

IMHO we could package only the JDK and let the user use Java software directly 
from upstream.
Usually upstream means Apache, which is a trusted source, and Java users are 
smart enough to manage the Java packages.
I usuali do so when using maven, hadoop, tomcat, etc.
I think this solution could be valid for any other language, like php, python: 
packaging only the base language and anything that is not available in 
executable formats.

This is my personal opinion, your effort in supporting such huge Java stack has 
always been appreciated, also because I find it difficult packaging Java 
software.

Ciao

Guido
FAS: tartina
___
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

Build failure of zynaddsubfx on armv7hl

[Guido Aulisi]

Hi,

I got a segmentation fault trying to rebuild zynaddsubfx [0].

I pasted the main build.log below.

I found some strange compiler options passed by the build system and
g++ warns about that:
cc1plus: warning: switch '-mcpu=cortex-a9' conflicts with '-march=armv7-a' 
switch

Is this an annobin or lto problem?
Do I need to disable lto?

Thanks

Ciao
Guido
FAS: tartina

---
cc1plus: warning: switch '-mcpu=cortex-a9' conflicts with '-march=armv7-a' 
switch
*** WARNING *** there are active plugins, do not report this as a bug unless 
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
during IPA pass: icf
In member function 'replyArray':
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
gmake[2]: *** [src/UI/CMakeFiles/zynaddsubfx-ext-gui.dir/build.make:116: 
src/UI/zynaddsubfx-ext-gui] Error 1
gmake[2]: Leaving directory 
'/builddir/build/BUILD/zynaddsubfx-3.0.5/armv7hl-redhat-linux-gnueabi'
gmake[1]: *** [CMakeFiles/Makefile2:2313: 
src/UI/CMakeFiles/zynaddsubfx-ext-gui.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs

[0]: https://koji.fedoraproject.org/koji/taskinfo?taskID=48863016


___
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: s390x weirdness during mass rebuild

[Guido Aulisi]

Il giorno lun 27 lug 2020 alle ore 17:11 Jerry James
 ha scritto:
>
> I don't know if this is related to what we saw during the previous
> mass rebuild, but on s390x only, the TOPCOM build failed with:
>
> BuildrootError: Requested repo (1785306) is DELETED
I'm having the same issue.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1548001

FAS: tartina

Ciao
Guido
___
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 that failed to build with Python 3.9

[Guido Aulisi]

Il giorno ven, 29/05/2020 alle 21.59 +0200, Miro Hrončok ha scritto:
> Hello.
Hello,

> As you might already know, we have recently merged in the Python 3.9
> side tag, 
> despite several builds have not succeeded. We always aim for some
> compromise 
> between having the side tag open for too long and having too many
> failures.
> 
...snip

I just successfully rebuilt lilv, it failed only on s390x, because
dependant package sord had some problems on s390x and GCC 10.

I first rebuilt sord with -O1 optimization on all arches except x86.

I still have some optimization bugs with GCC 10 on arches other than
x86, I will try to understand how to reproduce them and file a bug on
GCC.

Ciao
Guido

FAS: tartina


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

New package review tickets page last update on 2020-04-06

[Guido Aulisi]

Hi,

the new package review tickets page [0] was last updated on 2020-04-06.
New tickets are not displayed, I made a new review request on April 19
and it never appeared on that page

Is there anything not working on auto updating that page?

Ciao
Guido
FAS: tartina

[0]: https://fedoraproject.org/PackageReviewStatus/NEW.html


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: Problems with packages compiled with gcc 10.0

[Guido Aulisi]

Il giorno mar, 19/05/2020 alle 18.43 +0200, Dan Horák ha scritto:
> On Tue, 19 May 2020 17:42:29 +0200
> Guido Aulisi  wrote:
> 
> > Il giorno mar, 19/05/2020 alle 12.11 +0200, Florian Weimer ha
> > scritto:
> > > * Guido Aulisi:
> > > 
> > > > I'm getting some strange errors from some packages built for
> > > > f32
> > > > with
> > > > gcc 10.0 [0].
> > > > Building with g++ 10.1 ardourd5 seems fine...
> > > > 
> > > > It seems GCC 10.0 had some bugs that could be discovered only
> > > > at
> > > > runtime. Did you have any similar problems?
> > > > 
> > > > Ciao
> > > > Guido
> > > > FAS: tartina
> > > > 
> > > > [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089
> > > 
> > > Comment 12 on that bug suggests that it's the known underlinking
> > > issue
> > > in Ardour (“it seems related to a missing symbol (__atan2_finite)
> > > in
> > > libvampplugins”).  If true, this is not related to GCC 10 at all.
> > 
> > Yes, that really seems a link and/or symbol versioning problem, but
> > it
> > wasn't the only one.
> > I had some other crashes in packages, usually not x86 arches.
> > As an example sord [0] was crashing on power64 when compiled with
> > -O2,
> > an exit condition in a for loop was optimized out until it crashed
> > the
> > loop. I had to use -O1 [1], and I have not tried with gcc 10.1 yet.
> 
> usually it's useful to report a bug against gcc if such things
> happen.
> Also there is https://gcc.gnu.org/wiki/FAQ#misoptimization the should
> help to localize the root cause. My blog
> (https://gcc.gnu.org/wiki/FAQ#misoptimization) has also some
> pointers.
> 
> 
>   Dan

Yes, I was trying to report a bug, but it was really hard to repeat all
the steps I made to get it; at that time I thought it was a program
bug, not some compiler optimization.
Next time (I hope never!) I will try to file a bug...

Ciao
Guido


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: Problems with packages compiled with gcc 10.0

[Guido Aulisi]

Il giorno mar, 19/05/2020 alle 12.11 +0200, Florian Weimer ha scritto:
> * Guido Aulisi:
> 
> > I'm getting some strange errors from some packages built for f32
> > with
> > gcc 10.0 [0].
> > Building with g++ 10.1 ardourd5 seems fine...
> > 
> > It seems GCC 10.0 had some bugs that could be discovered only at
> > runtime. Did you have any similar problems?
> > 
> > Ciao
> > Guido
> > FAS: tartina
> > 
> > [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089
> 
> Comment 12 on that bug suggests that it's the known underlinking
> issue
> in Ardour (“it seems related to a missing symbol (__atan2_finite) in
> libvampplugins”).  If true, this is not related to GCC 10 at all.

Yes, that really seems a link and/or symbol versioning problem, but it
wasn't the only one.
I had some other crashes in packages, usually not x86 arches.
As an example sord [0] was crashing on power64 when compiled with -O2,
an exit condition in a for loop was optimized out until it crashed the
loop. I had to use -O1 [1], and I have not tried with gcc 10.1 yet.

> Thanks,
> Florian

Ciao
Guido

[0]: https://src.fedoraproject.org/rpms/sord/
[1]: 
https://src.fedoraproject.org/rpms/sord/c/0a9adfc498d2e3cfcb3c8e67e53463beefdb10ff?branch=master


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

Problems with packages compiled with gcc 10.0

[Guido Aulisi]

Hi,
I'm getting some strange errors from some packages built for f32 with
gcc 10.0 [0].
Building with g++ 10.1 ardourd5 seems fine...

It seems GCC 10.0 had some bugs that could be discovered only at
runtime. Did you have any similar problems?

Ciao
Guido
FAS: tartina

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1837089


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 Weekly: 2020-05-11

[Guido Aulisi]

Il giorno lun, 11/05/2020 alle 09.40 +0100, Aoife Moloney ha scritto:
> # CPE Weekly: 2020-05-11
> ---
> title: CPE Weekly status email
> tags: CPE Weekly, email
> ---
> 
...
> 
> ## GitForge Updates
> * We are tracking our progress here (nothing new added yet, fyi)
> https://fedoraproject.org/wiki/Git_forge_update
> * And the council are tracking the community issues in this ticket
> https://pagure.io/Fedora-Council/tickets/issue/292
> * I have an  Office hours IRC meeting slot on #fedora-meeting-1 @
> 1400-1500 UTC every Thursday. Feel free to stop by and say hi! We can
> talk about Gitforge, or not :)
> 

Any chance to rethink this all, considering the way this decision was
adopted?

Ciao
Guido

FAS: tartina


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 Weekly: 2020-04-26

[Guido Aulisi]

Il giorno dom, 26/04/2020 alle 18.13 +0100, Aoife Moloney ha scritto:
> # CPE Weekly: 2020-04-26
> ---
> title: CPE Weekly status email
> tags: CPE Weekly, email
> ---

Hello,

... snip
> 
> ## GitForge Updates
> * We will be tracking our progress here
> https://fedoraproject.org/wiki/Git_forge_update
> * Please be aware this does not contain any new information, as we
> don't have any to share yet.
> * However once we have more information for you, we will be posting
> it
> to the above link, and with the URL in the weekly emails for quick
> access.
> * We are currently doing a technical deep-dive with our own team on
> what we need from GitLab
> * We are also still engaging with Fedora Council who are tracking the
> Fedora Communities needs here
> https://pagure.io/Fedora-Council/tickets/issue/292
> * And we are looking at ways to engage closer with the CentOS
> community too to share information as and when we have it
> * Public Q sessions are still being discussed to allow for open
> conversations in public forums too as we move through this journey,
> so
> thank you for your patience with us.

So you are doing a technical deep-dive now after choosing Gitlab, not
before deciding? It's a very strange way to take decisions...

I'd expect that the entire git forge discussion would start from the
beginning, because of the many mistakes that were made in this process.

Sorry for my bad english...

Guido Aulisi

FAS: tartina



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

Intent to retire jamin

[Guido Aulisi]

Hello,

I'm going to retire the jamin package [0], because it's unmaintained
upstream and it uses an old audio plugin standard (LADSPA).

According to this thread [1], it introduces a lot of distortion too.

Ciao
Guido

FAS: tartina

[0]: https://src.fedoraproject.org/rpms/jamin
[1]: https://discourse.ardour.org/t/ardour-jamin-cant-save-eq/88830/5


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: kiss-fft's builds failure on rawhide after upgrading of gcc and glibc

[Guido Aulisi]

Il giorno mar, 21/04/2020 alle 21.27 +0200, Guido Aulisi ha scritto:
> Il giorno mar, 21/04/2020 alle 11.19 -0700, Samuel Sieb ha scritto:
> > On 4/21/20 2:30 AM, Guido Aulisi wrote:
> > > I'm trying to understand why kiss-fft (an FFT library) is failing
> > > in
> > > rawhide only on aarch64.
> > > The failing test does some fft calculation and compares them with
> > > the
> > > same done with numpy.
> > > For waht I understood the upgrade of gcc and/or glibc makes this
> > > test
> > > fail only on aarch64, and I cannot undestand why gcc or glibc
> > > changed
> > > the maths or the precision used on this arch.
> > 
> > Can you get the output to see what's happening in the failing
> > test? 
> > That might help to figure out what's going wrong.
> 
> Yes, of course, sorry I forgot to link the Koschei failed build:
> 
> https://koschei.fedoraproject.org/package/kiss-fft?collection=f33
> 
> And this is the build.log:
> https://kojipkgs.fedoraproject.org/work/tasks/8318/43588318/build.log
> 

With the latest update of gcc and glibc kiss-fft's builds are back to
normal now, thanks gcc folks!

Ciao
Guido
___
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: kiss-fft's builds failure on rawhide after upgrading of gcc and glibc

[Guido Aulisi]

Il giorno mar, 21/04/2020 alle 11.19 -0700, Samuel Sieb ha scritto:
> On 4/21/20 2:30 AM, Guido Aulisi wrote:
> > I'm trying to understand why kiss-fft (an FFT library) is failing
> > in
> > rawhide only on aarch64.
> > The failing test does some fft calculation and compares them with
> > the
> > same done with numpy.
> > For waht I understood the upgrade of gcc and/or glibc makes this
> > test
> > fail only on aarch64, and I cannot undestand why gcc or glibc
> > changed
> > the maths or the precision used on this arch.
> 
> Can you get the output to see what's happening in the failing test? 
> That might help to figure out what's going wrong.

Yes, of course, sorry I forgot to link the Koschei failed build:

https://koschei.fedoraproject.org/package/kiss-fft?collection=f33

And this is the build.log:
https://kojipkgs.fedoraproject.org/work/tasks/8318/43588318/build.log

Thanks

Ciao
Guido

FAS: tartina



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

kiss-fft's builds failure on rawhide after upgrading of gcc and glibc

[Guido Aulisi]

Hello,

I'm trying to understand why kiss-fft (an FFT library) is failing in
rawhide only on aarch64.
The failing test does some fft calculation and compares them with the
same done with numpy.
For waht I understood the upgrade of gcc and/or glibc makes this test
fail only on aarch64, and I cannot undestand why gcc or glibc changed
the maths or the precision used on this arch.

I could disable tests, but it's not a great solution.

Can any gcc expert tell what changed between the release about math
calculation and maybe how to fix them or are these tests only a waste
of time and they should be disbled?

Thank you very much for any help.

Ciao
Guido

FAS: tartina


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

[Guido Aulisi]

Il giorno ven, 03/04/2020 alle 09.20 +0200, Miro Hrončok ha scritto:
> On 03. 04. 20 1:25, 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, rest assure that your work added real value.
> 
> I must concur with Erich in everything that they replied to this.

I would like to add that personally I like Pagure UX much more that
Gitlab.
If any help is needed to improve Pagure, I could add some of my little
fre time, it would be a reason to learn some more python programming.

Ciao
Guido Aulisi
FAS: tartina


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

[Guido Aulisi]

Il giorno mar, 31/03/2020 alle 12.42 +0200, Kevin Kofler ha scritto:
> Leigh Griffin wrote:
> > Thank you for your patience while the CPE Team worked through an
> > incredible number of requirements from multiple stakeholder
> > sources. On
> > Friday evening we announced on the Community Blog
> > <
> > https://communityblog.fedoraproject.org/making-a-git-forge-decision/
> > > our
> > decision to adopt Gitlab as our Git Forge and to retain pagure.io
> > to
> > ultimately hand over to the Community to maintain. It wasn't an
> > easy
> > decision by any stretch of the imagination and we hope that the
> > compromise
> > that we are striking will help to allow Pagure flourish and to give
> > a
> > choice of Forges for your usage. I'm happy to field any questions
> > or
> > comments about this decision.
> 
> What really worries to me is that:
> * using GitLab as SaaS is being considered, and
> * for self-hosting, using the proprietary "enterprise" editions is
> not
>   excluded.
> 
> I think that using anything other than Free Software as the hosting
> platform 
> for Fedora should be an absolute no go. In other words, self-hosted
> GitLab 
> CE or Pagure, no other options.
> 
> Kevin Kofler

I totally agree with Kevin +1.

Guido Aulisi


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

[Guido Aulisi]

Il giorno lun 30 mar 2020 alle 11:21 Leigh Griffin  ha
scritto:

> Hi everyone,
>
> Thank you for your patience while the CPE Team worked through an
> incredible number of requirements from multiple stakeholder sources. On
> Friday evening we announced on the Community Blog
>  our
> decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> ultimately hand over to the Community to maintain. It wasn't an easy
> decision by any stretch of the imagination and we hope that the compromise
> that we are striking will help to allow Pagure flourish and to give a
> choice of Forges for your usage. I'm happy to field any questions or
> comments about this decision.
>

I don’t agree with this. Pagare is the right tool for all.

Kind regards,
> Leigh, on behalf of the CPE Team
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford 
>
> Communications House
>
> Cork Road, Waterford City
>
> lgrif...@redhat.com
> M: +353877545162 IM: lgriffin
> @redhatjobs    redhatjobs
>  @redhatjobs
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Beware: java-1.8.0-openjdk SIGSEGVs / SIGABRTs in rawhide

[Guido Aulisi]

Il giorno gio, 19/03/2020 alle 12.07 +0100, Iñaki Ucar ha scritto:
> Yet another gcc10-related headache... I'm experiencing issues
> building rstudio in rawhide for i686: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=42614405. But I
> believe this is not the best package to chase the bug. No issues so
> far in F32, but you said this fails randomly?
> 
> Iñaki
> 

snip

I had problems with package sord and gcc 10, but not building, runtime,
when building other packages that use sord.
Doing test sord segfaulted in a for loop with iterators, where the end
conditions calls a function, which IMO is optimized out (?).
I had to compile with -O1 to get it working [0].
This only happened on ppc64le, arm, aarch64.

Guido
FAS: tartina

[0]: 
https://src.fedoraproject.org/rpms/sord/c/0a9adfc498d2e3cfcb3c8e67e53463beefdb10ff?branch=master


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: Intent to request a FESCo exception for python2 for ardour5

[Guido Aulisi]

Il giorno dom, 15/03/2020 alle 14.44 +0100, Fabio Valentini ha scritto:
> On Sun, Mar 15, 2020 at 2:37 PM Alexander Bokovoy <
> aboko...@redhat.com> wrote:
> > On su, 15 maalis 2020, Guido Aulisi wrote:
> > > Hi,
> > > 
> > > I’m going to ask a FESCo exception for python2 for package
> > > ardour5.
> > > Python2 is only needed to build the package using the WAF build
> > > system.
> > > 
> > > Ardour has been undergoing a complete rewriting for 2 years, no
> > > stable versions have been released in the last 2 years,
> > > so we are stuck with ardour 5.12, which still uses python2 to
> > > build.
> > > 
> > > What do you think about that?
> 
> (snip)
> 
> > Just package git master in Rawhide. It has been migrated to waf
> > 2.0.19
> > two months ago and builds just fine in Fedora 32 environments with
> > Python 3 only.
It's not considered ready for production by the developers, yet.

> I think FESCo would agree to temporarily continue building it with
> python2, given that upstream has already worked on supporting
> building
> with python3 eventually. At least, I would approve such an exception
> request (and other, similar requests for firefox, chromium, etc. have
> already been approved).
Thank you, I will make the request ASAP.

> But, if you think a current git snapshot would be an appropriate
> target for packaging, that solves the problem as well (I don't know
> how stable their development branch is).
AFAIK it's currently in alpha stage, I would wait for the next GIT tag.

Ciao
Guido
FAS: tartina


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: Beware: java-1.8.0-openjdk SIGSEGVs / SIGABRTs in rawhide

[Guido Aulisi]

Il giorno dom, 15/03/2020 alle 15.02 +0100, Fabio Valentini ha scritto:
> Hi everybody,
> 
> The latest java-1.8.0-openjdk update for rawhide (the first build
> with
> GCC 10) seems to have introduced some serious problems - including
> crashes and segmentation faults during package builds for Java
> packages.
I had some problems with sord package with GCC 10, I had to lower
optimization to -O1.
It only happened on power64le and arm arches, not x86.
The problem is in a for loop, the exit condition (with calls a function
whcih modifies its argument) is never(?) evaluated (optimized out?).
The problem is present in F32 as well.
I could not find the root cause, because I do not know power assembler
that well.

Ciao
Guido
FAS: tartina


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

Intent to request a FESCo exception for python2 for ardour5

[Guido Aulisi]

Hi,

I’m going to ask a FESCo exception for python2 for package ardour5.
Python2 is only needed to build the package using the WAF build system.

Ardour has been undergoing a complete rewriting for 2 years, no stable versions 
have been released in the last 2 years,
so we are stuck with ardour 5.12, which still uses python2 to build.

What do you think about that?

Ciao
Guido

FAS: tartina
___
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

Help needed debugging core dump while building lilv on ppc64le and arm

[Guido Aulisi]

Hi,
I'm trying to debug a build failure of package lilv on ppc64le and arm
platforms, x86 builds fine.

[0] is the status of lilv package on Koschei

The build core dumps while executing tests, in particular lilv_test,
which uses sord library.

Dmesg output:

[292790.757364] lilv_test[603241]: segfault (11) at 8 nip 7fffaaaf59b0 lr 
7fffaaaf59b8 code 1 in libsord-0.so.0.16.4[7fffaaaf+1]
[292790.757375] lilv_test[603241]: code: 2e2a 3b80 3b60 6042 
419200b0 83be 7bba26e4 7efed214 
[292790.757378] lilv_test[603241]: code: 83370010 eb170008 7b291f24 7d384a14 
 4bffc52d e8410018 a118

Debugging is difficult because it must be done in the chroot of a ppc64le 
machine and no gdb is available.

Any help is kindly welcome.

Ciao
Guido
FAS: tartina

[0]: https://koschei.fedoraproject.org/package/lilv
___
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

[Guido Aulisi]

Il giorno sab, 07/03/2020 alle 10.11 -0800, er...@ericheickmeyer.com ha
scritto:
> On Sat, 2020-03-07 at 19:04 +0100, Guido Aulisi wrote:
> > Hi Erich,
> > I took lv2-x42-plugins, because I've been maintaining it for the
> > latest
> > time, I'm currently maintaining some audio relatede packages, so we
> > could collaborate.
> > 
> > Ciao
> > Guido
> > 
> > FAS: tartina
> 
> Thanks, Guido
> 
> You beat me to it by mere seconds. I actually have a working
> relationship with Robin Gareus (x42) so I was looking forward to
> taking
> that one.
> 
> Not sure if you knew, but I'm reviving the Fedora Jam project and am
> the current leader of Ubuntu Studio. So, I'm no stranger to this
> stuff.
> :)

I added you to the commit group of lv2-x42-plugins, so you can
(co)maintain Robin's plugins.

Ciao
Guido
___
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

[Guido Aulisi]

Il giorno sab, 07/03/2020 alle 09.08 -0800, er...@ericheickmeyer.com ha
scritto:
> Hi Brendan,
> 
> On Sat, 2020-03-07 at 09:10 +0100, Brendan Jones wrote:
> > Hello,
> > 
> > the following packages have been orphaned and require a primary
> > maintainer. Feel free to take them over
> > 
> > Add64
> > aj-snapshot
> > ambdec
> > dssi
> > dssi-vst
> > gluidsynth
> > fluidsynth-dssi
> > freq-tweak
> > fst 
> > giada
> > gnome-guitar
> > harmony-seq
> > hexter-dssi
> > jackctlmmc
> > jmeters
> > ladish
> > libinstpatch
> > lv2-artyfx-plugins
> > lv2-avw-plugins
> > lv2-c++-tools
> > lv2-fabla
> > lv2-fomp-plugins
> > lv2-mdaEPiano
> > lv2-mdala-plugins
> > lv2-newtonator
> > lv2-sorcer
> > lv2-swh-plugins 
> > lv2-triceratops
> > lv2-vocoder-plugins
> > lv2-x42-plugins
> > meterbridge
> > mxml
> > nekobee-dssi
> > non-daw
> > non-session-manager
> > portmidi
> > radium-compressor
> > realTimeConfigQuickScan
> > seq24
> > soundtracker
> > whysynth-dssi
> > xsynth-dssi
> > 
> 
> I realize we recently had a discussion about me taking just the
> fedora-jam-* stuff, but I will likely take all of these. Anything
> that is dead upstream and FTBFS I'll likely be retiring. For anything
> that is alive upstream and FTBFS I'll work hard to get fixed. Thanks!
> 
> Erich

Hi Erich,
I took lv2-x42-plugins, because I've been maintaining it for the latest
time, I'm currently maintaining some audio relatede packages, so we
could collaborate.

Ciao
Guido

FAS: tartina


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

Creation of pkgconfig file for libraries that do not ship one

[Guido Aulisi]

Hi,
can we create a pkgconfig file for libraries that do not ship one?
I did not find anything about that in our packaging policy.

A bug was filed [0] about a missing pkgconfig file for zita-convolver
library and I'm thinking og creating the missing pkgconfig file
myself.

Thank you
Guido

FAS: tartina

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1809043
___
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 clalsadrv

[Guido Aulisi]

I'm going to retire clalsadrv, it's been deprecated upstream [0] for a
long time and it has been replaced by zita-alsa-pcmi.
Nothing depends on it in rawhide according to this query:

dnf --disablerepo='*' --enablerepo='rawhide' repoquery --whatrequires clalsadrv 
--alldep

Ciao
Guido

FAS: tartina

[0]: https://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html


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: Ideas for better development processes when maintaining hundreds of packages

[Guido Aulisi]

Il giorno mar 28 gen 2020 alle ore 10:04 Richard W.M. Jones
 ha scritto:
>
> I always think that Fedora works fine if you maintain 1-5 packages.
> It's possible to maintain 20 with a lot of work.  And if you want to
> maintain 100+ (things like the ocaml-* set that I help to maintain)
> then you have to write your own automation.  Could we do things
> better?  No one asked for them, but here are my ideas ...
>
> ---
>
> * kill the %changelog
>
> Please, let's kill it, and generate it from the git changelog.
> I'm glad to see there's a proposal to do this.
>
> A general principle I'm following here is a packager should never
> be asked to enter the same information twice.
>
> * committing to git should build the package
>
> Is there a reason why this wouldn't be the case?

Sometimes you only add comments to the spec file and a rebuild is not needed.

Ciao
Guido
___
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: Git Forge Requirements: Please see the Community Blog

[Guido Aulisi]

> Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini  
> ha scritto:
> 
> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  > wrote:
>> 
>> Hey Everyone,
>> 
>> On behalf of the CPE team I want to draw the communities attention to a 
>> recent blog post which you may be impacted by:
>> https://communityblog.fedoraproject.org/git-forge-requirements/ 
>> 
>> 
>> We will be seeking input and requirements in an open and transparent manner 
>> on the future of a git forge solution which will be run by the CPE team on 
>> behalf of the Fedora Community. This mail is being sent to the devel, 
>> mindshare and council-discuss lists for maximum visibility on a BCC to allow 
>> each list have their own views. Please forward it to any other list you may 
>> feel is relevant to maximise the exposure.
>> 
>> Thanks in advance,
>> Leigh
> 
> Alright, I have some questions that are not answered by the blog post.
> 
> - What is going to happen to the two pagure instances at pagure.io 
> ,
> and src.fedoraproject.org ?
> 
> I think pagure.io  is a good home for fedora-related 
> projects (it was
> the successor to fedorahosted.org , after all, 
> IIRC). I know that many
> group efforts are hosting their source code, ticketing system, etc.
> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> shut down pagure.io , I assume those projects will have to 
> be moved
> somewhere?
+1

> Also, it's very nice to have a PR-based workflow for some
> shared-maintenance packages on src.fedoraproject.org 
> , and I don't
> think losing that feature would be a good thing for fedora.
+1

> - How is GitHub considered to be an alternative here?
+1 …and to my knowledge GitHub is closed source.

> I don't think (public or hosted) GitHub can do what is currently done
> on src.fedoraproject.org , can it?
> I'd also not want to see fedora use a closed-source product for such a
> core service ...
> 
> - Which features are missing from pagure, compared to the other forges?
+1 It’s not clear reading the original POST

> For my purposes, I don't miss any feature on pagure.io  
> compared to my
> repositories on github.com , and OTTOMH, I can't come up 
> with any
> missing features, at all …
+1

> 
> TL;DR:
> Can we please keep pagure? It already has the fedora-specific features
> we need, and I don't mind a "slow" pace of development.
> In my experience, it works really well, and I actually *like* to use
> it (which is not true for GitLab ... which is slow and horrible)
+1

> Fabio

I totally agree with Fabio, I can’t think of a single reason we should dismiss 
pagure.

Ciao
Guido
FAS: tartina___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Philip Matura

[Guido Aulisi]

> Il giorno 5 dic 2019, alle ore 17:34, p...@tura-home.de ha scritto:
> 
> Hello,
> 
> my name is Philip Matura and I'm currently a student in mathematics. In
> my freetime I'm doing audio/music and electronics stuff. I've been
> converted to the Linux world with Fedora about 10 years ago and would
> like to give some things back.

Welcome to Fedora!

> So there are currently four packages I would like to see included in
> Fedora eventually, to which I would lend a hand in order to make that
> happen. Three of them already were submitted in the past, but didn't
> make it through (yet):
> 
> aelous (https://bugzilla.redhat.com/show_bug.cgi?id=789390)
> drumgizmo (https://bugzilla.redhat.com/show_bug.cgi?id=1210356)
> helm (https://bugzilla.redhat.com/show_bug.cgi?id=1661657)

Great! Some more audio related packages for Fedora

> But for now I'll start with this one:
> 
> zita-njbridge (https://bugzilla.redhat.com/show_bug.cgi?id=1780297)
> 
> So I am looking for a sponsor.

Unfortunately I cannot sponsor you, but I’ll take a look at your requests.

> Greetings,
> Philip

Ciao
Guido
FAS: tartina
___
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: Effort to remove libdb

[Guido Aulisi]

Ah, it permits linking only with GPLv3!!!
___
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: Effort to remove libdb

[Guido Aulisi]

Sorry if I misunderstood, but I thought BDB was licensed under the GNU
AFFERO GENERAL PUBLIC LICENSE v3 [1].
Is that not correct?

Ciao
Guido

[1]: https://www.oracle.com/downloads/licenses/berkeleydb-oslicense.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Upgrading libffi

[Guido Aulisi]

Il giorno lun, 06/01/2020 alle 18.11 -0500, Anthony Green ha scritto:
> I released a new version of libffi a month or so ago, the first one
> in 5
> years.  There's an ABI change that was unavoidable in order to
> accommodate the aarch64 port, and the sonumber was bumped.
> 
> I am also the Fedora package maintainer for libffi, but admit that I
> don't have the time or expertise required to manage an ABI-breaking
> libffi upgrade in Fedora (assuming the temporary requirement of a
> 'compat' package, etc), as there are many packages that depend on
> this
> library.
If you know all depending packages will get updated in an acceptable
time to the new ABI, you can wait for this to happen, and then rebuild
all in rawhide.

> Should I simply orphan libffi and hope that somebody picks it
> up?  I'm
> looking for the best path forward.
I don't think this would be the best solution! And you are surely the
best packager of your own software.

> Thanks! 
> 
> AG
> 
> -- 
> Anthony Green  

Ciao
Guido
___
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 unretire non-ntk

[Guido Aulisi]

Ciao,

I'm going to unretire non-ntk in rawhide and f31 releases,
because it's a dependency for lv2-sorcer and maybe other audio
packages.

I will file a review request ASAP, I have already made a scratch
build in rawhide [0]

FAS account: tartina

Ciao
Guido

[0]: https://koji.fedoraproject.org/koji/taskinfo?taskID=40167944


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: lv2-sorcer is not installable

[Guido Aulisi]

Il giorno dom, 05/01/2020 alle 12.21 +0100, Miro Hrončok ha scritto:
> On 03. 01. 20 19:24, Kevin Kofler wrote:
> > Zbigniew Jędrzejewski-Szmek wrote:
> > > The dep was provided by non-ntk, which got retired about half a
> > > year
> > > ago [1] after FTBFSing since F29 [2].
> > 
> > Isn't it great when the policy designed to
> > remove
> > breakage from the distribution actually CREATES breakage? Retiring
> > packages
> > with no regards to their reverse dependencies is just broken. It
> > had never
> > been done that way in the past, before Miro's recent crackdown,
> > because it
> > simply defeats all common sense.
> 
> As a matter of fact, the policy was changed recently, so depending
> package 
> maintainers MUST get notifications. The Fedora 31 round was
> unfortunate, mostly 
> because nobody got properly notified. I have devoted a great amount
> of energy 
> and time to make it better for next rounds. I hope it worked. Only
> couple of 
> packages are to be retired, where the maintainers simply don't care
> anymore with 
> only one dependent package:
> 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/YRLNHZSV4U47A3MDWIU6MUANVMPEFKD2/
> 
> For the F31 crackdown - it's not like a retired package cannot ever
> be 
> unretired. It has been more than 8 weeks now, but I gladly re-review
> a package 
> that got retired, if new maintainers pop up. Unlike you, I actually
> believe 
> packages must be maintained in order to be kept.

I'm working for unretiring non-ntk, I think I can file a new review
request in one week, as soon as I come back home; I'm already working
on it.

> The solution is not to stop orphaning/retiring FTBFS packages, the
> solution is 
> to get "broken deps" notifications working again:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RBV3UTSPIGW3TOZJSYTXCZMRV4QBR7X5/

Ciao
Guido

FAS: tartina


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: Build complete, but result generic error

[Guido Aulisi]

Il giorno lun 23 dic 2019 alle ore 09:24 Guido Aulisi
 ha scritto:
>
> Hi,
> Koji reports that build [0] is complete, but it is marked with this error:
> GenericError: cannot update build 1424540, state: COMPLETE
>
> It's not selectable in Bodhi.
> Do I have to run it again?
>
> Thanks
> Ciao
> Guido
>
> [0]: https://koji.fedoraproject.org/koji/buildinfo?buildID=1424540

I manually tagged this build with tag f31-updates-candidate, and now I
can see this update in bodhi.
Is this sufficient, do I have to add other tags (f31-signing-pending)?

Guido
fas: tartina
___
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

Build complete, but result generic error

[Guido Aulisi]

Hi,
Koji reports that build [0] is complete, but it is marked with this error:
GenericError: cannot update build 1424540, state: COMPLETE

It's not selectable in Bodhi.
Do I have to run it again?

Thanks
Ciao
Guido

[0]: https://koji.fedoraproject.org/koji/buildinfo?buildID=1424540
___
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: List of Python 2 packages to be removed mid-November

[Guido Aulisi]

> tartina
>lilv
>  (BuildRequires: python2-numpy → PY2)

Fixed.
___
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: Modularity and the system-upgrade path

[Guido Aulisi]

Il giorno mer 16 ott 2019 alle ore 11:58 Fabio Valentini
 ha scritto:
>
> On Wed, Oct 16, 2019 at 11:50 AM Alexander Bokovoy  
> wrote:
> >
> > On ti, 15 loka 2019, John M. Harris Jr wrote:
> > >On Tuesday, October 15, 2019 9:40:31 PM MST Neal Gompa wrote:
> > >> And to be fair, while it is a hard problem to solve, it's a worthy
> > >> one. It makes sense and if done well, could really distinguish Fedora
> > >> from the rest in providing a way for codifying individual lifecycles
> > >> separately from the distribution. Moreover, with all the container
> > >> circus stuff going on, it's become even more important to enable some
> > >> kind of parallel availability.
> > >
> > >If "parallel availability" is the problem Modularity is trying to solve, it
> > >seems that Modularity is a failure. You can't install more than one 
> > >version of
> > >a package at once.
> > You are mixing up parallel availability and parallel installability.
> > These aren't the same. Modularity does solve parallel availability
> > problem. It was never designed to solve parallel installability problem.
>
> And that is, in my opinion, the root source of all the issues that are
> currently plaguing Modularity.
> Parallel availability without parallel installability can only lead to 
> problems.
> This is just a new, shiny version of DLL hell. Thanks, I hate it.

+1
I totally agree

> Fabio
>
> > >Anyway, this is off topic, in my eyes, the best course of action is to 
> > >simply
> > >require that all modules have a non-modular version in Fedora. This can 
> > >also
> > >be done for things that are currently default modules. Sure, those who have
> > >existing installs with modules won't get their install fixed with the 
> > >current
> > >code, but new installations would. That's a start.
> >
> > I don't think it is not only reasonable to have this requirement but it
> > is also detrimental to the project to have the requirement that
> > basically doubles the amount of work volunteers have to do. Simply
> > providing content of default modules in non-modular way ignores the fact
> > that you somehow need to be able to rebuild those packages and they
> > might depend in their build dependencies on packages from other modules,
> > including non-default streams.
> >
> >
> > --
> > / Alexander Bokovoy
> > Sr. Principal Software Engineer
> > Security / Identity Management Engineering
> > Red Hat Limited, Finland
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: Intent to unretire qm-dsp

[Guido Aulisi]

Il giorno mer, 02/10/2019 alle 14.32 +0200, Guido Aulisi ha scritto:
> Hi,
> I'm going to unretire qm-dsp in all current Fedora supported
> releases,
> because it's a dependency for ardour5.
> 
> I will file a review request ASAP, I have already made a scratch
> build
> in rawhide:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=38004441
> 
> FAS account: tartina

I filed a review request for this
https://bugzilla.redhat.com/show_bug.cgi?id=1757778

Ciao
Guido
___
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 unretire qm-dsp

[Guido Aulisi]

Hi,
I'm going to unretire qm-dsp in all current Fedora supported releases,
because it's a dependency for ardour5.

I will file a review request ASAP, I have already made a scratch build
in rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=38004441

FAS account: tartina

Ciao
___
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: Defining the future of the packager workflow in Fedora

[Guido Aulisi]

Il giorno ven, 27/09/2019 alle 08.31 +, Petr Pisar ha scritto:
> On 2019-09-26, Pierre-Yves Chibon  wrote:
> > ○ Every changes to dist-git is done via pull-requests
> 
> Pull requests are great for proposing your changes to foreign
> packages.
> It does not make sense when maintaining the code. Either when doing
> a mass changes like rebuilding all Perl packages against a new perl
> or
> when pushing your own changes. It will become a bureaucracy that adds
> a delay and complexity and spams you mailbox. Who is going to merge
> all
> the requests? How do you automate it? We would need "koji watch-task"
> for merging the pull requests. I will repeat it: pull requests are
> great when you need a review. Otherwise it only consusmes resources.
> 
> I'm strongly against this.
I'm against too 100%

> 
> > ○ Pull-requests are automatically tested
> 
> Nice. But i think this already happens.
> 
> > ○ Every commit to dist-git (ie: PR merged) is automatically built
> > in koji
> 
> How do you want to implement waiting on propagating build root
> overrides?
Good question

> > ○ Every build in koji results automatically in an update in bodhi
> 
> How do I merge related updates into on if more packages must be
> tested and delivered as one unit? That very often happens with the
> overrides.
Another good question

> I smell automated side-tags that has never been implemented.
> 
> > ○ Every update in bodhi is automatically tested
> 
> This is already a reality.
> 
> > ○ If the tests pass, the update is automatically pushed to the
> > repository
> > 
> This also already happens.
> 
> -- Petr

I agree with you completely, packaging can be quite time consuming and
complex, with mandatory PR it could become really impossible.

Guido
Ciao


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: Audio packages depending on python2

[Guido Aulisi]

Il giorno ven 20 set 2019 alle ore 13:03 Leigh Scott
 ha scritto:
>
> Shouldn't you be using system waf instead of the ancient bundled version?, 
> try the waf-python3 package instead.

It's not that simple, every wscript file needs to be patched.
WAF change its API from version 1.7 (if I remember well), ardour5
still uses version 1.6 with old API and it does not work with python3

Ciao
Guido
___
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

Audio packages depending on python2

[Guido Aulisi]

Hi,
there are many audio related packages that depend on python2, mainly
because they use the WAF build system, which will be retired in f32 if
not ported to python3.
Porting them to python3 is not a trivial job.

Some of the most important packages are:
ardour5
jack-audio-connection-kit (next upstream release should fix this problem)
a2jmidid (I'm trying to port to python3
https://github.com/tartina/a2jmidid/tree/ftbfs)

Also, ardour5 depends on qm-dsp which has been retired, I will try to
unretire it soon.

I'm also unretiring ladspa-swh-plugins
https://bugzilla.redhat.com/show_bug.cgi?id=1750499 I'm waiting for a
review and sorry at the moment I cannot swap reviews, because I'm busy
fixing this problems.

Any help would be greatly appreciated.

Thanks

Ciao
Guido

FAS and Github: tartina
___
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: Donate 1 minute of your time to test upgrades from F30 to F31

[Guido Aulisi]

Il giorno mer, 11/09/2019 alle 14.54 +0200, Miroslav Suchý ha scritto:
> Do you want to make Fedora 31 better? Please spend 1 minute of your
> time and try to run [*]:
> 
>   sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31
> --enablerepo=updates-testing distro-sync
> 
> If you get this prompt:
> 
>   ...
>   Total download size: XXX M
>   Is this ok [y/N]:
> 
> you can answer N and nothing happens, no need to test the actual
> upgrade.
> 
> But very likely you get some dependency problem now. In that case,
> please report it against the appropriate package. Or
> against fedora-obsolete-packages if that package should be removed in
> Fedora 31. Please check existing reports first:
> https://red.ht/2kuBDPu
> 
> Thank you
> 
> [*] this command does not replace `dnf system-upgrade`, but it will
> reveal potential problems. You may also run `dnf
> upgrade` before running this command.
> 
> -- 
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

I got this:

Errore: 
 Problema: problem with installed package rubygem-asciidoctor-pdf-
1.5.0-0.9.alpha.16.fc30.noarch
  - rubygem-asciidoctor-pdf-1.5.0-0.9.alpha.16.fc30.noarch does not
belong to a distupgrade repository
  - nothing provides (rubygem(concurrent-ruby) >= 1.1.0 with
rubygem(concurrent-ruby) < 1.2) needed by rubygem-asciidoctor-pdf-
1.5.0-0.10.alpha.18.fc31.noarch
  - nothing provides (rubygem(treetop) >= 1.5.0 with rubygem(treetop) <
1.6) needed by rubygem-asciidoctor-pdf-1.5.0-0.10.alpha.18.fc31.noarch
(try to add '--skip-broken' to skip uninstallable packages)

Ciao
Guido

P.S. Sorry for the wrong answer to wrong Fedora version
___
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: Donate 1 minute of your time to test upgrades from F29 to F30

[Guido Aulisi]

Il giorno gio, 28/02/2019 alle 10.22 +0100, Miroslav Suchý ha scritto:
> Do you want to make Fedora 30 better? Please spend 1 minute of your
> time and try to run:
> 
>   sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30
> --enablerepo=updates-testing distro-sync
> 
> If you get this prompt:
> 
>   ...
>   Total download size: XXX M
>   Is this ok [y/N]:
> 
> you can answer N and nothing happens, no need to test the real
> upgrade. Upgrades will be fine for you.
> 
> But very likely you get some dependency problem now. In that case
> please report it against appropriate package.
> 
> Thank you
> 
> Miroslav

I got this:

Errore: 
 Problema: problem with installed package rubygem-asciidoctor-pdf-
1.5.0-0.9.alpha.16.fc30.noarch
  - rubygem-asciidoctor-pdf-1.5.0-0.9.alpha.16.fc30.noarch does not
belong to a distupgrade repository
  - nothing provides (rubygem(concurrent-ruby) >= 1.1.0 with
rubygem(concurrent-ruby) < 1.2) needed by rubygem-asciidoctor-pdf-
1.5.0-0.10.alpha.18.fc31.noarch
  - nothing provides (rubygem(treetop) >= 1.5.0 with rubygem(treetop) <
1.6) needed by rubygem-asciidoctor-pdf-1.5.0-0.10.alpha.18.fc31.noarch
(try to add '--skip-broken' to skip uninstallable packages)

Ciao
Guido
___
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 deprecate clalsadrv

[Guido Aulisi]

I'm going to deprecate clalsadrv, because it has been deprecated and
replaced by zita-alsa-pcmi upstream.

Nothing depends on it in rawhide:

dnf --disablerepo='*' --enablerepo=rawhide --enablerepo=rawhide-source
repoquery  --whatdepends clalsadrv --alldeps

reports only
clalsadrv-devel-0:2.0.0-20.fc31.i686
clalsadrv-devel-0:2.0.0-20.fc31.x86_64

FAS account: tartina

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

Re: Self Introduction: alciregi

[Guido Aulisi]

Il giorno lun, 09/09/2019 alle 19.02 +0200, alcir...@gmail.com ha
scritto:
> Hello. 
> My name is Alessio.
> FAS: alciregi
Welcome to Fedora...

> I work as an unpretentious sysadmin, mostly as the "IT guy".
> I've been a long-time user/administrator of *nix systems, starting
> with
> Red Hat Linux 6 in 1999. I've been a user of other distributions as
> well. Yeah, just a user.
> After some years of distro hopping, a couple of years ago I settled
> down and now I use Fedora as my main workstation; in the same period
> I
> decided to start to contribute. I'm more or less active in other
> areas
> of the community (anything important).
> Packaging has always been my dream, but since I'm not a developer I
> never started to learn how to do it.
> But now I'm interested in learning and do something useful.

A good starting point:
https://docs.fedoraproject.org/en-US/packaging-guidelines/

Also learning from other people's is very useful:
https://src.fedoraproject.org/

Ciao
Guido


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

Intent to unretire ladspa-swh-plugins

[Guido Aulisi]

I'd like to unretire ladspa-swh-plugins in rahwide, f31 and f30,
because it is a dependency of some packages I maintain:

ams
jamin

It's a dependency of pulseeffects too.

I will file a review request ASAP, I have already made a scratch build
in rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=37562823

FAS account: tartina

Ciao
Guido


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

Correct path for package bash completion file

[Guido Aulisi]

Ciao,
what is the right path for package bash completion file?

Most packages put then in %sysconf/bash_completion.d
some other (and bash_completion itself) in %datadir/bash-completion/completions/

IMHO I think %sysconf should be for users and %datadir for packages
Am I correct?

Thanks

Ciao
Guido
___
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: unorphaning ladspa-swh-plugins

[Guido Aulisi]

Il giorno mer 28 ago 2019 alle ore 12:16 Miro Hrončok
 ha scritto:
>
> On 28. 08. 19 8:47, Guido Aulisi wrote:
> > I'd like to take ownership of orphaned  ladspa-swh-plugins package,
> > because it's needed by some other packages I maintain.
> > For some reason I missed the orphaning announcement, I'm sorry for that.
> >
> > What are the next steps to unorphan it?
>
> Yes.
>
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package
>
> I.e. open a ticket in https://pagure.io/releng/issues

It seems it has been retired. Do I need to file a re-review?

Ciao
Guido
___
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

unorphaning ladspa-swh-plugins

[Guido Aulisi]

I'd like to take ownership of orphaned  ladspa-swh-plugins package,
because it's needed by some other packages I maintain.
For some reason I missed the orphaning announcement, I'm sorry for that.

What are the next steps to unorphan it?

Thanks.

FAS account: tartina

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

Re: HEADS-UP: soname version bump for zita-convolver

[Guido Aulisi]

Il giorno lun, 24/06/2019 alle 19.09 +0200, Igor Gnatenko ha scritto:
> Hi Guido,
> 
> On Mon, Jun 24, 2019 at 6:59 PM Guido Aulisi 
> wrote:
> > Hello,
> > I'm going to update zita-convolver library to version 4 in the next
> > weeks, it will be a rather slow job because of holidays :-)
> > 
> > According to dnf this update will impact the packages listed below:
> > 
> > guitarix-0:0.37.3-3.fc30.x86_64
> > jconvolver-0:0.9.2-17.fc30.x86_64
> > ladspa-zam-plugins-0:3.10-5.fc30.x86_64
> > lv2-guitarix-plugins-0:0.37.3-3.fc30.x86_64
> > lv2-ir-plugins-0:1.3.4-4.fc30.x86_64
> > lv2-x42-plugins-0:0.10.0-0.1.20190507.fc31.x86_64
> > lv2-zam-plugins-0:3.10-5.fc30.x86_64
> > pulseeffects-0:4.5.0-1.fc30.i686
> > pulseeffects-0:4.5.0-1.fc30.x86_64
> > zam-plugins-0:3.10-5.fc30.x86_64
> > zita-convolver-devel-0:3.1.0-17.fc30.i686
> > zita-convolver-devel-0:3.1.0-17.fc30.x86_64
> > 
> > I can rebuild most of them, but not pulseeffects, I've got no
> > commit
> > privileges on that.
> 
> Please ping me on IRC or over the email and I'll take care of it.
Hi Igor,
I made the upgrade and now only pulseeffects needs to be rebuilt, it
wasn't a hard work at the end...

Thank you for your help rebuilding that package.

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

HEADS-UP: soname version bump for zita-convolver

[Guido Aulisi]

Hello,
I'm going to update zita-convolver library to version 4 in the next
weeks, it will be a rather slow job because of holidays :-)

According to dnf this update will impact the packages listed below:

guitarix-0:0.37.3-3.fc30.x86_64
jconvolver-0:0.9.2-17.fc30.x86_64
ladspa-zam-plugins-0:3.10-5.fc30.x86_64
lv2-guitarix-plugins-0:0.37.3-3.fc30.x86_64
lv2-ir-plugins-0:1.3.4-4.fc30.x86_64
lv2-x42-plugins-0:0.10.0-0.1.20190507.fc31.x86_64
lv2-zam-plugins-0:3.10-5.fc30.x86_64
pulseeffects-0:4.5.0-1.fc30.i686
pulseeffects-0:4.5.0-1.fc30.x86_64
zam-plugins-0:3.10-5.fc30.x86_64
zita-convolver-devel-0:3.1.0-17.fc30.i686
zita-convolver-devel-0:3.1.0-17.fc30.x86_64

I can rebuild most of them, but not pulseeffects, I've got no commit
privileges on that.

jconvolver and zam-plugins need to be upgraded to latest versions to
work with new zita-convolver library, I will upgrade them.

Bye
Guido

fas account: tartina


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: Help needed for FTBFS in rawhide because of libraries order

[Guido Aulisi]

Il giorno lun 4 feb 2019 alle ore 13:14 Mamoru TASAKA
 ha scritto:
>
> Guido Aulisi wrote on 2019/02/03 20:31:
> > Hi,
> > I'm trying to debug a FTBFS in rawhide:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
> >
> > Apparently it fails because of library ordering, but it works in f29.
> > g_object_unref is defined in gobject-2.0 and it gets surely added by
> > the 'pkgconf  --libs cairo pangocairo pango' command.
> >
> > Did anything about gobject or glib change in rawhide recently?
> >
> > Thank you for any help.
> >
> > Guido
> >
> Apparently this is because rawhide pango.pc does not add -lglib-2.0
> when called with pkgconf --libs:
>
> F-29
> $ rpm -q pango
> pango-1.42.4-2.fc29.x86_64
> $ pkgconf --libs pango
> -lpango-1.0 -lgobject-2.0 -lglib-2.0
>
> F-30
> $ rpm -q pango
> pango-1.43.0-1.fc30.x86_64
> $ pkgconf --libs pango
> -lpango-1.0
>
> pango-1.43.0-1.fc30.x86_64 pango.pc shows:
> --
> Name: Pango
> Description: Internationalized text handling
> Version: 1.43.0
> Requires.private: glib-2.0 >=  2.38.0, gobject-2.0 >=  2.38.0, fribidi >=  
> 0.19.7, libthai >=  0.1.9, harfbuzz >=  1.4.2, fontconfig >=  2.11.91, 
> freetype2, xrender, xft >=  2.0.0, cairo >=  1.12.10
> Libs: -L${libdir} -lpango-1.0
> Libs.private: -lm
> --
> So -lglib-2.0 is moved to Requires.private.
>
> I guess this is due to this commit:
> https://gitlab.gnome.org/GNOME/pango/commit/86855b6a458fd9b82d246f723a7e3c9cdb37a8a0
> It seems to be doing some refactoring (with adding some fallback), and
> "requires: gobject_dep," line is deleted.
>
> Currently I am not sure if it is intentional or accidental.

Ok, now I understand why it does not work in rawhide

> Regards,
> Mamoru

Thank you very much

Ciao
Guido
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Help needed for FTBFS in rawhide because of libraries order

[Guido Aulisi]

Il giorno dom 3 feb 2019 alle ore 23:17 Kalev Lember
 ha scritto:
>
>
> On 2/3/19 12:31, Guido Aulisi wrote:
> > Hi,
> > I'm trying to debug a FTBFS in rawhide:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
> >
> > Apparently it fails because of library ordering, but it works in f29.
> > g_object_unref is defined in gobject-2.0 and it gets surely added by
> > the 'pkgconf  --libs cairo pangocairo pango' command.
> >
> > Did anything about gobject or glib change in rawhide recently?
> >
> > Thank you for any help.
>
> Not sure what changed, but if you are using a symbol from a library, the
> right thing to do is to list it in the 'pkgconf --libs' line so that you
> can be sure that you are linking against it and not relying on another
> library pulling it in.
>
> Just add gobject-2.0 to the 'pkgconf --libs' line and that should fix
> the issue you are seeing, hopefully.

Thank you for your suggestion,
I added -lgobject-2.0 -lglib-2.0 to LDFLAGS and the build was ok.
I don't want to modify or patch upstream's Makefile...

> Hope this helps,
> Kalev
It helped for sure!
I will search for root problem ASAP, I think I'll have to install a
full rawhide system to do that.

Ciao
Guido
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Help needed for FTBFS in rawhide because of libraries order

[Guido Aulisi]

Hi,
I'm trying to debug a FTBFS in rawhide:

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

Apparently it fails because of library ordering, but it works in f29.
g_object_unref is defined in gobject-2.0 and it gets surely added by
the 'pkgconf  --libs cairo pangocairo pango' command.

Did anything about gobject or glib change in rawhide recently?

Thank you for any help.

Guido

FAS account: tartina


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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change proposal: Make ambiguous python shebangs error

[Guido Aulisi]

Il giorno ven 31 ago 2018 alle ore 13:18 Miro Hrončok
 ha scritto:
>
> On 31.8.2018 08:22, Guido Aulisi wrote:
> > Can we explicitly call python2?
> > Instead of calling
> > ./waf ...
> > which contains the unversioned shebang, we call
> > python2 waf ... ?
>
> You can. This has nothing to do with this change. What am I not getting?
>

waf script contains unversioned python shebangs, but it's usually
provided by upstream developer,so instead of patching it I prefer
calling python2 explicitly.
I don't know if the new f30 build system checks this too, I remember
some warnings about waf containing wrong shebangs in the past.
I usually fix this problem calling waf this way:

%{_python2} waf ...

other ways are calling

python2 waf

or patching waf

Ciao
Guido
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 30 Self-Contained Change proposal: Make ambiguous python shebangs error

[Guido Aulisi]

Il giorno mer 22 ago 2018 alle ore 21:53 Ben Cotton
 ha scritto:
>
> https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error
>
> == Summary ==
> The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot
> policy script will be changed to make the build fail when it sees an
> ambiguous python shebang, such as #!/usr/bin/python or
> #!/usr/bin/env python. (The script has been warning in
> these cases for 2 Fedora releases already, saying ''This will become
> an ERROR''.)
>
> == Owner ==
> * Name: Miro Hrončok (churchyard)
> * Email: 
>
> == Detailed Description ==
> The buildroot policy script in
> /usr/lib/rpm/redhat/brp-mangle-shebangs currently changes
> all python shebangs to python2 with a message like:
>
>  *** WARNING: mangling shebang in /usr/bin/taskotron_result from
> #!/usr/bin/python to #!/usr/bin/python2. This will become an ERROR,
> fix it manually!
>
> We will change it to:
>
>   *** ERROR: ambiguous python shebang in
> /usr/bin/taskotron_result: #!/usr/bin/python. Change it to python3 (or
> python2) explicitly.
>
> The script will exit with nonzero exit code, rendering the build failed.
>
> The warning and a promise of the error was there for 2 releases (28
> and 29). Taskotron check was also present.
>
> There are standard mechanics to avoid this buildroot policy script or
> to block certain files form it. Those remain intact by this change.
> For details see
> https://fedoraproject.org/wiki/Packaging:Guidelines#Shebang_lines and
> https://fedoraproject.org/wiki/Packaging:Guidelines#BRP_.28BuildRoot_Policy.29_Scripts
> sections of the packaging guidelines.
>
Can we explicitly call python2?
Instead of calling
./waf ...
which contains the unversioned shebang, we call
python2 waf ... ?

Guido Aulisi
fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Library ABI change

[Guido Aulisi]

Hi,
recently serd library changed its ABI adding 1 function without
bumping the soname.
I think adding one function should not be a problem for depending
packages, what do you think about it?

Guido
fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TOJ2PS33R6C4LUJY6FBKXUEVNJZ5W64H/

Re: Build failures of packages which use waf as build system

[Guido Aulisi]

2018-07-17 0:38 GMT+02:00 Miro Hrončok :
> On 16.7.2018 21:54, Guido Aulisi wrote:
>>
>> I fixed some of these audio packages, prefixing waf calls with
>> %{__python2} macro. You have to BR python2-rpm-macros or python2-devel
>> to use it.
>
>
> Or you can just type "python2". However, if you need %{__python2} macro, BR
Can I type python2 without absolute path? If so it's even easier...

> python2-devel, not python2-rpm-macros. Consider python2-rpm-macros an
> implementation detail.
Ok, I'll fix it...

> Also, try to use %{__python3} or python3 with waf, it should be compatible,
> depending of course on the version.
Yes, of course, this is the next step, for now I just fixed the build problem.
I have to check every waf version in use, I had some problems in the
past with python3 and waf.

> --
> Miro Hrončok
Thank you very much
Guido
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G7R54DGDCHNTXJLL6QDYCP53PNHUTWVK/

Build failures of packages which use waf as build system

[Guido Aulisi]

Hi all,

I found many build failure of packages using waf as build system.
This is due to recent move of /usr/bin/python into a separate package

https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separat
e_package

Many audio related packages have this problem.

I fixed some of these audio packages, prefixing waf calls with
%{__python2} macro. You have to BR python2-rpm-macros or python2-devel
to use it.

For example:
https://src.fedoraproject.org/rpms/ardour5/c/e72960049735476c19c08a14cb
d5891556802753?branch=master

As discussed on the ML, this was the accepted solution, I hope this can
be useful to other people getting this problem

Guido

fas: tartina

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TIT5YDEUODUBTDOE2CGL754DWV6655F5/

Re: F29 System Wide Change: i686 Is For x86-64

[Guido Aulisi]

2018-06-04 10:35 GMT+02:00 Jan Kurik :
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
>
>
> Owner(s):
>   * Florian Weimer 
>
>
> Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.
>
>
>
> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).

Fedora 27 i686 stil runs well on a HP ProLiant ML570 G2, I don't have
kernel issues, I was unaware of kernel problems on i686.

Output of lscpu:
Architecture:i686
CPU op-mode(s):  32-bit
Byte Order:  Little Endian
CPU(s):  8
On-line CPU(s) list: 0-7
Thread(s) per core:  2
Core(s) per socket:  1
Socket(s):   4
Vendor ID:   GenuineIntel
CPU family:  15
Model:   2
Model name:  Intel(R) Xeon(TM) MP CPU 2.70GHz
Stepping:6
CPU MHz: 2694.885
BogoMIPS:5389.77
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
pebs bts cpuid cid xtpr

Kernel version: 4.16.11-200.fc27.i686+PAE #1 SMP Tue May 22 19:01:08
UTC 2018 i686 i686 i386 GNU/Linux

> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.

Will Fedora 29 run on the CPU listed above?

> == Scope ==
> * Proposal owners:
> Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
> new compiler flags. Except for mstackrealign, there is substantial
> experience with this configuration downstream.
>
> * Other developers:
> Other developers can enable SSE2 optimization in their packages if
> they want, where this has been a compile-time option only.
>
> * Release engineering:
> https://pagure.io/releng/issues/7543 #7543
>
> ** List of deliverables: TBD
>
> * Policies and guidelines:
> i686 is no longer a primary architecture. The Packaging Guidelines do
> not currently require support for non-SSE2 x86 systems, so no change
> is required there.
>
> * Trademark approval:
> N/A (not needed for this Change)
> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CC22ZTFDB5L3BFSQG7M3TUZUVYKFUSKP/

Guido Aulisi
Fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RE25T5GUJFSLZVRTQ7Z3JYB23PKH6Z6I/

Re: GCC 8.1.1 broken in rawhide due to annobin

[Guido Aulisi]

It seems broken in f28 too.

Ciao
Guido
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora mass rebuild 2018

[Guido Aulisi]

2018-02-22 21:47 GMT+01:00 Josh Boyer :
> On Thu, Feb 22, 2018 at 12:49 PM, Marek Polacek  wrote:
>> As many of you know, every year we (the GCC team) rebuild all the Fedora
>> packages with the upcoming GCC, so as to reveal as many bugs as possible 
>> before
>> we release the new version.  As in the previous years, it is only performed 
>> on
>> x86_64 only; we unfortunately lack the resources to deal with other arches.
>> Ideally we'd conclude this mass rebuild *before* the new GCC has gotten into
>> the buildroots; alas, this wasn't the case this year.

Thank you for your great job.

>
> josh
>
>>
>> Let's get down to the nitty-gritty:
...
>> jalv-1.6.0-3.fc27.src.rpm
I tried a mockbuild in current rawhide (jalv-1.6.0-4.fc28.src.rpm) and
it was successful.
...
>> lv2-x42-plugins-0.3.0-0.3.20170428.fc27.src.rpm
I've patched this package
(lv2-x42-plugins-0.3.0-0.5.20170428.fc29.src.rpm) and I've sent PRs
upstream

Ciao
Guido
fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Guido Aulisi]

2018-02-19 9:30 GMT+01:00 Igor Gnatenko <ignatenkobr...@fedoraproject.org>:
>> amsynth has been fixed in all supported branches.
>
> It should have both gcc and gcc-c++.

Done, BR for both.

Ciao
Guido Aulisi
fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Guido Aulisi]

2018-02-19 9:30 GMT+01:00 Igor Gnatenko <ignatenkobr...@fedoraproject.org>:
> On Mon, 2018-02-19 at 09:12 +0100, Guido Aulisi wrote:
>> Hi Igor
>>
>> > 2018-02-18 18:09 GMT+01:00 Igor Gnatenko <ignatenkobr...@fedoraproject.org>
>> > :
>> > Over this weekend I've performed scratch-mass-rebuild without having gcc
>> > and
>> > gcc-c++ in buildroot of all Fedora packages, many of which failed due to
>> > random
>> > reasons and I grepped all logs for some common errors found by analyzing
>> > hundreds of build logs.
>> >
>> > Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildReq
>> > uire
>> > s_and_Requies
>> >
>> > The grep output is located here:
>> > https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
>>
>> amsynth has been fixed in all supported branches.
>
> It should have both gcc and gcc-c++.

Sorry, I thought gcc-c++ implied gcc. When I tested the new buildroot
gcc was installed as a dependency.
If so, I have to fix other packages too.

Guido Aulisi
fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Guido Aulisi]

Hi Igor

> 2018-02-18 18:09 GMT+01:00 Igor Gnatenko <ignatenkobr...@fedoraproject.org>:
> Over this weekend I've performed scratch-mass-rebuild without having gcc and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due to 
> random
> reasons and I grepped all logs for some common errors found by analyzing
> hundreds of build logs.
>
> Guidelines: 
> https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildRequire
> s_and_Requies
>
> The grep output is located here:
> https://ignatenkobrain.fedorapeople.org/gcc-removal.txt

amsynth has been fixed in all supported branches.

Thanks for your work.

Guido Aulisi
fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Ambiguous python version in waf

[Guido Aulisi]

2018-02-05 12:00 GMT+01:00 Petr Viktorin <pvikt...@redhat.com>:
> On 02/05/2018 09:32 AM, Guido Aulisi wrote:
>>
>> Hi,
>> according to latest python guides, we should avoid calling generic
>> unversioned python command
>>
>> (https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)
>>
>> But what should we do if it's called inside waf? waf is provided
>> upstream, should we patch it to call either python2 or python3, or use
>> PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?
>>
>> I got this problem in recent ardour5 rawhide builds
>> (https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
>> Now I'm seeing that builds are back to normal and python2 has been
>> downgraded.
>>
>> Thanks
>
>
> Thanks for the question, and sorry for the inconvenience!
>
> The python2 message is, so far, only a warning. I see the log contains a
> different error: "--freedesktop requires itstool > 2.0.0 to translate
> files.".
> Could you check if that's not causing the failure?

I found that the check for itstool fails because it gets the
deprecation warning as input, there's a mistake in
output = subprocess.Popen("itstool --version", shell=True,
stderr=subprocess.STDOUT,
stdout=subprocess.PIPE).communicate()[0].splitlines()
stderr is redirected to stdout, so itstool gets DEPRECATION and
version [u'WARNING:']
I will report this upstream, it seems to me that the redirection of
stderr is a mistake.

> If the python2 message is breaking your build, then please file a bug and
> set an environment variable, as described in the Change. (Do file the bug,
> though – that ensures we'll contact you before we remove the workaround.)

> Background:
>
> We do want everyone to avoid calling /usr/bin/python, but we realize it's
> not always easy. That's why we added the warning -- it will allow us to grep
> the logs to figure out what is using it (and why). And of course, in simple
> cases it can be fixed right away.
> Some tools do fail if there's extra output on stderr; that's the reason for
> the "Quick Opt-Out" workaround.
>
> It looks like waf will be one of the tougher things to figure out. After the
> mass rebuild we'll see the effect on the whole distribution, and hopefully
> come up with a better strategy for bundled waf.

I will file a bug for waf, if it's the correct thing to do.

> --
> Petr Viktorin

Many thanks for your reply

Guido Aulisi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Ambiguous python version in waf

[Guido Aulisi]

Hi,
according to latest python guides, we should avoid calling generic
unversioned python command
(https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out)

But what should we do if it's called inside waf? waf is provided
upstream, should we patch it to call either python2 or python3, or use
PYTHON_DISALLOW_AMBIGUOUS_VERSION=0?

I got this problem in recent ardour5 rawhide builds
(https://apps.fedoraproject.org/koschei/package/ardour5?collection=f28).
Now I'm seeing that builds are back to normal and python2 has been downgraded.

Thanks

Guido Aulisi
FAS: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Infrastructure move -- thanks

[Guido Aulisi]

Great job, thanks to everyone

Guido
fas account: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Sailing to others seas

[Guido Aulisi]

2017-09-19 21:44 GMT+02:00 Alexandre Moine :
> Hi all,
>
> Short version: I am leaving from fedora to archlinux.
>
> Long version: I really want to thank ALL of the fedora community, which
> was more than friends. You have been in fact great teachers for me, when
> I started to contribute the 19/11/2012 (I was 14).
> You showed me not only how to contribute, but also how to work
> efficiently with opensource projects. I want to thank especially the
> entire french team who helped me being an ambassador and teach me many
> things (not to name the main ones: Emmanuel Seyman and Jean-Baptiste
> Holcroft).
>
> I am not leaving "brutally". I will continue to maintain my packages as
> long as possible and obviously accept any new mainteners [1]. For now, I
> will only step back of my activities, no take in charge any new work but
> finish the ones I started. I will resign of my ambassador role soon.
>
> My reasons are diverse. I like the KISS of archlinux, their great
> documentation and  their philosophy in general. Rolling releases and AUR
> seems more than great to me, alongside the governance model (I don't
> like the fedora one, with many instances , groups, leaders...). But, I
> won't deny it, I want to learn how my system really works and to "get my
> hands dirty", to learn things that fedora "kept away" of me.
>
> BUT: I think that Fedora and Archlinux are two great distros, and I will
> keep recommend fedora to new users and advanced users who want a system
> with many packages and features, without getting their hands too dirty
> in administration.
>
> Please keep doing what you are doing. It REALLY matters: help, encourage
> and teach new users. Freedom, First, Features, Friends, always.
>
> Regards,
> Alexandre
>
> [1]: I maintain, in officials fedora repositories:
>
> * adonthell -- A 2D graphical RPG game ( master f26 f25 f24 )
> * amsynth -- A classic synthesizer with dual oscillators ( master f26
> f25 f24 )
> * hyperrogue -- An SDL roguelike in a non-euclidean world ( master f26
> f25 f24 )
> * opencity -- Full 3D city simulator game project ( master f26 f25 f24 )
> * rogue -- The original graphical adventure game ( master f26 f25 f24 )
> * tinyxpath -- Small XPath syntax decoder ( master f26 f25 f24 )
> * wastesedge -- Official game package for Adonthell ( master f26 f25 f24 )
>
> In rpmfusion (free):
>
> * openmw -- Unofficial open source engine re-implementation of the game
> Morrowind ( master f26 f25 f24 )
>
> Feel free to ask for ownership.

Hi,
I can take over amsynth, my fas account is tartina.
Do I have to file a ticket in pagure?

Ciao
Guido
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ardour5 build failures in rawhide

[Guido Aulisi]

Hi,
recently ardour5 failed to build in rawhide, I think because glibmm
now requires c++14.

I patched the spec at the beginning this way and it works on my pc:

# glibmm needs --std=c++11 for F-23..F-27 and --std=c++14 for F-28 and later
# --std=c++14 is the default for F-28
%if !0%{?fedora}%{?rhel} || ( 0%{?fedora} >= 23 && 0%{?fedora} < 28 )
|| 0%{?rhel} >= 8
%bcond_without cxx11
%else
%bcond_with cxx11
%endif

But I think we should remove all c++ explicit standard selection and
let the compiler use its default, which should work for every fedora
version (I hope).

What do you think about it?

Nils, please let me know your opinion when you have time.

Thanks

Guido Aulisi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Guido Aulisi]

I'm still using some old 32 bit physical servers with Fedora, and they
still work well!
So I would like to have a 32 bit kernel for some other releases, maybe
f28 if possible.

Guido

2017-07-12 2:18 GMT+02:00 Solomon Peachy :
> On Wed, Jul 12, 2017 at 12:00:05AM +0200, Zdenek Kabelac wrote:
>> The question is - why - certainly not  because CPU got less powerfull that
>
> No, it's because modern desktop environments are much more heavily
> GPU-dependent to the point where the (very lousy) onboard GPUs on
> 2005-era laptops are simply not able to keep up -- or force
> non-optimized software-based rendering fallbacks.
>
>> it's been 10-12 years back -  but  when   gnome clock  needs  30MB,
>> and rendering of html pages  often takes over 100MB - and nobody cares about
>> any performance regression since  new shiny i7 is so fast to 'mask' all
>> programmers faults and 32GB or RAM also needs some usage
>
> The real limitation for that old 2005-era laptop is its ability to hold
> enough memory to allow someone to fire up Chrome and hit facebook.com
> without hitting swap.  The pokey GPU will be the the other problem.
>
> But that's not due to programmers getting sloppy or not caring about
> resource usage -- it's due to the realities of modern computing.  A
> modern web browser is certianly "more bloated" than older ones, but that
> bloat buys you many more capabilities than before, not to mention
> javascript engines that are an order of magnitude faster than the ones
> of a decade ago.  Modern web sites require those capabilities and the
> greatly increased system resources (CPU, GPU, and Memory) those entail.
>
>  - Solomon
> --
> Solomon Peachy pizza at shaftnet dot org
> Delray Beach, FL  ^^ (email/xmpp) ^^
> Quidquid latine dictum sit, altum videtur.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Comaintaining of lv2-x42-plugins

[Guido Aulisi]

Hi,
I'd like to help update lv2-x42-plugins to the latest upstream version,
so I asked for acls on pkgdb.
As pkgdb is near EOL, I'm also writing here...

Guido Aulisi

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

Upgrade of Ardour to latest version

[Guido Aulisi]

I'm going to upgrade ardour5 to the latest upstream version 5.10,
starting with rawhide, f26, f25 and f24.

Guido Aulisi

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

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Guido Aulisi]

Il giorno mar, 13/06/2017 alle 19.12 +0200, Till Maas ha scritto:
> On Tue, Jun 13, 2017 at 11:14:37AM +0200, Guido Aulisi wrote:
> 
> > This is going to break all audio applications in Fedora, because
> > jack-
> > audio-connection-kit is affected, but I cannot see a dependency on
> > efl,
> > I've got jack installed with no efl and only libffado, if I try to
> > install ffado I get no efl, so I cannot understand where the
> > dependency
> > on efl is.
> 
> The subpackage dbus-c++-ecore of dbus-c++ depends on libefl.so.1 and
> libffado depends on dbus-c++. However, I understood that efl is being
> fixed with the next stable push so you probably do not have to worry
> about this one.

This I can't understand, libffado depends on dbus-c++, but dbus-c++
itself does not depend on libefl.so.1, only its subpackage dbus-c++-
ecore. So a dependency on a subpackage is affecting the entire package,
is this true? It looks strange to me, but maybe I'm wrong.
I know efl is being fixed, so I'm really not worried about this issue,
only a little bit curious about dependencies.

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

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Guido Aulisi]

Il giorno mar, 13/06/2017 alle 11.11 +0100, Peter Robinson ha scritto:
> I'm not sure how all those people can be co-maintainers of efl. I'm
> not sure how that's meant to be interpreted but given some of the
> other responses I think this script as bit rotted some what.
> 
> Peter

I think these are (co)maintainers of other packages affected by efl
problems, I am one of these, but IMHO dependencies are not well
computed here.

> > Affected (co)maintainers
> > alexl: efl
> > ankursinha: lldb, efl
> > atkac: efl
> > bpepple: efl
> > bsjones: efl
> > caillon: efl
> > caolanm: efl
> > chkr: efl, banshee-community-extensions
> > cicku: efl
> > company: lldb, efl
> > cwickert: efl
> > danfruehauf: efl
> > dchen: efl
> > design-sw: efl
> > drago01: efl
> > dtimms: efl
> > dwrobel: efl
> > filiperosset: efl
> > greghellings: efl
> > group::gnome-sig: libsmbios, efl
> > hobbes1069: efl
> > ignatenkobrain: lldb, efl, getdp
> > imntreal: efl
> > jankratochvil: lldb, efl
> > jjames: efl
> > jkraehemann: efl
> > jnovy: efl
> > john2583: efl
> > johnp: efl
> > jvlomax: efl
> > jwrdegoede: efl
> > kkofler: efl
> > konradm: lldb, efl
> > kvolny: efl
> > kwizart: efl
> > lennart: efl
> > limb: lldb, efl
> > lkundrak: efl
> > lorenzosu: efl
> > luya: YafaRay, efl
> > mbarnes: python-etcd, efl, etcd
> > mbooth: efl
> > mcrha: efl
> > moezroy: efl
> > mschwendt: efl
> > mtasaka: OmegaT, efl, sslogger
> > muep: efl
> > nando: efl
> > nobrakal: efl
> > nonamedotc: efl
> > nphilipp: efl
> > nucleo: efl
> > oget: efl
> > pbrobinson: efl
> > perex: efl
> > pfj: efl
> > pwalter: lldb, efl
> > rakesh: efl
> > rdieter: efl, kf5-libkface
> > rhughes: libsmbios, efl
> > roma: efl
> > rrankin: efl
> > rstrode: efl
> > s4504kr: efl
> > salimma: efl
> > sereinit: efl
> > sergiomb: efl
> > slaanesh: YafaRay, efl, mesos
> > smani: efl, getdp
> > spot: python-repoze-who-plugins-sa, AcetoneISO, efl
> > ssp: efl
> > tartina: efl
> > thm: efl
> > thomasj: efl
> > tikro: efl
> > uraeus: efl
> > verdurin: efl
> > vicodan: libsmbios, efl, python-repoze-who-plugins-sa
> > wtaymans: lldb, efl
> > xiphmont: efl
> > zbyszek: efl


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

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Guido Aulisi]

Il giorno lun, 12/06/2017 alle 22.38 +, t...@fedoraproject.org ha
scritto:
> In preparation for the Final Freeze on 2017-06-27 Release
> Engineering will retire all packages in Branched with broken
> dependencies and
> all packages depending on these. If you get this e-mail directly this
> affects
> at least one of your packages. Please fix the broken dependency as
> soon as
> possible.  If you know for sure that the package should be retired,
> please do
> so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
This is going to break all audio applications in Fedora, because jack-
audio-connection-kit is affected, but I cannot see a dependency on efl,
I've got jack installed with no efl and only libffado, if I try to
install ffado I get no efl, so I cannot understand where the dependency
on efl is.

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

Possible patch to fix Ardour appdata

[Guido Aulisi]

Hi,
Nils in your pull request to fix Ardour appdata
https://github.com/Ardour/ardour/pull/261
there's a comment by x42 that says it would break bundle-scripts,
'revision' is expected in the 2nd line.

So I modified your first commit to let revision stay in the 2nd line,
as Paul suggested in the PR.

This patch should be applied after your
commit 0f1915a7162a0f64d01
AppData release tags need a date to be valid

I'm attaching my patch, maybe this could help accept the PR

Bye
Guido AulisiFrom bc6e617d1df5587d54bce40a7ac1e2f9e72896fe Mon Sep 17 00:00:00 2001
From: Guido Aulisi <guido.aul...@gmail.com>
Date: Sun, 21 May 2017 12:31:12 +0200
Subject: [PATCH] AppData: 'revision' in revision.cc is expected in the 2nd
 line

---
 wscript | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/wscript b/wscript
index ed10c32..434ab2a 100644
--- a/wscript
+++ b/wscript
@@ -165,10 +165,12 @@ def fetch_tarball_revision_date():
 with open('libs/ardour/revision.cc') as f:
 content = f.readlines()
 remove_punctuation_map = dict((ord(char), None) for char in '";')
-raw_line_tokens = content[1].decode('utf-8').strip().split(' ')
 
+raw_line_tokens = content[1].decode('utf-8').strip().split(' ')
 rev = raw_line_tokens[7].translate(remove_punctuation_map)
-date = raw_line_tokens[12].translate(remove_punctuation_map)
+
+raw_line_tokens = content[2].decode('utf-8').strip().split(' ')
+date = raw_line_tokens[4].translate(remove_punctuation_map)
 
 return rev, date
 
@@ -287,8 +289,7 @@ def create_stored_revision():
 #
 text =  '#include "ardour/revision.h"\n'
 text += (
-'namespace ARDOUR { '
-'const char* revision = \"%s\"; '
+'namespace ARDOUR { const char* revision = \"%s\";\n'
 'const char* date = \"%s\"; }\n'
 ) % (rev, rev_date)
 print('Writing revision info to libs/ardour/revision.cc using ' + rev + ', ' + rev_date)
-- 
2.9.4



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

Re: Update Ardour to 5.9.0

[Guido Aulisi]

Il giorno ven, 19/05/2017 alle 19.13 +0200, Nils Philippsen ha scritto:
> On Fri, 2017-05-19 at 19:06 +0200, Nils Philippsen wrote:
> > Hi Guido,
> > 
> > On Fri, 2017-05-19 at 18:58 +0200, Guido Aulisi wrote:
> > > Hi,
> > > I'm updating Ardour 5 to the latest 5.9.0 version in rawhide.
> > > 
> > > Nils, I will wait for your review to update f26 and f25, too.
> > 
> > Have you recreated libs/ardour/revision.cc? This is necessary still
> > because upstream hasn't integrated the respective patch yet.
> 
> I've attached the file because it's a little cumbersome to do:
> 
> - check out the exact release ("5.9" tag in our case)
> - cherry-pick the changes without committing them
> - run ./waf ... until the file gets updated ;)
I edited the original patch and it's the same as your file, only the
diff header dates are different.
I think "./waf tarball" is enough to build revision.cc.
I hope the patch will be accepted upstream
5.9 is now building in rawhide. 
> Nils

Bye
Guido
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Update Ardour to 5.9.0

[Guido Aulisi]

Hi,
I'm updating Ardour 5 to the latest 5.9.0 version in rawhide.

Nils, I will wait for your review to update f26 and f25, too.

Guido Aulisi
fas account: tartina

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