Re: dav1d SONAME bump
On Sat, Dec 5, 2020, 6:22 AM Robert-André Mauchin wrote: > Hello, > > I plan on updating dav1d to 0.8.0 next week. This triggers a soname bump > (libdav1d.so.5). > That's actually perfect, I need to put together new Cinelerra-GG packages anyway, I already have the 2020-10 release built locally and basically ready to go. So what I'll do is put together the new spec files and sources, commit them, but then NOT trigger a build. After dav1d gets bumped, then I can submit builds to include the updated dav1d version. I had been waiting on the next monthly release, since 2020-11 would normally have been out December 1. But I just learned the sad news that Bill Morrow, aka "GoodGuy" (the "GG" in Cinelerra-GG) was killed last month in a cycling accident.[1] While the Cinelerra-GG project members and user community have expressed interest in continuing the project and eventually resuming the development / release cycle, GoodGuy was for the most part the solo development lead for the project. The 2020-10 release I'll be pushing soon will be the last Cinelerra-GG monthly release for at least the immediate future. [1]: http://libregraphicsworld.org/blog/entry/rip-bill-morrow > ___ 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: ntp replacement (Self-Contained Change)
On Fri, Dec 04, 2020 at 01:38:02AM +0100, Björn Persson wrote: > > == Upgrade/compatibility impact == > > > > The `ntp` package is replaced automatically on upgrade to Fedora 34. > > The configuration file ''/etc/ntp.conf'' is saved as to > > ''/etc/ntp.conf.rpmsave'' and it needs to be renamed to > > ''/etc/ntp.conf'' to be used by `ntpsec`. Otherwise, `ntpsec` will > > fall back to the default configuration in ''/etc/ntp.d'' using the > > ''pool.ntp.org'' servers. > > > > The `ntpd` service is disabled after the upgrade and needs to be enabled > > again. > > That's not so nice to those users who can use NTPsec as a drop-in > replacement. For them it would be better to keep the configuration file > and have the service enabled if it was enabled before the upgrade. Good point. What would be the best way to do that in the ntpsec package? Trigger on ntp? -- Miroslav Lichvar ___ 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 Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
> Am 04.12.2020 um 20:33 schrieb Matthew Miller : > >> ... >> Just in case it is indeed considered useful and desirable I could >> contribute various Fedora Server related/specific documentations and >> how-to's, e.g. an annotated step-by-step guide to setup a basic server >> which can get extended for various purposes, how to set up a Postgres >> server on top of a basic server, an infrastructure for vm’s and containers >> (including scripts and ansible templates), troubleshooting guides, and >> other topics like that (mostly practical but always together with >> preliminary strategic considerations). Just let me know. > > > Absolutely! A functioning Working Group needs people interested in and doing > these kinds of things too, not just package maintenance. So if you're > interested, you'd absolutely be welcome in a re-constituted Fedora Server > WG. Well, where should we discuss further proceedings? Is it this generic devel list, is it ser...@lists.fedoraproject.org? Another one? First of all we need content, of course, but we also need some planning beforehand. - How to set things in motion, - where we want which documentation be published (under Releases, Quick Doc, dedicated area in https://docs.fedoraproject.org/en-US/docs/, or wiki entries at https://fedoraproject.org/wiki/Fedora_Project_Wiki?rd=Fedora_Project_Wiki/en), - where can drafts be discussed before publication, - contact with the Doc project to name but a few. > -- > Matthew Miller > > Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: ntp replacement (Self-Contained Change)
On Mon, Dec 07, 2020 at 11:05:56AM +0100, Miroslav Lichvar wrote: > On Fri, Dec 04, 2020 at 01:38:02AM +0100, Björn Persson wrote: > > > == Upgrade/compatibility impact == > > > > > > The `ntp` package is replaced automatically on upgrade to Fedora 34. > > > The configuration file ''/etc/ntp.conf'' is saved as to > > > ''/etc/ntp.conf.rpmsave'' and it needs to be renamed to > > > ''/etc/ntp.conf'' to be used by `ntpsec`. Otherwise, `ntpsec` will > > > fall back to the default configuration in ''/etc/ntp.d'' using the > > > ''pool.ntp.org'' servers. > > > > > > The `ntpd` service is disabled after the upgrade and needs to be enabled > > > again. > > > > That's not so nice to those users who can use NTPsec as a drop-in > > replacement. For them it would be better to keep the configuration file > > and have the service enabled if it was enabled before the upgrade. > > Good point. What would be the best way to do that in the ntpsec > package? Trigger on ntp? Since the plan it to Obsolete the old package, I think you should trigger on the removal of it: %triggerun ntp <= ... # copy service enablement from the old name to the new name if systemctl is-enabled -q ntpd 2>/dev/null; then systemctl enable ntpsecd # if the name is different... fi ... Zbyszek ___ 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: ntp replacement (Self-Contained Change)
On Mon, Dec 07, 2020 at 10:47:31AM +, Zbigniew Jędrzejewski-Szmek wrote: > Since the plan it to Obsolete the old package, I think you should trigger > on the removal of it: > %triggerun ntp <= ... > > # copy service enablement from the old name to the new name > if systemctl is-enabled -q ntpd 2>/dev/null; then > systemctl enable ntpsecd # if the name is different... > fi More magic is needed. The service name is the same (ntpd). The ntpsec post disables the service before the triggerun runs. I suspect the original state needs to be captured first in a triggerprein or pre scriptlet. -- Miroslav Lichvar ___ 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: virt-backup "The PDC branch already exists"
Obviously no humans are paying attention to the ticket so can someone help me? I requested a repo for virt-backup but the automated response is "The PDC branch already exists ", however, I can't not find a previous Review Request for this nor can I clone the repo... https://pagure.io/releng/fedora-scm-requests/issue/31197 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
Sponsorship for non-maintainers
Hi all, I am facing a bit of a pickle and I would like to discuss this out in the open here. Please keep and open mind while reading. There has been an effort to open-source some of our tests that we have in Red Hat and we decided to place them in the tests/* namespace in Fedora dist-git[1]. Now, our team has some 10 maintainers and we own almost 200 packages in RHEL8(way more than that in Fedora). For all these packages we have only three people in the QE team to test them. So here is the problem: Let us assume, that we create a repository for each component in the tests/* namespace. Now we need to assign access to QE member to these repositories. It would make sense to create a group that would include our package maintainers as well as our QE colleagues. This would help a lot when it comes to stuff changes for instance. As discussed here[2], the only problem here is "once a group is created, it can be given commit access to all projects in the tests/ namespace, but also to any project in the rpms/ namespace or the modules/ namespace and everyone who is committing to these namespaces must be in the packager groups. Thus the requirement for pkgdb group to require the packager membership." But our colleagues from QE don't have sponsorship and therefore are not in the packager group. There are those in RH who said that they would give them sponsorship for these purposes if it is required but I am not sure if that is the right way to do this and I would like to discuss it here. Any input on this is appreciated. Thanks and regards, Michal -- [1] https://src.fedoraproject.org/projects/tests/* [2] https://pagure.io/fedora-infrastructure/issue/9490 -- Michal Ruprich Software Engineer Email: mrupr...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00, 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://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
Distro Devroom @ FOSDEM: CfP open
Hi everyone! The CfP for the Distro Devroom at FOSDEM 2021 is open through 20 December. This is a great venue to talk about the issues and work of distro creation. See the Community Blog post[1] for topic ideas or submit your proposal in the CfP portal[2]. The deadline is 20 December at 2359 UTC. [1] https://communityblog.fedoraproject.org/distro-devroom-fosdem-cfp-open/ [2] https://penta.fosdem.org/submission/FOSDEM21 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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: New package: virt-backup "The PDC branch already exists"
On 12/7/20 3:39 PM, Richard Shaw wrote: Obviously no humans are paying attention to the ticket so can someone help me? Unfortunately, no humans are :( I recommend opening an issue at https://pagure.io/releng/issues when the automated "conversation" at https://pagure.io/releng/fedora-scm-requests leads nowhere. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Sponsorship for non-maintainers
On 12/7/20 3:42 PM, Michal Ruprich wrote: Hi all, I am facing a bit of a pickle and I would like to discuss this out in the open here. Please keep and open mind while reading. There has been an effort to open-source some of our tests that we have in Red Hat and we decided to place them in the tests/* namespace in Fedora dist-git[1]. Now, our team has some 10 maintainers and we own almost 200 packages in RHEL8(way more than that in Fedora). For all these packages we have only three people in the QE team to test them. So here is the problem: Let us assume, that we create a repository for each component in the tests/* namespace. Now we need to assign access to QE member to these repositories. It would make sense to create a group that would include our package maintainers as well as our QE colleagues. This would help a lot when it comes to stuff changes for instance. As discussed here[2], the only problem here is "once a group is created, it can be given commit access to all projects in the tests/ namespace, but also to any project in the rpms/ namespace or the modules/ namespace and everyone who is committing to these namespaces must be in the packager groups. Thus the requirement for pkgdb group to require the packager membership." But our colleagues from QE don't have sponsorship and therefore are not in the packager group. There are those in RH who said that they would give them sponsorship for these purposes if it is required but I am not sure if that is the right way to do this and I would like to discuss it here. Any input on this is appreciated. Thanks and regards, With rpm packages, co-maintainers can sponsor people into the packager group: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer I believe this procedure works quite fine for tests as well. "They [existing maintainers] agree to be responsible for mentoring you [the new maintainer] in how to follow the Fedora Packaging Guidelines and how to use the tools Fedora provides for building and pushing packages but need someone to sponsor you since they are not sponsors themselves." Obviously, here they maintain you about the test things instead, but that's a technicality. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: New package: virt-backup "The PDC branch already exists"
‐‐‐ Original Message ‐‐‐ On Monday, December 7, 2020 9:17 AM, Miro Hrončok wrote: > On 12/7/20 3:39 PM, Richard Shaw wrote: > > > Obviously no humans are paying attention to the ticket so can someone help > > me? > > Unfortunately, no humans are :( Sort of. :) I @ed pingou and mohan in the ticket. The issue here is that when a human runs the script to process the request queue, it doesn't display the "conversation". I would definitely recommend Miro's suggestion. > > I recommend opening an issue at https://pagure.io/releng/issues when the > automated "conversation" at https://pagure.io/releng/fedora-scm-requests leads > nowhere. > > > - > > Miro Hrončok > > - > > Phone: +420777974800 > IRC: mhroncok > > 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: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction: Sohan Kunkerkar
Hi Folks, Good day! I hope everyone is keeping well in these unprecedented and difficult times. My name is Sohan Kunkerkar and I'm a software engineer at Red Hat Inc helping to develop and maintain a container-focused operating system. Before working on Fedora-CoreOS, I was involved in efforts to building the foundational aspects of the k8s cluster federation-v2 (KubeFed) prototype. I've been a Fedora user for the past 5 years and am looking forward to contributing to this ecosystem. I'm passionate about large-scale distributed systems, cloud-native infrastructure, and container tools. In my free time, I try to explore the open-source community with their recent concepts and solutions and try to contribute to it. Regarding packaging, I would like to apply for co-maintainership of the following packages: 1. https://src.fedoraproject.org/rpms/rust-coreos-installer 2. https://src.fedoraproject.org/rpms/fedora-coreos-config-transpiler 3. https://src.fedoraproject.org/rpms/ignition 4. https://src.fedoraproject.org/rpms/rust-afterburn Thanks! ___ 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 Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Fri, Dec 4, 2020, 3:25 PM Matthew Miller wrote: > On Fri, Dec 04, 2020 at 02:16:23PM -0800, Japheth Cleaver wrote: > > be a better-engineered and tested option. But as time goes on and > > the next EL release isn't either isn't announced or isn't stable > > enough to rely on, Fedora Server probably sees more use as a > > quasi-stable release base.. This fills a real need when your users > > are absolutely clamoring for things that aren't likely to be > > backported into the stable EL release and you don't want to have to > > send them into Ubuntu/Debian land (or have them grab an > > un-administered container off the shelf). > > Yeah, we may have an opportunity to do this better with CentOS Stream. > Starting with RHEL 8, there's no more "next EL isn't announced" -- instead, > they're every three years. So, we know when Fedora ELN is going to flow > into > CentOS Stream and from there to RHEL. We could actually position and label > each Fedora Server release by where it fits on the wave of that cadence. > It's too early to say that this hypothetical workflow is a replacement for Fedora. Things still show up in RHEL 8 ahead of CentOS Stream. A strong Fedora Server edition means a strong RHEL Server. - Ken > ___ 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 proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)
FESCo's approval[1] of this proposal was contingent on splitting it into two phases. For Fedora 34, nscd will be deprecated[2]. For Fedora 35, nscd will be removed[3]. [1] https://pagure.io/fesco/issue/2501#comment-704653 [2] https://fedoraproject.org/wiki/Changes/DeprecateNSCD [3] https://fedoraproject.org/wiki/Changes/RemoveNSCD -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 34 Change: Ignore Anaconda kernel boot parameters without 'inst.' prefix (System-Wide change)
https://fedoraproject.org/wiki/Changes/Ignore_Anaconda_kernel_boot_parameters_without_inst_prefix == Summary == Right now Anaconda allows usage of boot options both with the 'inst' prefix (inst.stage2=) and without (stage2=). We would like to ignore the use of Anaconda kernel boot parameters which do not contain the 'inst.' prefix. == Owner == * Name: [[User:jkonecny| Jiří Konečný]] * Email: == Detailed Description == Anaconda allows you to use kernel boot parameters with and without the 'inst.' prefix right now (e.g. inst.repo= / repo=). However, specifying boot parameters without the 'inst' prefix has not been recommended for years and has been deprecated since Fedora 33. We (Anaconda team) would like to make it an official requirement now that users must specify the 'inst.' prefix all the time. The reason for this is frequent parameter conflicts with other projects. We already had a few issues with conflicts in the past, such as if the user ran an installation with `debug`. In that case the installation boot would enable debug mode for the kernel and also for Anaconda which is probably not what the user intended. Another reason is to make it readable at first glance what belongs to Dracut (rd.), kernel (no prefix) or Anaconda (inst.). == Feedback == We have sent mail about doing the deprecation on Fedora 33. The only issue there was why the prefix is 'inst.' and not 'anaconda.'. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/43LKTJOUO5TB7LGFWPRNXOYLEQF3KLGG/#ENTHA45Y6VO45FAD4ULPSHCTOXPML3PA == Benefit to Fedora == This change should make crystal clear what kernel boot parameters are processed by the Anaconda installer. It will also avoid conflicts with other kernel boot parameters. == Scope == * Proposal owners: Remove support to process arguments without the 'inst.' prefix and require the 'inst.' prefix for kernel boot parameters consumed by Anaconda. * Other developers: All configurations using the not-recommended solution without prefix will have to change the invocation of the kernel boot options consumed by Anaconda. These users are already warned since Fedora 33 after boot. This should not be a problem for ISOs we ship because they already use the recommended 'inst.' prefix everywhere. However, it will probably touch some custom PXE configurations and other custom ISO configurations which are prone to this, because users often want to save typing and not explicitly write the 'inst.' prefix. Fortunately, most of these configuration changes shouldn't be that hard to change. * Release engineering: [https://pagure.io/releng/issue/9889 #9889] * Policies and guidelines: This should not be required. All the documentation should use the recommended 'inst.' prefix already. * Trademark approval: No (not needed for this Change) * Alignment with Objectives: No == Upgrade/compatibility impact == If your custom infra configuration is not updated then new Fedora installations could not install correctly. Most probably the ISO will not boot (use of 'stage2=') or your repositories won't be used (use of 'repo='). == How To Test == # You need a Virtual Machine and ISO for testing. # Boot the installation using the ISO and try Anaconda specific kernel boot parameters. See here to find out the list https://anaconda-installer.readthedocs.io/en/latest/boot-options.html. # Parameters without the prefix should be ignored and with the prefix should be used. == User Experience == Users of Fedora official ISOs should not be impacted because all the Fedora official ISOs should already use the recommended prefix. == Dependencies == Don't know about any packages impacted by this change. == Contingency Plan == * Contingency mechanism: The Anaconda team will revert code changes and get back support for boot parameters without the 'inst.' prefix. * Contingency deadline: Final Freeze * Blocks release? No * Blocks product? This won't require changes for any specific product. == Documentation == I don't think we need to document this change other than in Release Notes. As mentioned before, the solution without 'inst.' prefix has not been recommended for years and it should not be used anywhere in the official documentation. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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
Introduction
Hi, My name is Robin Opletal, I am from the Czech Republic and online I tend to go under the name of "fourstepper". I would like to help out with maintaining packages of interest for Fedora, currently, I am interested in getting aerc, the terminal e-mail client packaged for Fedora. (https://git.sr.ht/~sircmpwn/aerc) For Aerc, I have so far created a COPR repository, which currently lives here: https://copr.fedorainfracloud.org/coprs/fourstepper/aerc/builds/ I would also be thrilled to help with other packages if needed and learn and help with the Fedora's package build system. ___ 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: btrfs: nodatacow and snapshots
El dom, 6 dic 2020 a las 22:52, Chris Murphy () escribió: > On Sun, Dec 6, 2020 at 3:54 PM Sergio Belkin wrote: > > > > Hi, > > Let's say that I have 2 subvolumes for both / and /home. What happen > with a snapshot of /home if I run before : > > chattr +C /home/jdoe/VMs ? > > If /home/jdoe/VMs is a directory, then it and its contents are > included in the snapshot. And it means nodatacow extents have become > shared extents. Writes to shared extents are always cow, even if > marked as nocow. So the initial VM "overwrite" to a shared extent will > be cow to a new extent that is exclusive, not shared. Subsequent > writes to that same exclusive extent will be nocow, i.e. an overwrite. > > This same principle applies to reflink copies of any file, whether on > Btrfs or XFS. A reflink copy also causes extents to become shared > extents. > > My suggestion is to put the VM images in their own subvolume. i.e. > from ~/ just do: > > btrfs sub create VMs > > Since Btrfs snapshots are not recursive [1] and instead stop at > subvolume boundaries, a snapshot of ~/ will not snapshot ~/VMs. > > [1] https://github.com/kdave/btrfs-progs/tree/master/libbtrfsutil > libbtrfsutil provies a C API and python bindings making it possible to > do recursive snapshot creation and deletion; but this is not exposed > in the user space tools for a number of reasons, mainly it's > potentially confusing and risky since btrfs subvolumes and snapshots > can be created anywhere without any meaningful limits beyond what the > user institutes. Another advantage of libbtrfsutil is it provides an > _fd variant of subvolume/snapshot creation and deletion, meaning there > doesn't need to be a "line of sight" path to the source or destination > via the mounted file system. Ergo, in effect creating "hidden" > subvolumes and snapshots; "hidden" as in they're not in the normal > mounted file system path. A user can of course always mount the > top-level of the file system and see all such subvolumes. > > > -- > Chris Murphy > Thanks Chris, nice explanation -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.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: Self Introduction: Sohan Kunkerkar
On Mon, Dec 07, 2020 at 03:41:23PM -, Sohan Kunkerkar wrote: > My name is Sohan Kunkerkar and I'm a software engineer at Red Hat Inc > helping to develop and maintain a container-focused operating system. > Before working on Fedora-CoreOS, I was involved in efforts to building the Hi! Welcome! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Sat, Dec 5, 2020 at 7:33 am, James Szinger wrote: Undelivered -devel packages and modularity are killer anti-features of EL 8—it is way too hard to build the software I need. Honestly I don't think modularity is a serious problem for end users. Missing -devel packages is unbelievably frustrating, though. And EPEL just doesn't contain as much as Fedora does, in general. So for personal servers... well, I've never seen Fedora Server broken by automatic updates. I don't think I would use Fedora Server for critical business infrastructure, but it works well enough for my personal needs. The odds of encountering problems with Fedora are simply way lower than the odds of discovering that EPEL lacks something that I want, or an essential -devel package that doesn't exist. Michael ___ 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 Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Mon, Dec 07, 2020 at 11:41:01AM +0100, p...@uni-bremen.de wrote: > Well, where should we discuss further proceedings? Is it this generic > devel list, is it ser...@lists.fedoraproject.org? Another one? Yes, let's take it to that list. Everyone interested, join us over there. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The future of Fedora Server (was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change))
On Mon, Dec 07, 2020 at 08:44:37AM -0700, Ken Dreyer wrote: > It's too early to say that this hypothetical workflow is a replacement for > Fedora. Things still show up in RHEL 8 ahead of CentOS Stream. I don't suggest that it's a replacement, but it can be complementary. > > A strong Fedora Server edition means a strong RHEL Server. Absolutely! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide Repo needs downgradeable packages
On Fri, Dec 4, 2020 at 4:12 PM Marius Schwarz wrote: > > > Hi, > > as you may have heared, Fedora is now running on Pinephone and other devices, > that need bleeding edge versions to function. > > Status of Fedora Pine as of 15:15 CET > > Cams now working, but app needs rework > Mobile INET working > WIFI working > Touch working > SMS working > GPS working > Calls partly, "calls app" does not connect to pulseaudio. > Headphones ( sort of ) > Mali400 GPU support working ( MPV rulez ) > > and with Gnome(38) instead of Phosh.. no window problems! Big Thanks to > nikhiljha and his copr repo. > > O== my request > > In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell > 40~alpha ) caused a lot of bugs and needed to be downgraded directly from > koji, > by first finding & downloading them with wget ( because of the slow wifi and > dependency checks, direct http links work ofcourse ), and later downgraded > with > dnf, which is so to speak, a pain in the ass. Of course, the best way to > handle it would be, if the os compenents came from stable repos, so that > these problems do not happen. But as i said, bleeding edge is needed atm. > > Is it possible to keep at least the last version of a package around in > rawhide repo, to make dnf downgrade work? That would ease a lot of this pain. > > I know that there is a native koji tool to handle rawhide, but i must say, > that won't work in most cases. Let me explain: > > Pine has announced to open stores in the US and Canada, because of the huge > amount of requests for a pinephone. As it looks, this phone, as cheap as it > compontants are, fills a gap of some kind. Therefor we will have much more > user using it, and (i hope i can help with it) will use Fedora with > Gnome-Shell. > Phosh is more like Android, it has it charm, but tbh I, and people I showned > it to, love they way gnome-shell handles stuff. > > We "may" get them to downgrade stuff with dnf, but that needs to be as simple > as it could. I'm wondering, wouldn't this scenario be a prime application of an OSTree based system like Silverblue? It would give you exactly what you want, being able to revert to the previous (working) version if the new one breaks something. Even Android does something like this nowadays. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rawhide Repo needs downgradeable packages
On Mon, 2020-12-07 at 17:45 +0100, Fabio Valentini wrote: > On Fri, Dec 4, 2020 at 4:12 PM Marius Schwarz wrote: > > > > Hi, > > > > as you may have heared, Fedora is now running on Pinephone and other > > devices, that need bleeding edge versions to > > function. > > > > Status of Fedora Pine as of 15:15 CET > > > > Cams now working, but app needs rework > > Mobile INET working > > WIFI working > > Touch working > > SMS working > > GPS working > > Calls partly, "calls app" does not connect to pulseaudio. > > Headphones ( sort of ) > > Mali400 GPU support working ( MPV rulez ) > > > > and with Gnome(38) instead of Phosh.. no window problems! Big Thanks to > > nikhiljha and his copr repo. > > > > O== my request > > > > In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell > > 40~alpha ) caused a lot of bugs and needed to > > be downgraded directly from koji, > > by first finding & downloading them with wget ( because of the slow wifi > > and dependency checks, direct http links > > work ofcourse ), and later downgraded with > > dnf, which is so to speak, a pain in the ass. Of course, the best way to > > handle it would be, if the os compenents > > came from stable repos, so that these problems do not happen. But as i > > said, bleeding edge is needed atm. > > > > Is it possible to keep at least the last version of a package around in > > rawhide repo, to make dnf downgrade work? > > That would ease a lot of this pain. > > > > I know that there is a native koji tool to handle rawhide, but i must say, > > that won't work in most cases. Let me > > explain: > > > > Pine has announced to open stores in the US and Canada, because of the huge > > amount of requests for a pinephone. As > > it looks, this phone, as cheap as it compontants are, fills a gap of some > > kind. Therefor we will have much more user > > using it, and (i hope i can help with it) will use Fedora with Gnome-Shell. > > Phosh is more like Android, it has it charm, but tbh I, and people I > > showned it to, love they way gnome-shell > > handles stuff. > > > > We "may" get them to downgrade stuff with dnf, but that needs to be as > > simple as it could. > > I'm wondering, wouldn't this scenario be a prime application of an > OSTree based system like Silverblue? > It would give you exactly what you want, being able to revert to the > previous (working) version if the new one breaks something. Even > Android does something like this nowadays. Yeah, it really seems to me that OSTree managed system with apps in Flatpaks on top could work very well on an Linux mobile device. It could actually be much better than what's used in Android at the moment as I'm not sure they really do diff updates or how very well & you usually replace one system image by another one. So there is no way easy way to revert the update & the device might need a reflash if the update process is interrupted while the new system image is being created (due to a crash or running out of battery). With OSTree one could easily have multiple update states available (sable, cutting edge, last 3 updates, etc.) and as the new OSTree is created "in the background" without destroiong the current one/s it would be really hard to get the device into such a bad state with OSTree to need a reflash. > > Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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: Rawhide Repo needs downgradeable packages
On Fri, 2020-12-04 at 16:11 +0100, Marius Schwarz wrote: > > > Hi, > > > > as you may have heared, Fedora is now running on Pinephone and other > devices, that need bleeding edge versions to function. Are bleeding edge of all packages needed ? If not I wonder if just budiling what needs to be bleeding edge in a COPR overlay on top of a stable release would work. This would give you a stable base to work on and a lot of control over what goes on top of it, including downgrading packages and applying custom not-yet-upstream patches. You could of course at the same time make sure all the bits and pieces land in Rawhide, so that when you switch your COPR overlay baseline to the next Fedora stable release, less custom package versions are needed. Rinse and repeat until no overlay packages are needed. :) > > > Status of Fedora Pine as of 15:15 CET > > > > Cams now working, but app needs rework > > Mobile INET working > > WIFI working > > Touch working > > SMS working > > GPS working > > Calls partly, "calls app" does not connect to pulseaudio. > > Headphones ( sort of ) > > Mali400 GPU support working ( MPV rulez ) > > > > and with Gnome(38) instead of Phosh.. no window problems! Big > Thanks to nikhiljha and his copr repo. Nice, very good progress! :) I really need to try the latest Fedora image on my Pinephone when I have some time. :) > > > O== my request > > > > In the last 3 days alone several updates ( i.e. bind-libs, > gnome-shell 40~alpha ) caused a lot of bugs and needed to be > downgraded directly from koji, > > by first finding & downloading them with wget ( because of the > slow wifi and dependency checks, direct http links work ofcourse ), > and later downgraded with > > dnf, which is so to speak, a pain in the ass. Of course, the best > way to handle it would be, if the os compenents came from stable > repos, so that these problems do not happen. But as i said, bleeding > edge is needed atm. > > > > Is it possible to keep at least the last version of a package around > in rawhide repo, to make dnf downgrade work? That would ease a lot > of this pain. > > > > I know that there is a native koji tool to handle rawhide, but i > must say, that won't work in most cases. Let me explain: > > > > Pine has announced to open stores in the US and Canada, because of > the huge amount of requests for a pinephone. As it looks, this > phone, as cheap as it compontants are, fills a gap of some kind. > Therefor we will have much more user using it, and (i hope i can > help with it) will use Fedora with Gnome-Shell. > > Phosh is more like Android, it has it charm, but tbh I, and people I > showned it to, love they way gnome-shell handles stuff. > > > > We "may" get them to downgrade stuff with dnf, but that needs to be > as simple as it could. > > > > best regards, > > Marius Schwarz > > > > > > > > ___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
Nothing provides libgnat-10.so()(64bit)
Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit): $ repoquery --repo=rawhide --whatrequires 'libgnat-10.so()(64bit)' GtkAda3-devel-0:2020-1.fc34.x86_64 PragmARC-0:20130728-22.fc33.x86_64 ahven-0:2.7-7.fc33.x86_64 aunit-0:2017-10.fc33.x86_64 aws-0:2019-3.fc33.x86_64 aws-devel-0:2019-3.fc33.x86_64 aws-tools-0:2019-3.fc33.x86_64 florist-0:2017-7.fc33.x86_64 ghdl-0:0.38~dev-9.20200827git4ce9925.fc34.x86_64 ghdl-llvm-0:0.38~dev-9.20200827git4ce9925.fc34.x86_64 ghdl-mcode-0:0.38~dev-9.20200827git4ce9925.fc34.x86_64 gnatcoll-core-0:2018-6.fc33.x86_64 gnatcoll-db-devel-0:2018-7.fc33.x86_64 gnatcoll-gmp-0:2018-7.fc33.x86_64 gnatcoll-iconv-0:2018-7.fc33.x86_64 gnatcoll-postgres-0:2018-7.fc33.x86_64 gnatcoll-readline-0:2018-7.fc33.x86_64 gnatcoll-sql-0:2018-7.fc33.x86_64 gnatcoll-sqlite-0:2018-7.fc33.x86_64 gnatcoll-syslog-0:2018-7.fc33.x86_64 gnatcoll-xref-0:2018-7.fc33.x86_64 matreshka-0:20.1-3.fc33.x86_64 matreshka-amf-0:20.1-3.fc33.x86_64 matreshka-amf-dd-0:20.1-3.fc33.x86_64 matreshka-amf-mofext-0:20.1-3.fc33.x86_64 matreshka-amf-ocl-0:20.1-3.fc33.x86_64 matreshka-amf-uml-0:20.1-3.fc33.x86_64 matreshka-amf-utp-0:20.1-3.fc33.x86_64 matreshka-fastcgi-0:20.1-3.fc33.x86_64 matreshka-servlet-lib-0:20.1-3.fc33.x86_64 matreshka-soap-core-0:20.1-3.fc33.x86_64 matreshka-soap-wsse-0:20.1-3.fc33.x86_64 matreshka-spikedog-api-lib-0:20.1-3.fc33.x86_64 matreshka-spikedog-awsd-0:20.1-3.fc33.x86_64 matreshka-spikedog-core-lib-0:20.1-3.fc33.x86_64 matreshka-sql-core-0:20.1-3.fc33.x86_64 matreshka-sql-mysql-0:20.1-3.fc33.x86_64 matreshka-sql-postgresql-0:20.1-3.fc33.x86_64 matreshka-sql-sqlite-0:20.1-3.fc33.x86_64 matreshka-xml-0:20.1-3.fc33.x86_64 mine_detector-0:6.0-38.fc33.x86_64 plplot-ada-0:5.15.0-22.fc34.x86_64 templates_parser-0:11.8.0-23.fc33.x86_64 templates_parser-tools-0:11.8.0-23.fc33.x86_64 xmlada-0:2019-3.fc33.x86_64 zeromq-ada-0:2.1.0-30.24032011git.fc32.x86_64 zlib-ada-0:1.4-0.26.20120830CVS.fc33.x86_64 But gcc was updated and bumped the soname to 11, hence nothing provides it. Could you please rebuild the affected packages? It would also be really appreciated if side tag was used to coordinate the rebuilds, instead of shipping the update directly. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Nothing provides libgnat-10.so()(64bit)
On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote: > Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit): I'm not a provenpackager, so I'm afraid I can't do that myself. Perhaps the maintainers can just rebuild them themselves? Jakub ___ 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: Mass spec file change: Adding BuildRequires: make
On 11/30/20 2:06 PM, Tom Stellard wrote: Hi, As part of the f34 change request[1] for removing make from the buildroot, I will be doing a mass update of packages[2] to add BuildRequires: make where it is needed. If you are a package maintainer and would prefer to update your packages on your own, please do so before Dec 14, which is when I will begin doing the mass update. Hi, Thanks for all the feedback. It seems like there is consensus now that packages that use %cmake_build and %cmake_install but never invoke make directly should not have to BuildRequire: make, so I've updated my scripts to ignore those packages. I have also eliminated some (but not all) of the false positives that have been reported on the list. I'm still working on getting rid of the rest of them. I've updated the package list now[2] to reflect the %cmake_build change, and I will continue to update this at least once per day to account for package updates in Fedora. There is still a week left before I start the updates, so please continue to give feedback. Thanks, Tom I will be doing the updates in batches, so that if there is a mistake the impact will be limited. Here is the rough schedule of the changes: Dec 14: Update first 50 packages. Dec 16: Next 1000. Dec 18: Next 1000. Jan 4: Next 1000. Jan 5: Next 1000. Jan 6: Next 1000. Jan 7: Next 1000. Jan 8: Rest of packages. The deadline for completing these updates is the start of the f34 mass rebuild (Jan 20). Thanks, Tom [1] https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot [2] https://fedorapeople.org/~tstellar/needs_br_make_packages.txt ___ 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: Nothing provides libgnat-10.so()(64bit)
On 12/7/20 11:07 AM, Jakub Jelinek wrote: > On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote: >> Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit): > I'm not a provenpackager, so I'm afraid I can't do that myself. > Perhaps the maintainers can just rebuild them themselves? And note that some of these are going to require fixes to the packages themselves as the Ada front-end changed and some of them no longer build. IIRC zlib and templates_parser are the most important to get rebuilt and I think those "just work". I'll try to get those rebuilt so that the downstream things have a better chance of working :-) jeff ___ 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: Mass spec file change: Adding BuildRequires: make
On 12/7/20 7:18 PM, Tom Stellard wrote: I've updated the package list now[2] to reflect the %cmake_build change, I see for example libsavitar on the list. https://src.fedoraproject.org/rpms/libsavitar/blob/master/f/libsavitar.spec It only uses %cmake_... macros. Was it indeed updated correctly? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Mass spec file change: Adding BuildRequires: make
On 12/7/20 10:33 AM, Miro Hrončok wrote: On 12/7/20 7:18 PM, Tom Stellard wrote: I've updated the package list now[2] to reflect the %cmake_build change, I see for example libsavitar on the list. https://src.fedoraproject.org/rpms/libsavitar/blob/master/f/libsavitar.spec It only uses %cmake_... macros. Was it indeed updated correctly? I just fixed this now. I had pushed the wrong list earlier today. -Tom ___ 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: %pretrans [package name]
On Thu, Dec 3, 2020 at 4:40 PM Miro Hrončok wrote: > On 12/3/20 6:08 PM, Kevin Kofler via devel wrote: > > Miro Hrončok wrote: > >> Try this (note the -n): > >> > >> %pretrans -n doc-en -p > > > > That would have to be: > > %pretrans -n sagemath-doc-en -p > > because -n takes the full subpackage name, not just the suffix. (That is > > normally the entire point of -n, to allow arbitrary names for subpackages.) > > Oh, right. I've mixed up. Disregard my previous email entirely. Sorry for the silence. $DAYJOB kicked into high gear last week. Okay, I will give this a try today. Thanks for the help, Miro and Kevin! -- Jerry James http://www.jamezone.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: Mass spec file change: Adding BuildRequires: make
On 07.12.2020 19:18, Tom Stellard wrote: I have also eliminated some (but not all) of the false positives that have been reported on the list. I'm still working on getting rid of the rest of them. Please check the purple-plugin_pack package. It uses the meson build system. -- 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
Re: Rawhide Repo needs downgradeable packages
Am 07.12.20 um 18:28 schrieb Martin Kolman: Nice, very good progress! :) I really need to try the latest Fedora image on my Pinephone when I have some time. :) Read the issue tracker on github before you update... you will be surprised ;) Best regards, Marius Schwarz ___ 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
Scala
Scala has been orphaned. I don't do anything with scala personally, but I would like to see jacop stay in Fedora. So I've been poking around to see how hard it would be to rescue scala, as well as move it up to a more recent version. The results of my poking around can be seen here: https://copr.fedorainfracloud.org/coprs/jjames/scala/ The bootstrap build of scala 2.13.4 uses upstream's JARs, but then the second build is done entirely from source with Fedora (and COPR) RPMs. Stuff to do before this can really be built in Fedora: - Figure out if jansi 2.0.1 is backwards compatible with jansi 1.18. If it is not, then we'll have to figure out how to make parallel installable versions of jansi 1.18 and 2.0.1, or else port everything currently using 1.18 to 2.0.1. - Figure out if I built jansi 2.0.1 correctly. There is a shared object inside of the JAR, which I think is not correct. - Figure out if any scala tests can be run and, if so, how. If no tests can be run, then we can omit java-diff-utils and jol, which are only used for the tests. So far as I can tell, the only scala applications currently in Fedora are jacop and scalacheck, and scalacheck has also been orphaned, so I'm not worried about breaking anything with such a big jump in scala versions. If anybody else is interested in scala, please speak up and we can figure out how to meet your goals, too. -- Jerry James http://www.jamezone.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
Deprecate xemacs and neXtaw
It pains me to write this. I have been part of XEmacs upstream for over 20 years [1]. I worked on several features, fixed a lot of bugs [2], and really enjoyed working with the other XEmacs developers. But, as has happened to so many open source projects, the developers slowly trickled away until only a handful of us were left. I personally have only fixed a few bugs now and then since 2014, when I contributed my last feature (SSL/TLS support). Suffice it to say that upstream is all but dead. There are still a few commits now and then, but nothing much is happening. I think it is time, sadly, to start moving towards dropping XEmacs from Fedora. Given the number of XEmacs add-on packages in the repository, I think the first step should be to deprecate XEmacs so that no more are added. I know there are XEmacs users in the audience, because I still get bug reports now and then. How do you XEmacs users feel about this? If everybody is okay with this, I will submit a Change Proposal to deprecate the following packages: xemacs xemacs-packages-base xemacs-packages-extra neXtaw Footnotes: [1] My first commit is dated 1 Dec 2000, but I sent patches upstream prior to that. [2] Some of them were even bugs I hadn't written in the first place! -- Jerry James http://www.jamezone.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
missing devel package for pulseaudio-libs-glib2 aarch64
Hi, i try to rebuild the gnome-settings-daemon for Pinephone and missing a dependency as it looks: # meson --prefix=/usr --sysconfdir=/etc .. ... Determining dependency 'libpulse-mainloop-glib' with pkg-config executable '/usr/bin/pkg-config' PKG_CONFIG_PATH: Called `/usr/bin/pkg-config --modversion libpulse-mainloop-glib` -> 1 CMake binary for MachineChoice.BUILD is not cached None of 'CMAKE' are defined in the environment, not changing global flags. CMake binary missing from cross or native file, or env var undefined. Trying a default CMake fallback at cmake Found CMake: /usr/bin/cmake (3.18.4) None of 'CMAKE_PREFIX_PATH' are defined in the environment, not changing global flags. Extracting basic cmake information Try CMake generator: auto Calling CMake (['/usr/bin/cmake']) in /root/rpmbuild/SOURCES/gnome-settings-daemon-3.38.1/build/meson-private/cmake_libpulse-mainloop-glib with: - "--trace-expand" - "--trace-format=json-v1" - "--no-warn-unused-cli" - "--trace-redirect=cmake_trace.txt" - "-DCMAKE_TOOLCHAIN_FILE=/root/rpmbuild/SOURCES/gnome-settings-daemon-3.38.1/build/meson-private/cmake_libpulse-mainloop-glib/CMakeMesonToolchainFile.cmake" - "." -- Module search paths: ['/', '/opt', '/usr', '/usr/local'] -- CMake root: /usr/share/cmake -- CMake architectures: [] -- CMake lib search paths: ['lib', 'lib32', 'lib64', 'libx32', 'share'] Preliminary CMake check failed. Aborting. Run-time dependency libpulse-mainloop-glib found: NO (tried pkgconfig and cmake) ../meson.build:105:0: ERROR: Dependency "libpulse-mainloop-glib" not found, tried pkgconfig and cmake This should be available in a package "pulseaudio-libs-glib2-devel-??" but it's not found. pulseaudio-libs-glib2-14.0-2.fc34.aarch64 glib2-2.67.0-7.fc34.aarch64 glib2-devel-2.67.0-7.fc34.aarch64 As it looks, it's missing for any architecture. 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
Fedora 34 Change: Stratis 2.3.0 (Self-Contained Change)
https://fedoraproject.org/wiki/Changes/Stratis_2.3.0 == Summary == Stratis 2.3.0 adds additional flexibility to its encryption support via Clevis. == Owner == * Name: [[User:dkeefe|Dennis Keefe]], [[User:mulhern|Anne Mulhern]], [[User:jbaublitz|John Baublitz]] * Email: dke...@redhat.com, amulh...@redhat.com, jbaubl...@redhat.com == Detailed Description == === Stratis 2.3.0 === This release extends the pool unlock command, and adds two new commands, pool bind and pool unbind. The pool bind command establishes an alternative mechanism for unlocking a pool. The user may select either the "tang" mechanism, which implements NBDE (Network-bound Disc Encryption) by means of a Tang server, or the "tpm2" mechanism, which uses TPM 2.0 (Trusted Platform Module) encryption. Binding the devices in a pool to a supplementary Clevis encryption policy does not remove the primary encryption mechanism, which uses a key in the kernel keyring. The pool unbind command simply unbinds a previously added encryption policy from all the devices in the specified pool. In the pool unlock command it is now necessary to specify the mechanism. Use clevis to make use of the Clevis unlocking policy previously specified for the devices in the pool. Use keyring, to make use of the mechanism that uses a key in the kernel keyring, which was introduced in Stratis 2.1.0. Note that the pool unlock command unlocks all currently locked pools. == Detailed Description == === stratisd 2.3.0 === This release introduces two D-Bus interface revisions, which differ in the following way from the previous revisions. org.storage.stratis2.Manager.r3 modifies the UnlockPool method to take an additional parameter, unlock_method, which may be keyring or clevis. org.storage.stratis2.pool.r3 adds two new method: Bind and Unbind. The Bind method takes two arguments, pin and json. The pin argument designates the Clevis pin as a string, and the json argument encodes a Clevis configuration appropriate to the designated pin. The configuration is a JSON object. Besides Clevis information, it may include Stratis-specific keys that encode configuration decisions that Stratis may implement. At present there is just one such key: stratis:tang:trust_url. The Unbind method reverses a Bind action. == Remarks == The Bind method may be called with any Clevis pin and configuration; we expect that any valid Clevis pin and configuration can be used to bind the devices in a pool. However the Stratis project officially supports only the "tang" and "tpm2" pins as those are the pins that may be designated via stratis. Support for additional Clevis policies may be introduced into stratis in later releases. When binding a supplementary encryption policy to the devices in a pool using Clevis, the primary key, which is the key in the kernel keyring which was originally used to encrypt each device, must be supplied. stratisd obtains the appropriate key from the kernel keyring in order to provide it to the Clevis binding mechanism. The correct key must be present in the keyring for the bind operation to succeed. It is not necessary for the user to specify the key, stratisd obtains the necessary information from the LUKS2 metadata on the devices in the pool. In general, it is unwise to write a key consisting of arbitrary binary data to a keyfile. An accidental newline character in the data may cause the contents of the file to be truncated at the newline when read in one context while all the data may be read from the file in some other context. We are not aware that such a mistake would result in any error in Stratis's operation when Stratis is used in the way that we recommend. We explicitly acknowledge that it might be possible, through some direct interaction with the stratisd D-Bus API, or by, e.g., setting a key in the kernel keyring without using stratis, to manufacture a situation where stratisd could not bind the devices in a pool, even when the correct key is set in the kernel keyring. We would not treat such a situation as evidence of a bug in Stratis. == Feedback == == Benefits to Fedora == Users of Fedora will now benefit from Stratis 2.3.0 by: * Multiple methods of unlocking Stratis pools using - Kernel keyring - Tang server - TPM2 Device == Scope == * Proposal owners: ** Update existing stratis-cli package to specify new release ** Update existing stratisd package to specify new release * Other developers: N/A * Release engineering: Self Contained * Policies guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == There is no know impact when upgrading from Stratis 2.2.0 to 2.3.0 == How To Test == * Bind using Tang server echo "secret" > /tmp/testkey stratis key set --keyfile-path /tmp/testkey testkey stratis pool create --key-desc testkey testpool /dev/vdb stratis pool bind tang --trust-url testpool testkey tang.yourdomain.org * Bind using TPM2 echo "secret" > /tmp/testkey stratis key set --keyfile-path /tmp/testkey t
libfplll soname bump
In about a week, I will build libfplll 5.4.0 for Rawhide. This update comes with an soname bump. There are only two consuming packages: gap-pkg-float python-fpylll I will rebuild both of them. -- Jerry James http://www.jamezone.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: Mass spec file change: Adding BuildRequires: make
On 12/7/20 7:33 PM, Miro Hrončok wrote: On 12/7/20 7:18 PM, Tom Stellard wrote: I've updated the package list now[2] to reflect the %cmake_build change, I see for example libsavitar on the list. https://src.fedoraproject.org/rpms/libsavitar/blob/master/f/libsavitar.spec It only uses %cmake_... macros. Was it indeed updated correctly? Now it was. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Nothing provides libgnat-10.so()(64bit)
Hi Jeff. Thank you for rebuilding xmlada. I'll continue from there as I want to use this bootstrap to update packages to newest upstream version anyway . On Mon, Dec 7, 2020 at 7:25 PM Jeff Law wrote: > > > > On 12/7/20 11:07 AM, Jakub Jelinek wrote: > > On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote: > >> Hello. Apparently, many packages in rawhide require libgnat-10.so()(64bit): > > I'm not a provenpackager, so I'm afraid I can't do that myself. > > Perhaps the maintainers can just rebuild them themselves? > And note that some of these are going to require fixes to the packages > themselves as the Ada front-end changed and some of them no longer > build. IIRC zlib and templates_parser are the most important to get > rebuilt and I think those "just work". > > I'll try to get those rebuilt so that the downstream things have a > better chance of working :-) > > jeff > ___ > 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 -- Pavel Zhukov Software Engineer IRC: landgraf ___ 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: Nothing provides libgnat-10.so()(64bit)
On 12/7/20 1:48 PM, Pavel Zhukov wrote: > Hi Jeff. > Thank you for rebuilding xmlada. I'll continue from there as I want to > use this bootstrap to update packages to newest upstream version > anyway . ACK. That'll definitely help. I'll keep my gprbuild bits here (they aren't complete/working anyway) jeff ___ 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: %pretrans [package name]
On Mon, Dec 7, 2020 at 11:37 AM Jerry James wrote: > Sorry for the silence. $DAYJOB kicked into high gear last week. > Okay, I will give this a try today. Thanks for the help, Miro and > Kevin! Nope, that didn't work either: https://koji.fedoraproject.org/koji/taskinfo?taskID=56996523 build.log says: error: line 1572: %pretrans -n sagemath-doc-en -p : package sagemath-doc-en does not exist I don't remember if that was the same error I got with "%pretrans doc-en -p " or not, but it seems likely that it was. Any other ideas? -- Jerry James http://www.jamezone.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: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi wrote: > > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote: > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi wrote: > > > > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote: > > > > Also a couple of notes on modularity here: > > > > > > > > # By default, module stream name is derived from the branch name > > > > If we have any "master" modules, those will get unexpectedly renamed > > > > as soon as they get rebuilt. This might impact tagging or updates and > > > > cause confusion in general. We should check if there are any like that > > > > and decide on further steps. > > > > > > Good thing to check yes. I can try and do so. > > > > Thanks. > > hum, but I am not 100% sure what I am looking for. > modules with a master branch and no name defined? > What does the name being defined look like in the yaml file? Yes. You could also query MBS for stream=master and see if there's anything reasonably recent to narrow your search. But branches would be enough. In modulemd, stream name is defined as "stream: ". > > > > # Modules might be pulling components from their master branches to > > > > build Rawhide artifacts > > > > There are various use cases for this, too long to list. If the master > > > > ref is no longer available, these will not build. Modulemd files that > > > > pull components from master need to be updated after Phase 2. > > > > > > Yep. +1 > > > > Great, will you do that, too? > > There seems to be a bunch of them. ;( Many of those are definitely obsolete, though! > > > > # The modulemd component ref is optional and defaults to master > > > > Unless this got changed later, if the ref field is omitted, the value > > > > defaults to "master". This is part of the specification and is handled > > > > by libmodulemd. Not sure how to proceed here. > > > > > > Can we change the default? > > > > According to Vít that's already happened (for completely unrelated > > reasons), so we're good here. > > ok. > > > > > And besides modularity: > > > > > > > > There are people and teams who use bots to autobuild their upstream > > > > projects in Rawhide. If they have a bot account (and I hope they do), > > > > they should be notified to update their tooling. > > > > > > We don't have much tracking on bot accounts. People make them and sign > > > up for fas for them, etc. > > > > > > We can try and find things that are obvious, but we are likely to miss > > > some. We can definitely help people who notice breakage tho. > > > > Ah, I kinda expected these accounts to be clearly marked as being > > non-human. Oh well. > > > > Anyway, besides the magical module stream renames, all of this should > > continue to work fine if we get the symbolic refs, I think? > > Well, I am ok with a symbolic ref from main to/from rawhide, but I don't > like the idea of a master symbolic ref. It kind of defeats the purpose > of the entire thing. ;( Well, okay. If we get the master ref, I'm happy as that's mostly a no-op for me. If not, it implies a lot of downstream RHEL work we'll have to handle. Just let us all know in due time. P ___ 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: Mass spec file change: Adding BuildRequires: make
Hi Tom, Tom Stellard writes: > On 11/30/20 2:06 PM, Tom Stellard wrote: >> Hi, >> >> As part of the f34 change request[1] for removing make from the >> buildroot, I will be doing a mass update of packages[2] to add >> BuildRequires: make where it is needed. >> >> If you are a package maintainer and would prefer to update your packages >> on your own, please do so before Dec 14, which is when I will begin >> doing the mass update. >> > > Hi, > > Thanks for all the feedback. It seems like there is consensus now that > packages that use %cmake_build and %cmake_install but never invoke make > directly should not have to BuildRequire: make, so I've updated my > scripts to ignore those packages. > > I have also eliminated some (but not all) of the false positives that > have been reported on the list. I'm still working on getting rid of the > rest of them. > > I've updated the package list now[2] to reflect the %cmake_build change, > and I will continue to update this at least once per day to account for > package updates in Fedora. > > There is still a week left before I start the updates, so please > continue to give feedback. i3 now uses meson and no longer requires make. Also, I've fixed python-breathe myself today (so it's most likely not yet included). Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Introduction
Welcome to the pack Robin! If you need assistance getting started, take a look at the Fedora Join SIG: https://docs.fedoraproject.org/bg/fedora-join/ Cheers, Dan "Robin Opletal" writes: > Hi, > > My name is Robin Opletal, I am from the Czech Republic and online I tend > to go under the name of "fourstepper". > > I would like to help out with maintaining packages of interest for > Fedora, currently, I am interested in getting aerc, the terminal e-mail > client packaged for Fedora. (https://git.sr.ht/~sircmpwn/aerc) > > For Aerc, I have so far created a COPR repository, which currently lives > here: https://copr.fedorainfracloud.org/coprs/fourstepper/aerc/builds/ > > I would also be thrilled to help with other packages if needed and learn > and help with the Fedora's package build system. > ___ > 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: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Scala
On Mon, Dec 7, 2020 at 11:51 AM Jerry James wrote:
> - Figure out if jansi 2.0.1 is backwards compatible with jansi 1.18. If it is
> not, then we'll have to figure out how to make parallel installable versions
> of jansi 1.18 and 2.0.1, or else port everything currently using 1.18 to
> 2.0.1.
It is not backwards compatible. Drat!
> - Figure out if I built jansi 2.0.1 correctly. There is a shared object
> inside
> of the JAR, which I think is not correct.
What's happening here is that jansi 2.x obsoletes jansi-native. The
shared library for jansi-native is packed inside of the JAR (which is
correctly installed into %{_jnidir}). The packaging guidelines allow
this, so all I need to do is add the appropriate Obsoletes and
Provides. I've also got to ensure that the shared library is built
with the correct compiler and linker flags.
So the sticking point here is that jansi 1.x and 2.x are incompatible.
I'll see if there is a reasonable way of installing them in parallel.
--
Jerry James
http://www.jamezone.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: %pretrans [package name]
On 12/7/20 9:59 PM, Jerry James wrote:
On Mon, Dec 7, 2020 at 11:37 AM Jerry James wrote:
Sorry for the silence. $DAYJOB kicked into high gear last week.
Okay, I will give this a try today. Thanks for the help, Miro and
Kevin!
Nope, that didn't work either:
https://koji.fedoraproject.org/koji/taskinfo?taskID=56996523
build.log says:
error: line 1572: %pretrans -n sagemath-doc-en -p
: package sagemath-doc-en does not exist
I don't remember if that was the same error I got with "%pretrans
doc-en -p " or not, but it seems likely that it was. Any other
ideas?
I have figured it out. The package indeed does not exist on ppc64le, which is
where the SRPM was created in Koji.
Wrap the scriptlet in %if %{with docs}.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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
OCaml PPX updates
Hi all, I would like to update several of the OCaml PPX packages to more recent versions, but doing so requires messing around with other people's packages. This is the set of updates I would like to make: https://copr.fedorainfracloud.org/coprs/jjames/ocaml/ I've BCCed the maintainers of the following packages to see if they are okay with this: - ocaml-migrate-parsetree (update to 1.8.0) - ocaml-sedlex (update to 2.2) There are also builds for ocaml-ppx-tools-versioned and ocaml-lwt in the list, but they are simple rebuilds with no substantive changes to the spec files. Let me know if you see anything that concerns you. Regards, -- Jerry James http://www.jamezone.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: %pretrans [package name]
On Mon, Dec 7, 2020 at 3:04 PM Miro Hrončok wrote:
> I have figured it out. The package indeed does not exist on ppc64le, which is
> where the SRPM was created in Koji.
>
> Wrap the scriptlet in %if %{with docs}.
/me smacks forehead
Thank you, Miro! There's no telling how long I might have puzzled over this.
--
Jerry James
http://www.jamezone.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: OCaml PPX updates
Hi Jerry, On Tue, 8 Dec 2020, 07:38 Jerry James, wrote: > Hi all, > > I've BCCed the maintainers of the following packages to see if they > are okay with this: > - ocaml-migrate-parsetree (update to 1.8.0) > - ocaml-sedlex (update to 2.2) > I'm fine with this. Thanks for taking care of the updates. Best regards, Andy > ___ 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
"CMake to do out-of-source builds" implemented under EPEL 7?
Hi,
will the change "CMake to do out-of-source builds" [1] also bee implemented
under EPEL 7?
So, that %cmake3 and %cmake3_build will work as expected and use
%{_vpath_builddir}.
Best regards
Wolfgang
[1] https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
___
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
Packaging a go application
Hi, As I have said earlier, I am trying to package aerc, the mail client, for Fedora. What didn't cross my mind is that internet access will be limited during the build, thus the automatic dependency resolution from the Makefile during the build stage of aerc doesn't work. I was wondering what the best way would be to get this into BuildRequires. My current .spec - https://pastebin.com/HZsuPXds The project uses go.mod (https://git.sr.ht/~sircmpwn/aerc/tree/master/go.mod) with quite a few dependencies, most of them not available in the official repositories as packages. As far as I understand, that gives me two options: 1) Bundle the dependencies as a package for each release of aerc based on aerc's go.mod 2) Package a go application according to the official Go packaging guidelines (from here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_dependencies) I have attempted this, generating the deps with golist as described and adding those as BuildRequires, but the builds then failed with error: Failed build dependencies: golang(github.com/creack/pty) is needed by aerc-0.5.2-4.fc33.x86_64 I have tried looking at the spec file of kubectl for reference, but I am not sure which all macros are required to make BuildRequires: golang() work. Thanks for any pointers! ___ 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
