HEADS UP: libvpx soname bump in rawhide
Hi, I am in the process of updating libvpx from 1.13.1 to 1.14.0 in rawhide. This comes with a soname bump, but I am including a livpx8 compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. Some of the affected packages were already FTBFS so the compat package is going to be needed for a while. I will take care of the rebuilds. Affected packages:baresip-3.9.0-1.fc40.src.rpmffmpeg-6.1.1-7.fc40.src.rpmgodot3-3.5.2-5.fc40.src.rpmgstreamer1-plugins-good-1.22.9-1.fc40.src.rpmicecat-115.7.0-1.rh1.fc40.src.rpmqt5-qtwebengine-5.15.16-1.fc40.src.rpmseamonkey-2.53.18.1-2.fc40.src.rpmtoxcore-0.2.18-6.fc40.src.rpmutox-0.18.1-11.fc40.src.rpmvlc-3.0.20-11.fc40.src.rpmxine-lib-1.2.13-10.fc40.src.rpmxpra-5.0.3-4.fc40.src.rpm Have a good day!Pete-- ___ 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
HEADS UP: icu 74 coming to rawhide
Hi,I am in the process of updating icu from 73.2 to 74.1 in rawhide. This comes with a soname bump, but as usual, I'm including a libicu73 compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. I'll work on the rebuilds over the weekend.Have a good day!Pete-- ___ 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: process to unretire/re-review package where some branches still exist?
28.08.2023, 20:08, "Fabio Valentini" :On Mon, Aug 28, 2023 at 7:53 PM Pete Walter <walter.p...@yandex.com> wrote: 28.08.2023, 18:34, "Scott Talbert" <s...@techie.net>: On Mon, 28 Aug 2023, Mark E. Fuller wrote: Hi all, I'm trying to unretire golang-github-google-renameio-2 and have completed a re-review. However, since the package still exists in F37 and F38, the process for getting the F39 and rawhide branches "back" and getting control of the package repo is unclear. Can anyone advise? It's just the normal process. The fact that F37 and F38 branches exist doesn't change anything. (Packages can't be retired in already-released versions, so that's why F37 and F38 branches still exist.) https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming No, the process does not work like that in practice. I tried to unretire a few retired rust packages before the 2 month deadline passed where re-review is not needed, but Fabio Valentini told me that I cannot do that because he is still maintaining them for the f36 and f37 branches (it was several months ago). Releng agreed and refused to unretire the packages. https://pagure.io/releng/issue/11372 https://pagure.io/releng/issue/11373 https://pagure.io/releng/issue/11374 I may have overreacted in the ticket but in my opinion this is an incredibly antisocial process where one person has the power to permanently retire something and then refuse to bring it back. I needed it for packaging fractal where as a result of being able to unretire them I had to bundle all dependencies. Same person tried to stop that as well... https://bugzilla.redhat.com/show_bug.cgi?id=2223224Can you please stop spreading lies about me?Anybody can read these public tickets, and see that I didn't refuse*anything* (other than having my maintainer rights taken away from me*without my knowledge*), and that I offered help instead. You gave up your maintainer rights when you retired the package but then you refused to let another person pick it up. You "offering help" was just a way to look nice in the ticket - where is the package now? Let me answer that for you: Still retired. Offered help never arrived. I am done with this discussion. Pete___ 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: process to unretire/re-review package where some branches still exist?
28.08.2023, 18:34, "Scott Talbert" :On Mon, 28 Aug 2023, Mark E. Fuller wrote: Hi all, I'm trying to unretire golang-github-google-renameio-2 and have completed a re-review. However, since the package still exists in F37 and F38, the process for getting the F39 and rawhide branches "back" and getting control of the package repo is unclear. Can anyone advise?It's just the normal process. The fact that F37 and F38 branches existdoesn't change anything. (Packages can't be retired in already-releasedversions, so that's why F37 and F38 branches still exist.)https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming No, the process does not work like that in practice.I tried to unretire a few retired rust packages before the 2 month deadline passed where re-review is not needed, but Fabio Valentini told me that I cannot do that because he is still maintaining them for the f36 and f37 branches (it was several months ago). Releng agreed and refused to unretire the packages. https://pagure.io/releng/issue/11372https://pagure.io/releng/issue/11373https://pagure.io/releng/issue/11374 I may have overreacted in the ticket but in my opinion this is an incredibly antisocial process where one person has the power to permanently retire something and then refuse to bring it back. I needed it for packaging fractal where as a result of being able to unretire them I had to bundle all dependencies. Same person tried to stop that as well... https://bugzilla.redhat.com/show_bug.cgi?id=2223224 (I am no longer interested in bringing the rust dependencies back. Bundling works much better. Thank you very much.) Pete___ 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
libgit2 1.7.x in rawhide and F39 with a compat packages for 1.6.x and 1.5.x
I just bumped libgit2 to 1.7.x in both rawhide and F39 and added a compat package for the old 1.6.x ABI. This should allow seamless switchover to the new ABI without breaking anything that needs 1.6.x. We also have an older compat package for 1.5.x ABI that is still used by the golang bindings. The golang bindings upstream is being slow here to update to new libgit2 versions. If anyone needs 1.7.x for F38 please let me know. With the compat package system this is now doable. Pete___ 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
libgit2 1.6.x in rawhide and F38 with a compat package for 1.5.x
I just bumped libgit2 to 1.6.x in both rawhide and F38 and added a compat package for the old 1.5.x ABI. This should allow seamless switchover to the new ABI without breaking anything that needs 1.5.x. Let me know if you run into issues with this. The compat package system for libgit2 is still new and may have some teething issues. Here is the F38 update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fdee262d55I left gnome-builder out of it as amigadave has gnome-builder updates pending. Packages still using old libgit2 versions: 1.3: nothing left so I just retired the libgit2_1.3 package in rawhide. Will do the same in F38 once the freeze is over.1.4: julia, rpm-git-tag-sort1.5: R-gert, git-time-metric, python-pygit2, rust Pete___ 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
libgit2 1.5.x in rawhide with compat packages for 1.3.x and 1.4.x
I took over libgit2 from Igor when he gave up all his packages and have since tried to get it up to date. libgit2 is a bit special because it bumps soname every once in a while and then other packages often fail to rebuild against the new version both because of libgit2 API changes and because they are FTBFS due to unrelated issues (hi new gcc). libgit2 is also network facing and due to this has a high number of security issues so it is very important to keep it up to date. I think I have a good plan now how to keep it up to date without too much disruption and it is as follows: Update libgit2 to new version in rawhide as soon as it is released. At the same time, create a compat package for the old API and add it to rawhide. Keep the old API compat package in rawhide for 6 months or as long as it takes for everything to switch over to the latest version. Today, we have 3 versions in rawhide (libgit2 was updated from 1.3.x to 1.4.x and then 1.5.x over the last month and the compat packages were added today): libgit2 package with version 1.5.1 (security supported still from upstream)libgit2_1.4 package with version 1.4.5 (security supported still from upstream)libgit2_1.3 package with version 1.3.2 (EOL upstream) I intend to retire libgit2_1.3 as soon as git-time-metric (https://bugzilla.redhat.com/show_bug.cgi?id=2162852) and golang-github-libgit2-git2go (https://bugzilla.redhat.com/show_bug.cgi?id=2152113) are fixed.I intend to retire libgit2_1.4 as soon as julia (https://bugzilla.redhat.com/show_bug.cgi?id=2165534) and rpm-git-tag-sort (https://bugzilla.redhat.com/show_bug.cgi?id=2165535) are fixed. The rest of the dependencies are already rebuilt to use libgit2. I think this kind of compat package system could even allow updating libgit2 to latest versions in stable Fedora branches and in EPEL. I want to test this out in rawhide first though and see if it works well enough. Pete___ 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: List of long term FTBFS packages to be retired next week
- all 31.01.2023, 12:44, "Miro Hrončok" :howl atim, pwalterI took over howl that was orphaned a few weeks ago and now rescued it and fixed it to build from source. I also created a fedora flatpak for it as it was missing. Pete___ 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: Retiring Bottles in favor of Flatpak provided by upstream
I am not happy about dropping Fedora packages in favor of upstream Flatpaks either. Can you assign the package to me instead of retiring it? I can get it updated so we can keep it in Fedora. Pete 25.01.2023, 10:56, "Vít Ondruch" :I am not user of Bottles so I won't complain about this particular case,but the push towards (upstream) Flatpaks is unfortunate :/VítDne 24. 01. 23 v 22:44 Sandro napsal(a): Hi, Development of Bottles is moving fast and we have been struggling to keep up with upstream releases, especially since the introduction of Rust components. Upstream has approached the maintainers [1,2] and asked us to retire the package in favor of the Flatpak packages provided by upstream. I'm planning to move forward with retiring Bottles in the coming days. I will add a comment in all open bug reports, letting users know they should switch to the Flatpak release. Bottles in F36 and F37 will not receive any further updates unless there are security related issues surfacing. [1] https://github.com/bottlesdevs/Bottles/issues/2345 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2160007 Cheers, Sandro,___devel mailing list -- devel@lists.fedoraproject.orgTo unsubscribe send an email to devel-le...@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.orgDo not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ 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: HEADS UP: icu 72 coming to rawhide
28.12.2022, 15:09, "Pete Walter" :Hi,I am in the process of updating icu from 71.1 to 72.1 in rawhide. This comes with a soname bump, but as usual, I'm including a compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. I'll work on the rebuilds over the weekend. This is now done. The following 4 packages failed to rebuild. The rest of 102 packages built fine and are all rebuilt in rawhide.mozjs78: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691022mozjs91: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691025mozjs102: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691005postfix: https://koji.fedoraproject.org/koji/taskinfo?taskID=95695828 mozjs* failed in self tests which I bet need updating for new icu. postfix failed due to an unrelated failure and was already FTBFS before the icu update. Pete___ 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
HEADS UP: icu 72 coming to rawhide
Hi,I am in the process of updating icu from 71.1 to 72.1 in rawhide. This comes with a soname bump, but as usual, I'm including a compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. I'll work on the rebuilds over the weekend.Have a good day!Pete___ 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: Unannounced soname bump: libgdal.so.28
22.05.2021, 10:43, "Sandro Mani" : On 21.05.21 14:24, Sandro Mani wrote: On 21.05.21 14:03, Richard Shaw wrote:On Fri, May 21, 2021 at 3:43 AM Pete Walter <walter.p...@yandex.com> wrote:libgdal soname has been bumped to libgdal.so.28 without rebuilding dependent packages in rawhide. From what I can tell the rebuilds were actually in progress but then due to the soname bump in libgta (discussed in another thread on devel@) the libgdal update leaked out to rawhide in https://koji.fedoraproject.org/koji/buildinfo?buildID=1749588 without the rest of the rebuilds that were in progress in f35-build-side-40845. hobbes1069, smani can you sort this out? I'm primarily interested in getting OpenImageIO to build again, so I've only been following the rabbit hole as far as needed to make that happen. The gdal update should have been performed in a side tag, but obviously too late for that now.The update was performed in a side tag and submitted [1], but the updated ended up not getting pushed due to a collision with gazebo-10.1.0-17, which I missed. I'll submoit the new builds as necessary to the side-tag and make sure that the update gets pushed correctly.Is done now. Thanks! Pete___ 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
Unannounced soname bump: libgdal.so.28
libgdal soname has been bumped to libgdal.so.28 without rebuilding dependent packages in rawhide. From what I can tell the rebuilds were actually in progress but then due to the soname bump in libgta (discussed in another thread on devel@) the libgdal update leaked out to rawhide in https://koji.fedoraproject.org/koji/buildinfo?buildID=1749588 without the rest of the rebuilds that were in progress in f35-build-side-40845. hobbes1069, smani can you sort this out? Pete___ 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: Bodhi critpath package updates now gated on openQA results
19.05.2021, 23:37, "Adam Williamson" :On Wed, 2021-05-19 at 15:23 -0700, Adam Williamson wrote: 2. How can we best sensibly tweak things so we don't gate on Rawhide updates that *do* get marked as critpath? I'm going to think about #2 now.So all the clever ways I can think of to do this for now kinda suck, soI went with a dull but fairly correct (I hope) one:https://pagure.io/fedora-infra/ansible/c/c9ee450c6a56cb0fa900ae5980d1d3d37dc960e5?branch=mainthe drawback of that is we have to remember to manually update thatlist of versions each time a release branches. Which will inevitablyget forgotten sometime. That's why I wanted to use the wildcards. Butit's the best option I can think of for now. Sorry again for thetrouble. That's great. Thank you! (My update ended up in a messed up state, but that I think is unrelated to openQA. Trying to split it up now into smaller chunks.) Pete___ 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: Bodhi critpath package updates now gated on openQA results
19.05.2021, 22:59, "Adam Williamson" :On Wed, 2021-05-19 at 22:54 +0100, Pete Walter wrote: I waited over an hour on openQA test results that never came. Ended up waiving https://bodhi.fedoraproject.org/updates/FEDORA-2021-8cdffadc43. After a bunch of searching I found https://openqa.fedoraproject.org but there was no indication that it had even started running the tests for this update. Frustrating experience.Sorry for the trouble. But there's obviously something odd there. Thegating is not intended to be active for Rawhide updates at all, becausewe don't run the tests for Rawhide. It is only supposed to happen forstable and Branched. I think it must be working this way most of thetime, or else Rawhide would've ground to a halt and there'd be a lotmore angry people.How did you create that update exactly? Was it from a side tag? Thanks! Thanks for the quick reply, Adam! Yes, it was from a side tag. I used the Bodhi web UI to create it: bodhi.fedoraproject.org -> New Update -> Use Side Tag. Pete___ 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: Bodhi critpath package updates now gated on openQA results
I waited over an hour on openQA test results that never came. Ended up waiving https://bodhi.fedoraproject.org/updates/FEDORA-2021-8cdffadc43. After a bunch of searching I found https://openqa.fedoraproject.org but there was no indication that it had even started running the tests for this update. Frustrating experience. Pete___ 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
HEADS UP: icu 69 coming to rawhide
Hi,I am in the process of updating icu from 67.1 to 69.1 in rawhide. This comes with a soname bump, but as usual, I'm including a compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. I'll work on the rebuilds over the weekend.Have a good day!Pete___ 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
HEADS UP: icu 67 coming to rawhide
Hi,I am in the process of updating icu from 65.1 to 67.1 in rawhide. This comes with a soname bump, but as usual, I'm including a compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. I'll work on the rebuilds over the weekend.Have a good weekend!Pete___ 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: Non-responsive maintainer: pwalter
21.03.2020, 10:15, "Neal Gompa" : > On Sat, Mar 21, 2020 at 6:02 AM Pete Walter wrote: >> For months!? This is the first email I get from you. Just for the record, I >> am around, but have 0 interest in EPEL 8 as of the moment. > > In that case, I'd be happy to take on co-maintainership (admin) or > even take over the package entirely from you (main admin), if you > wish. After this kind of treatment there's no way I'm giving you access to any of my packages. Please learn how to work in a group. Pierre is going to help out with the EPEL 8 branch. Pete ___ 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: Non-responsive maintainer: pwalter
Sure, I've bumped the access level and please go ahead. Thanks for asking nicely (instead of demanding like Neal Gompa did ...). Pete 21.03.2020, 15:20, "Pierre-Yves Chibon" : > On Sat, Mar 21, 2020 at 10:02:18AM +, Pete Walter wrote: >> For months!? This is the first email I get from you. Just for the record, I >> am around, but have 0 interest in EPEL 8 as of the moment. > > Hi Pete, > > The infra-sig group has already commit access to pygit2, however, to request a > new branch (epel8 in this case) one needs admin access. > So if you like you could just bump the level of access of that group (I can > also > do it for you if you wish) and we'll take care of epel8. > > Thanks, > Pierre ___ 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: Non-responsive maintainer: pwalter
For months!? This is the first email I get from you. Just for the record, I am around, but have 0 interest in EPEL 8 as of the moment. Pete 21.03.2020, 08:41, "Neal Gompa" : > Hello all, > > I've been trying to get in touch with Pete Walter for a few months now > w.r.t. python-pygit2[0]. Unfortunately, he hasn't been responding to > my emails[1][2][3] (he was CC'd to all of those) or the bug I filed > requesting pygit2 for EPEL 8[4]. > > I've also filed the requisite non-responsive maintainer check bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1815734 > > Does anyone know how to get in touch with him? > > [0]: https://src.fedoraproject.org/rpms/python-pygit2 > [1]: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GFQVBB5GLGYNBVYRUBEJN5ZSZXDCF4V5/ > [2]: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FCGFN5475HL37JL3W6MNLX4SAUCBTPUE/ > [3]: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LBO6PQBZNYONMTFKSWLF6HAGY2KAXV43/ > [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1803544 > > -- > 真実はいつも一つ！/ Always, there's only one truth! ___ 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
Last chance to vote for FESCo
Go vote now before the vote closes! Otherwise you'll miss this crucial chance to choose whether Fedora should support modularity or not. https://elections.fedoraproject.org/ Pete ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default
26.11.2019, 11:39, "Zbigniew Jędrzejewski-Szmek" : > On Mon, Nov 25, 2019 at 03:55:28PM -0800, Adam Williamson wrote: >> On Tue, 2019-11-26 at 00:34 +0100, Kevin Kofler wrote: >> > Samuel Sieb wrote: >> > > Steps 1 - 4 are not benefits, they are workarounds to critical system >> > > utilities required by this change. I don't understand why this change >> > > is necessary at all. It only affects local logins and if someone wants >> > > to have an empty password, why make it so difficult? It's their choice. >> > >> > +1, I do not see the point of patronizing our users that way (and it is >> only >> > an extra hoop to jump through because they can still readd the nullok), >> and >> > find it particularly pointless to make all those error-prone changes to >> core >> > system utilities just to make that work. >> > >> > > It's not like Fedora has any default logins with empty passwords, the >> > > user has to make their own. >> > >> > That part is actually not entirely true: the live images have no password >> > set on the liveuser and root accounts. Hence, this change will also break >> > the live images, unless we add yet another hack to the scriptlets in the >> > live kickstarts, one that readds the nullok option. IMHO, we already have >> > too many hacks in the kickstart scriptlets. >> >> I gotta say +1 too. I don't buy that there's a significant 'hardening' >> benefit worth all the effort mentioned in the Change *plus* the >> additional consequences Kevin and Martin pointed out. At minimum I'd >> like to see a much more convincing case that people are creating users >> without passwords without understanding what they're doing. > > +1 from me too. It is very convenient to be able to set an empty password > on certains VMs and containers and special-purpose machines. > > I would support this change if there were plausible scenarios where the > password is unset by mistake. But the only case cited so far is the puppet > mistake where the admins scripted 'passwd -d root' and then forgot about > this. This is not a fight we could ever win: if we remove 'nullok', > the admins would simply add another script line to add it back. Agreed. I too am against this change for the reasons other people have already stated. Pete ___ 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: icu 65 just landed in rawhide
Hi, I just updated icu from 63.2 to 65.1 in rawhide. This comes with a soname bump, but as usual, I've included a compat package providing the old soname to not break the world while the rebuilds are in progress, so no rawhide breakage is expected. I'll work on the rebuilds over the weekend. Have a good weekend! Pete ___ 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
17.10.2019, 17:15, "Stephen John Smoogen" : > On Wed, 16 Oct 2019 at 20:27, Stephen Gallagher wrote: >> > >> So, literally every word of this is wrong. The negative feedback is >> not "overwhelming". It is approximately four noisy individuals, all of >> whom have expressed zero interest in understanding the actual >> situation that they are trying to "fix" by endlessly insulting the >> people working on the problem. Demoralizing the people who can dig us >> out of this situation is an unwise strategy. > > I realize you were tired and angry when reading this, but I want to > say that I haven't put in my complaints because I find myself actually > agreeing with the high level points pointed out by the 4 noisy > individuals but find their method irritating and don't want to pile > on. Well said. I have also stayed quiet for much the same reasons, but I support what Kevin and Miro and others are saying. It's definitely just not 4 noisy individuals. I'd even go as far as saying that most of the community here agrees with what they are saying. Pete ___ 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: Major update to LLVM appearing in F31 without any communication, appears to violate update policy
27.09.2019, 16:51, "Tom Stellard" : > The LLVM update has the necessary karma now and all the gating tests > have passed. Should I push this to stable now and then push the mesa > update later or should we still try to combine the updates? Yes, go for it and push it to stable. I'll submit mesa to stable after you've submitted llvm so they end up going out at the same time. Thanks, Pete ___ 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 vs. libgit
20.06.2019, 22:50, "Igor Gnatenko" : > Hello, > > I just wanted to give you an update from my last discussions on > #fedora-modularity and other places. > > # Problems definition > > * Default modules can't have conflicting dependenices > * Changing dependencies in a stream is not supported > > # Why does libgit2 has to be a module? > > libgit2 is not just one package. It is an ecosystem. > > Right now libgit2 module provides libgit2 itself and python bindings. > While we can obviously provide libgit2_0.26, libgit2_0.27 and such, > this does not help us with python packages. Nobody in sane mind will rename > them > and make them conflict (because they are not parallel-installable). > > I wanted to also add ruby bindings to a module, but I never got time > to actually do it. I'm the python-pygit2 maintainer (libgit2 python bindings) and I'm very much opposed to what you are doing with libgit2 and modules. It's a huge mess right now. Please go back to a known libgit2 version shipped in one Fedora, so I know which version to target with the python bindings (and so that apps have a clear story as well what to expect). Also, I'd like you to stop shipping the python bindings inside the libgit2 module. They are working very well as a regular package. Thanks. The parallel installable libgit2 non-modular packages that were proposed earlier sounds like a nice solution. I'd be happy to help implement that. Pete ___ 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: pwalter pushed to ImageMagick (master). "Update to 6.9.10.28"
18.02.2019, 16:36, "Michael Cronenworth" : > On 2/18/19 10:07 AM, notificati...@fedoraproject.org wrote: >> Notification time stamped 2019-02-18 16:07:12 UTC >> >> From b21c11f55efa073c3d6c4798980bf8821131a872 Mon Sep 17 00:00:00 2001 >> From: Pete Walter >> Date: Feb 18 2019 15:50:47 + >> Subject: Update to 6.9.10.28 > > Thanks, Pete, but please stop pushing ImageMagick updates unless you are > going to do > the full job. There's at least one package that must be updated at the same > time, so > please update and push rubygem-rmagick at the same time. Hi Michael, Thanks for the heads up. I've kicked off a rubygem-rmagick rebuild against 6.9.10.28. Pete ___ 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: Attempting to fix hyperscan FTBFS
12.02.2019, 21:16, "jt" : > On Tue, 2019-02-12 at 16:13 -0500, jt wrote: >> On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote: >> > Looking at the build log, it seems to be checking for 'libpcre = >> > 8.41', but the build root has 8.43-RC1 which causes the build to >> > error out. >> > >> > Pete >> > >> > 12.02.2019, 20:43, "jt" : >> > > Hi All, >> > > >> > > I am looking at the FTBFS for hyperscan[0] and need some >> > > assistance. >> > > From what I can tell it looks like this may be related to the -- >> > > as- >> > > needed linker change. >> > > >> > > The reason I say it may be related to the linking change is I can >> > > build >> > > the 5.1.0 release against the fedora-29-x86_64 mock profile and >> > > the >> > > CMakeOutput.log from a local mock build against the fedora- >> > > rawhide- >> > > x86_64 profile[1] seems to indicate a linking issue. >> > > >> > > This is outside my expertise but I would obviously like to fix >> > > the >> > > issue the most appropriate way possible. >> > > >> > > So if this is linker issue, what's the best approach to fix in >> > > this >> > > case? >> > > >> > > If it isn't a linker issue, where should I start poking next? >> > > >> > > Thanks in advance for any pointers. >> > > >> > > [0] https://koji.fedoraproject.org/koji/taskinfo?taskID=32400415 >> > > [1] >> > > https://gist.github.com/jmtaylor90/bd9680de68d1f8486dacd4e0b645f07b >> > > >> > > JT >> > > >> > > >> >> My rereads before sending failed me. >> >> I linked the original 5.0.0 build, this is the proper 5.1.0 build >> link: >> >> https://koji.fedoraproject.org/koji/taskinfo?=32766510 >> >> The 5.1.0 release fixes the pcre explicit version requirement among >> other things. >> >> Sorry for the confusion > > Sigh, that should be: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32766510 This log has "-mtune=option: not valid". I guess something has changed here with gcc 9 that the cmake script doesn't like? Pete ___ 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: Attempting to fix hyperscan FTBFS
12.02.2019, 21:16, "jt" : > On Tue, 2019-02-12 at 16:13 -0500, jt wrote: >> On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote: >> > Looking at the build log, it seems to be checking for 'libpcre = >> > 8.41', but the build root has 8.43-RC1 which causes the build to >> > error out. >> > >> > Pete >> > >> > 12.02.2019, 20:43, "jt" : >> > > Hi All, >> > > >> > > I am looking at the FTBFS for hyperscan[0] and need some >> > > assistance. >> > > From what I can tell it looks like this may be related to the -- >> > > as- >> > > needed linker change. >> > > >> > > The reason I say it may be related to the linking change is I can >> > > build >> > > the 5.1.0 release against the fedora-29-x86_64 mock profile and >> > > the >> > > CMakeOutput.log from a local mock build against the fedora- >> > > rawhide- >> > > x86_64 profile[1] seems to indicate a linking issue. >> > > >> > > This is outside my expertise but I would obviously like to fix >> > > the >> > > issue the most appropriate way possible. >> > > >> > > So if this is linker issue, what's the best approach to fix in >> > > this >> > > case? >> > > >> > > If it isn't a linker issue, where should I start poking next? >> > > >> > > Thanks in advance for any pointers. >> > > >> > > [0] https://koji.fedoraproject.org/koji/taskinfo?taskID=32400415 >> > > [1] >> > > https://gist.github.com/jmtaylor90/bd9680de68d1f8486dacd4e0b645f07b >> > > >> > > JT >> > > >> > > >> >> My rereads before sending failed me. >> >> I linked the original 5.0.0 build, this is the proper 5.1.0 build >> link: >> >> https://koji.fedoraproject.org/koji/taskinfo?=32766510 >> >> The 5.1.0 release fixes the pcre explicit version requirement among >> other things. >> >> Sorry for the confusion > > Sigh, that should be: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32766510 This log has "-mtune=option: not valid". I guess something has changed here with gcc 9 that the cmake script doesn't like? Pete ___ 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: Attempting to fix hyperscan FTBFS
Looking at the build log, it seems to be checking for 'libpcre = 8.41', but the build root has 8.43-RC1 which causes the build to error out. Pete 12.02.2019, 20:43, "jt" : > Hi All, > > I am looking at the FTBFS for hyperscan[0] and need some assistance. > From what I can tell it looks like this may be related to the --as- > needed linker change. > > The reason I say it may be related to the linking change is I can build > the 5.1.0 release against the fedora-29-x86_64 mock profile and the > CMakeOutput.log from a local mock build against the fedora-rawhide- > x86_64 profile[1] seems to indicate a linking issue. > > This is outside my expertise but I would obviously like to fix the > issue the most appropriate way possible. > > So if this is linker issue, what's the best approach to fix in this > case? > > If it isn't a linker issue, where should I start poking next? > > Thanks in advance for any pointers. > > [0] https://koji.fedoraproject.org/koji/taskinfo?taskID=32400415 > [1] https://gist.github.com/jmtaylor90/bd9680de68d1f8486dacd4e0b645f07b > > JT > > ___ > 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 ___ 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 Mass Rebuild
There seems to be an issue with moving builds over. Everything seems to be stuck in f30-pending and not getting tagged with f30. I'm also concerned that once the signing queue starts moving, it's going to tag older packages over the new builds that have happened in the mean time. Pete 05.02.2019, 07:45, "Mohan Boddu" :Hi all, Per the Fedora 30 schedule[1] we started a mass rebuild for Fedora 30on Jan 31st 2019. We did a mass rebuild for Fedora 30 for the changes listed in: https://pagure.io/releng/issue/8086 Mass rebuild was done in a side tag (f30-rebuild) and are now getting moved over to f30. Failures can be seenhttps://kojipkgs.fedoraproject.org/mass-rebuild/f30-failures.html Things still needing rebuilthttps://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html 19097 builds have been tagged into f30, there s currently 1787 failedbuilds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in thereporting. You can contact releng in #fedora-releng on freenode, bydropping an email to our list[2] or filing an issue in pagure[3] Regards,Mohan Boddu. [1] https://fedoraproject.org/wiki/Releases/30/Schedule[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/[3] https://pagure.io/releng/,___devel-announce mailing list -- devel-annou...@lists.fedoraproject.orgTo unsubscribe send an email to devel-announce-le...@lists.fedoraproject.orgFedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlList Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org,___devel mailing list -- devel@lists.fedoraproject.orgTo unsubscribe send an email to devel-le...@lists.fedoraproject.orgFedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlList Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList 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://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: Unannounced soname bump - libwmf-0.2.so.7 -> libwmf-0.2.so.8
02.02.2019, 15:54, "Rex Dieter" : > Rolling back is still probably the "right thing to do(tm)" Completely agree. Thanks for fixing it, Caolán! Pete ___ 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: Can't figure out how to build flatpaks
01.02.2019, 04:06, "Owen Taylor" : > Thanks for trying it out, and sorry that you are having problems! Thanks Owen! That was super helpful. Got it to build now and submitted the update to bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2019-a922b417ed Pete ___ 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
Can't figure out how to build flatpaks
Hi,
I've noticed that someone created a flatpak build for one of my packages
(feedreader), but it's horribly out of date: flatpak has 2.5.1 vs rpm has
2.7.0. I've been trying to update the flatpak build, but not much luck here.
The documentation is pretty verbose, but seems to miss some crucial steps and
nothing really works.
I've been following
https://fishsoup.net/misc/fedora-docs-flatpak/flatpak/tutorial/
Specifically, I've typed the following commands:
# dnf install flatpak-module-tools fedmod
$ fedpkg clone modules/feedreader
$ cd feedreader
$ fedmod fetch-metadata
Up until here everything seems to check out and download correctly, but then
when I do:
$ flatpak-module local-build --install
2019-01-31 17:11:52,388 - MainThread - moksha.hub - WARNING - Cannot find qpid
python module. Make sure you have python-qpid installed.
BUILDING MODULE
===
Traceback (most recent call last):
File "/usr/bin/mbs-manager", line 11, in
load_entry_point('module-build-service==2.12.2', 'console_scripts',
'mbs-manager')()
File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line
189, in manager_wrapper
manager.run()
File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 417,
in run
result = self.handle(argv[0], argv[1:])
File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 386,
in handle
res = handle(*args, **config)
File "/usr/lib/python3.7/site-packages/flask_script/commands.py", line 216,
in __call__
return self.run(*args, **kwargs)
File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line
154, in build_module_locally
username, handle, str(stream), skiptests, optional_params)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py",
line 386, in submit_module_build_from_yaml
return submit_module_build(username, None, mmd, optional_params)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py",
line 486, in submit_module_build
mmds = generate_expanded_mmds(db.session, mmd, raise_if_stream_ambigous,
default_streams)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py",
line 345, in generate_expanded_mmds
current_mmd, default_streams, raise_if_stream_ambigous)
File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py",
line 276, in get_mmds_required_by_module_recursively
.format(base_module_choices))
module_build_service.errors.UnprocessableEntity: None of the base module
(platform) streams in the buildrequires section could be found
error: mbs-manager build_module_locally failed
error: log: None
From this error message, it's unclear to me what I need to install.
feedreader.yaml has:
- buildrequires:
flatpak-runtime: [f29]
requires:
flatpak-runtime: [f29]
so I've tried to do 'dnf install flatpak-runtime' but the package doesn't seem
to be available.
Next, I thought I'd try building it in koji. Not sure how to do that, the docs
are fairly vague, mentioning 'git push origin master' but I don't have anything
really to push, the existing git doesn't seem to refer to package versions or
anything. I figured that maybe it somehow magically connects it to dist-git
rpms/feedreader and gets the sources there so I've tried just 'fedpkg
module-build' without pushing anything to modules/flatpak, but that fails again
with the familiar missing buildrequires error:
$ fedpkg module-build
Submitting the module build...
Could not execute module_build: The build failed with:
None of the base module (platform or bootstrap) streams in the buildrequires
section could be found
Is the flatpak building actually working for anyone? What am I doing wrong? How
do I specify what version to actually build?
Thanks,
Pete
___
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
libicu 63 update with soname bump in rawhide/F30
Hi, I'm updating icu to 63.1 in rawhide and rebuilding anything that links with libicu. We'll also have a compat package with libicu 62 soname, so I don't expect much rawhide breakage: anything that is currently built with libicu 62 but fails to build with libicu 63 should just continue using the compat package. Thanks, Pete ___ 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: Heads Up: libmodulemd 2.0 coming soon to a Rawhide near you
11.12.2018, 10:29, "Fabio Valentini" : > On Tue, Dec 11, 2018 at 11:05 AM Pete Walter wrote: >> Huh, better to conflict? That's just not true. Conflicting packages are a >> major hurdle that we should try to avoid if at all possible. If it's still >> possible to still change the design of the library (rename the .so file) >> then it certainly makes sense to do so. > > That's nonsense. Compat packages for older versions of the same > library always conflict, on purpose. For an example, look at the > compat-openssl10-devel and openssl-devel packages. Packages are > developed and built against either one version or the other, and > *never* both - and even so, they can't be linked with both versions > simultaneously due to symbol conflicts. Please don't call other people's opinions nonsense. https://docs.fedoraproject.org/en-US/project/code-of-conduct/index.html Anyway, I would say that openssl 1.1 upstream was never designed around distro packaging in mind. They probably assumed that it's fine to have just one version of their headers installed at one time ... which is not the case if you need to work on a piece of software that uses the new API, and another piece of software that uses the old API. Conflicting packages mean repeatedly installing and uninstalling things in that case. Not what I'd call good packaging. compat-openssl10-devel are just a distro hack to make it possible to _build_ stuff in koji against the older API, but it makes it a pain for any developer to use the headers (because of the conflict). >> Look at some well designed libraries, gtk2 and gtk3 for example that can >> exist in parallel and have -devel packages that don't conflict. > > gtk2/3 is a bad example. Those two packages provide two differently > named libraries, not different versions of a library with the same > name (libgtk-x11-2.0.so vs. libgtk-3.so). (Nevermind that the symbols > conflict anyway and nothing can link against both, see the webkit2gtk3 > / gtk2 plugin process mess.) That's unrelated that the runtime libraries have symbol conflicts. We were talking about -devel parallel installability. >> Of course, you could make an argument that it is different there because >> gtk has longer lifetime than libmodulemd, but it still makes sense to do >> things right if we can and not make packages unnecessarily conflict. It's >> just good design that way. > > It's good design to allow broken installations and development > environments? I'd argue not. Please don't move the goal posts. Symbol conflicts is a completely different issue and conflicting -devel packages changes nothing there. If the devel packages conflict, it just makes it so much harder to use Fedora to actually develop software. It's fine for package building purposes, of course, but actually developing stuff is what I enjoy doing on Fedora. Pete ___ 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: Heads Up: libmodulemd 2.0 coming soon to a Rawhide near you
10.12.2018, 19:22, "Neal Gompa" : > On Mon, Dec 10, 2018 at 2:06 PM Kalev Lember wrote: >> On 12/10/2018 07:30 PM, Stephen Gallagher wrote: >> > It is versioned, actually. The 1.x API is `pkconfig(modulemd)` and 2.x >> > is `pkgconfig(modulemd-2.0)`. The source of the conflict between the >> > two -devel subpackages is that they both want to own >> > /usr/lib64/libmodulemd.so, symlinked to different objects. >> >> Perhaps it would then make sense to rename libmodulemd.so to >> libmodulemd-2.so in 2.x, so they don't conflict? > > No. It's better that the development subpackages conflict. There's > zero reason for them to be co-installable. Huh, better to conflict? That's just not true. Conflicting packages are a major hurdle that we should try to avoid if at all possible. If it's still possible to still change the design of the library (rename the .so file) then it certainly makes sense to do so. Look at some well designed libraries, gtk2 and gtk3 for example that can exist in parallel and have -devel packages that don't conflict. Of course, you could make an argument that it is different there because gtk has longer lifetime than libmodulemd, but it still makes sense to do things right if we can and not make packages unnecessarily conflict. It's just good design that way. Pete ___ 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
HEADS UP: xml-security-c 2.0 in rawhide
Hi, I've updated xml-security-c from 1.7.3 to 2.0.2 in rawhide. This includes a soname bump. I'm going to start rebuilds for affected packages shortly: libdigidocpp opensaml xmltooling Pete ___ 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: libicu 62 update with soname bump in rawhide/F29
09.07.2018, 20:34, "Pete Walter" : > Hi, > > I'm updating icu to 62.1 in rawhide and rebuilding anything that links with > libicu. We'll also have a compat package with libicu 61 soname, so I don't > expect much rawhide breakage: anything that is currently built with libicu 61 > but fails to build with libicu 62 should just continue using the compat > package. Hi, All the builds are now done. Quite a bit of unrelated build failures this time from both gcc buildroot removal and /usr/bin/python removal. I fixed up the gcc removal issues as this was super quick, but the rest of the build failures are now up to package maintainers to fix. This is the list of reimaining failures: 0ad: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104677 389-dsgw: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104669 apfs-fuse: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104679 idzebra: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104671 ledger: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104700 libreoffice: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104722 nodejs-node-stringprep: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104705 qt5-qtbase: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104711 qt5-qtwebengine: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104715 qt5-qtwebkit: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104713 rubygem-charlock_holmes: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104673 sword: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104676 v8-314: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104728 v8: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104730 webkit2gtk3: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104731 widelands: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104680 xiphos: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104732 zorba: https://koji.fedoraproject.org/koji/buildinfo?buildID=1104674 Pete ___ 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/JE2JL37H4TCWCBJWOG7ROGZPAFUHGPQW/
libicu 62 update with soname bump in rawhide/F29
Hi, I'm updating icu to 62.1 in rawhide and rebuilding anything that links with libicu. We'll also have a compat package with libicu 61 soname, so I don't expect much rawhide breakage: anything that is currently built with libicu 61 but fails to build with libicu 62 should just continue using the compat package. Thanks, Pete ___ 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/MH2P6BHSHMTTKHOG2NPHSRQ4FZGQLWCD/
Re: libicu upgrade to 61.1 with soname bump in rawhide/F29
01.05.2018, 19:05, "Jonathan Wakely" : > On 26/04/18 19:49 +0200, Eike Rathke wrote: >> Hi, >> >> I'm upgrading libicu to 61.1 for rawhide, which as usual comes with >> a soname bump. I requested a side target f29-icu for the builds, I'll >> ask Pete Walter (who already did it for 60.1) to help with rebuilding >> the dependent packages, or another proven packager if he's not >> available. > > I see that your rebuild of ledger failed due to my boost packaging > changes: > https://koji.fedoraproject.org/koji/taskinfo?taskID=26686488 > > I've fixed the build to work now (by adding boost-python2-devel) but > it will need to be bumped again and rebuilt in your f29-icu side tag. Done. Pete ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ICU 60.1 coming to rawhide/F28
14.12.2017, 12:07, "Eike Rathke" : > Hi Pete, > > On Friday, 2017-12-01 17:29:00 +, Pete Walter wrote: > >> Here's a quick update: icu 60.1 is now built and the rebuilds are all done >> and releng just tagged all the builds over from the f28-icu side tag to f28. >> >> A few of the rebuilds failed. I'd appreciate if the maintainers of the >> packages could take a look and help fix them up. Here's the full list of >> packages that failed to rebuild against icu 60.1: >> >> fontmatrix-0.9.99-32.r1218.fc27.src.rpm >> gnucash-2.6.18-2.fc28.src.rpm >> mozjs38-38.8.0-7.fc28.src.rpm >> mozjs45-45.9.0-5.fc28.src.rpm >> nodejs-mapnik-3.6.2-5.fc27.1.src.rpm >> nodejs-node-stringprep-0.7.3-16.fc28.src.rpm >> openttd-1.7.1-3.fc27.src.rpm >> qt5-qtwebengine-5.9.3-1.fc28.src.rpm >> soletta-1-1.fc26.src.rpm >> v8-314-3.14.5.10-7.fc27.src.rpm > > What's the status of this now? Pretty much the same. Kevin Kofler fixed qt5-qtwebengine but the rest still don't build with rawhide's icu 60.1. It's not the end of the world though as compat-libicu57 provides the old soname and the non-rebuilt packages continue working because of that. If anyone wants to look at fixing one of the above packages, I'd prioritize mozjs38 as it's pulled onto Workstation install media. Pete ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ICU 60.1 coming to rawhide/F28
Here's a quick update: icu 60.1 is now built and the rebuilds are all done and releng just tagged all the builds over from the f28-icu side tag to f28. A few of the rebuilds failed. I'd appreciate if the maintainers of the packages could take a look and help fix them up. Here's the full list of packages that failed to rebuild against icu 60.1: fontmatrix-0.9.99-32.r1218.fc27.src.rpm gnucash-2.6.18-2.fc28.src.rpm mozjs38-38.8.0-7.fc28.src.rpm mozjs45-45.9.0-5.fc28.src.rpm nodejs-mapnik-3.6.2-5.fc27.1.src.rpm nodejs-node-stringprep-0.7.3-16.fc28.src.rpm openttd-1.7.1-3.fc27.src.rpm qt5-qtwebengine-5.9.3-1.fc28.src.rpm soletta-1-1.fc26.src.rpm v8-314-3.14.5.10-7.fc27.src.rpm Cheers, Pete ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ICU 60.1 coming to rawhide/F28
28.11.2017, 15:52, "Eike Rathke" : > What ABI compat package? A parallel installable package that would temporarily provide ICU 57 libraries (but not development headers) so that packages that fail to rebuild with ICU 60 can be fixed gradually and keep on working in the mean time. Otherwise composes fall over if one package fails to rebuild etc and QA comes after us with pitchforks. > Let's do builds on a side tag, unless you have a better plan? Sure, good idea. I have now requested the side tag here: https://pagure.io/releng/issue/7187 Pete ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
ICU 60.1 coming to rawhide/F28
Hi all, Eike Rathke and I are working on updating ICU from 57.x to 60.x in rawhide/F28. It includes a soname bump and has a few API changes. We'll do an ABI compat package to avoid breaking the world while rebuilds are ongoing. We'll import it some time this week and I'll be coordinating rebuilds through my provenpackager powers. Thanks, Pete ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Reminder: upcoming retirement of webkitgtk and webkitgtk3 packages
Looks like this was done without involving FESCo and without going through a proper Change process. I don't think it's a proper way to approach it like this as it breaks a large part of the distro. I would like to unretire webkitgtk3 as removing it breaks one of my packages (bijiben). My intention is to keep maintaining the webkitgtk3 package until bijiben gets ported to something else. I took ownership in pkgdb, but it appears to be still blocked in koji. Does anyone know how I can get it unblocked? Pete 14.03.2017, 19:29, "Michael Catanzaro" : > On Mon, 2017-01-23 at 07:35 -0600, Michael Catanzaro wrote: >> Hi, >> >> This is a reminder that the webkitgtk and webkitgtk3 packages will be >> retired from rawhide shortly after F26 is branched from rawhide. This >> is due to numerous security issues affecting those packages (I just >> counted 204 CVEs), many of which could allow remote code execution. >> Bugs have already been filed against all directly-affected packages >> [1]. > > Hi, > > This is now complete in rawhide. The packages have *not* been retired > from F26, so if this broke your package you have the rest of the F27 > development cycle to decide how to handle it. The best option is to > port to the modern webkitgtk4 package, but alternatively you could try > bundling older WebKit with your package. > > Michael > ___ > 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
Re: Packages seeking new Point Of Contact
28.06.2016, 19:49, "Kevin Fenzi" : > rpms/conduit -- A synchronization solution for GNOME ( master f24 f23 f22 > ) > rpms/gmime -- Library for creating and parsing MIME messages ( epel7 el6 > el5 ) > rpms/goocanvas -- A new canvas widget for GTK+ that uses cairo for > drawing ( master f24 f23 f22 ) > rpms/pygoocanvas -- GooCanvas python bindings ( master f24 f23 f22 ) I picked these 4 up, co-maintainers welcome. Pete -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaning blueman
21.06.2016, 22:58, "Dan Book" :Hello, The blueman package has been orphaned by previous maintainer leigh123linux. It is an important service (bluetooth support) for the Cinnamon, MATE, XFCE, and other desktops, so if anyone is willing and capable, a new maintainer would be appreciated. I picked it up so it doesn't get retired at least. Pete-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HEADS UP] libgit2 bump to 0.24.0
20.03.2016, 10:49, "Igor Gnatenko" :I'm updating libgit2 stack to 0.24.0 in rawhide. Can you do it in F24 as well, please? Thanks-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Retire a package from Fedora i686 (not x86_64)
07.11.2015, 12:19, "Germano Massullo" : > [10:11] Germano: also feel free to refer those guys here to > us if they have questions. seems to me that some direct contact may be > better. What those guys? The only one who wants to kill off darktable is you, Germano. You almost succeeded last time and had it removed, before the community stepped in. Why are you trying to repeat it again? Seriously. Just let darktable be. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retire a package from Fedora i686 (not x86_64)
06.11.2015, 22:11, "Germano Massullo" :For example, SSE3 instructions set is one of the minimum requirements and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott architecture supports it. Prescott is 11 years old. I would expect vast majority of people who are currently running 32 bit Fedora to have newer computers. I would go even as far as to say that nobody who has an older than a 11 year old computer would even try to launch Darktable. And your solution is to just kill it off, because a few ancient computers can't run it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retire a package from Fedora i686 (not x86_64)
06.11.2015, 17:18, "Germano Massullo" : > I just removed 32bit CPU support from Darktable's spec file due > technical reasons. It is hard to help if you just say "due to technical reasons". What are they? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Copr for FeedReader
04.09.2015, 21:18, "Jan Lukas" :Okay, here it is: https://launchpad.net/feedreader/1.2/1.2.1/+download/FeedReader-1.2.1.tar.gzNow with license and build-time-switch for webkit2gtk so you don't have to replace 3.0 with 4.0 in the CMakeLists.txt anymore (use -DUSE_WEBKIT_4=ON) Already updated :) Thanks!One other thing I forgot to mention in my previous email is that FeedReader shows up without an icon in GNOME Shell app launcher. It appears to be so because its desktop file says 'Icon=internet-news-reader', but internet-news-reader is not installed by the standard icon theme. Any chance you could copy the icon in the app and install it in the hicolor icon theme, under feedreader.png/.svg name? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Copr for FeedReader
04.09.2015, 14:19, "Jan Lukas" :Already done. I will release something like a 1.2.1 soon (with the license), since I received a few bug reports after the release :) Thanks. I see you've now released 1.2.1, so I went ahead and updated my spec file as well in https://bugzilla.redhat.com/show_bug.cgi?id=1259532 If any packager sponsors are around, I'd love comments in the ticket. Thanks. Jan, I have a patch for the appdata file to make it validate. Can you push it upstream please? I'm attaching it to the email here as launchpad with its bazaar repos is too complicated for me. Peterdiff -up feedreader-1.2.1/data/feedreader.appdata.xml.orig feedreader-1.2.1/data/feedreader.appdata.xml --- feedreader-1.2.1/data/feedreader.appdata.xml.orig 2015-09-04 18:54:26.625264681 +0100 +++ feedreader-1.2.1/data/feedreader.appdata.xml 2015-09-04 18:54:31.866265133 +0100 @@ -1,11 +1,11 @@ -â - + + feedreader.desktop CC0 GPL-3.0+ FeedReader RSS client for various webservices -â + FeedReader is a program designed to complement an already existing web-based @@ -16,32 +16,40 @@ Tiny Tiny RSS Feedly - â + It combines all the advantages of web based services like synchronisation across all your devices with everything you expect from a modern desktop application: Desktop notifications, fast search and filters, tagging, sharing to "read-it-later" services like pocket and instapaper, handy keyboard shortcuts and a database that keeps all your old articles as long as you like. - â + -â + - The main window - http://www.something.something/feedreader/main.png + https://raw.githubusercontent.com/jangernert/feedreader/master/Screenshot1.png + + + https://raw.githubusercontent.com/jangernert/feedreader/master/Screenshot2.png + + + https://raw.githubusercontent.com/jangernert/feedreader/master/Screenshot3.png + + + https://raw.githubusercontent.com/jangernert/feedreader/master/Screenshot4.png - http://www.something.something/feedreader/preferences.png + https://raw.githubusercontent.com/jangernert/feedreader/master/Screenshot5.png -â - http://www.something.something/feedreader + + http://jangernert.github.io/feedreader/ elementaryOS -â + feedreader feedreader-daemon -â + @@ -49,4 +57,4 @@ -â + -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Copr for FeedReader
03.09.2015, 12:57, "Miroslav Suchý" : > Dne 3.9.2015 v 00:16 janlukasgern...@freenet.de napsal(a): >> repo is now available here. > > I assume this one: > https://copr.fedoraproject.org/coprs/jeanluc/FeedReader/ > :) > > It looks good. Although the spec from Pete looks little bit better. You may > want to add yourself to CC of > https://bugzilla.redhat.com/show_bug.cgi?id=1259532 > and then join as co-maintainer. I received a comment on the review ticket pointing out that the tarball lacks a license (COPYING) file. janlukasgernert, can you add it for the next release? Thanks! Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Copr for FeedReader
On 09/02/2015 01:00 PM, Vít Ondruch wrote: > Dne 1.9.2015 v 22:00 janlukasgern...@freenet.de napsal(a): >> >> Hi, >> >> I was advised to ask on this list for help regarding setting up a copr >> repository. > > Why Copr and not Fedora official package? Is there something which > conflicts with Fedora's Packaging Guidelines [1]? Otherwise I can't see > Copr to be less maintenance effort then official package (except the > initial review). I posted a review request at https://bugzilla.redhat.com/show_bug.cgi?id=1259532 to include it in Fedora proper, but I am not a packager yet and would need a sponsor. Cheers, Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Boost and Python 3 in f18
Petr Machata redhat.com> writes: > > David Malcolm redhat.com> writes: > > > Petr: What is the status of this? > > I was told by dgilmore to put a request in the boost side tag ticket > earlier today. I promptly did that. dgilmore said he was about to > branch f18, and would prefer to merge boost soon, so it seems like he > knows about this, and it's now just a matter of time. Maybe keep it f19 only now that it missed the f18 branching? The alpha release is looming closer and closer, and merging something that breaks tons of deps doesn't seem like a great idea at this point ... Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
Pavel Alexeev hubbitus.com.ru> writes: > May be in next time? What disadvantages you are seen proceed with that > update? Do you try test it? No, I did not test this. And here's a few reasons why I think this shouldn't be pushed: - You are forcing others to do work they otherwise wouldn't need to do. Why do you want me to test ImageMagick functionality in 57 dependant packages? Fix your security bugs and leave other packages alone. F16 is supposed to be stable. - A major ImageMagick update that introduces new features and new code invalidates the QA that has gone into the packages that use ImageMagick. - Needless update churn. We have the Stable Updates Policy for a reason. Do you development on rawhide and let stable Fedora release be stable. - The soname bump breaks third party packages that use ImageMagick libraries. An example is 'transcode' from rpmfusion. http://fedoraproject.org/wiki/Updates_Policy explicitly says that such ABI bumps are left to the discretion of FESCO and the packager. Have you already asked FESCO for their blessing? "Note that you should open this dialog _BEFORE_ you build or push updates." Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick in Fedora 16
Pavel Alexeev hubbitus.com.ru> writes: > If you or other will insist I may unpush that update and try patch > IM for all issues off course... But I really do not want doing it > now. In my opinion, the right way to handle this is to backport the security fixes. You even have patches linked to each of the security bugs on bugzilla.redhat.com. And yes, this means unpushing the update with the soname bump. Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
