Re: aobook - reviving review request?
Andy Mender wrote on 2020/08/12 4:49: Hello all :) I was just going through the swath of "needinfo cancelled" emails and a certain package piqued my interest: https://bugzilla.redhat.com/show_bug.cgi?id=1289070 Just wanted to clarify, if I'm interested in this package, the closed bug report should not be re-opened and instead I should open a new one and request a review, correct? As a beginner Japanese learner this package is of personal interest, but it might be useful to other people as well. Cheers, Andy If you are interested, I can prepare and submit a new review request, and assign reviewer to you. Regards, Mamoru ___ 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: Proposed Modular Policy for Fedora ELN
On Thu, Aug 6, 2020, at 10:45 AM, Miro Hrončok wrote: > On 05. 08. 20 21:36, Stephen Gallagher wrote: > > FESCo has requested that I submit the module policy once more to the > > Fedora development list for discussion. Feedback is welcome. > > > > == Requirements for Default Streams > > * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN > > permits defaults streams that adhere to the policy below. > > Since this has been discussed at lengths at FESCo and this is the first time > it > has been brought here (thanks for doing it, Stephen), let me summarize my > concerns with allowing default modular streams in ELN. > > I would like to know if my concerns are valid or if I am just biased. Sorry > for > the long email. > The concerns sound valid to me. Despite the concerns, it sounds like the decision has been made to have Default Streams in RHEL Next, so we should develop an appropriate policy for them in ELN. Let's not impede RHEL development unnecessarily, but let's work to make RHEL better. Part of that might be convincing the powers-that-be to give up default streams, but the topic that started this thread is "what is the policy, assuming they've already been allowed." > > Fedora has experimented with default modular streams for several > releases and we > seemed to be at an agreement that the experiment has failed: > > See https://pagure.io/fesco/issue/2406 which includes links to relevant > previous > discussions on the topic. Admitting that default modular streams are > bad took as > nearly two years, despite a few loud and persistent individuals > pointing it out > since the beginning. > > While I understand the original idea behind the concept of default modular > streams concept, shipping defaults via non-modular content has been proven > superior to default modular streams -- it has been proven that default > modular > streams cannot be better than nonmodular defaults and that they can only try > to > be as good as them, while they are currently technologically failing to do > that: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D2LQ6C6FHDS2LMKPDGCLFJDNHAPA6Q2B/ > > > The currently proposed modularity objective for Fedora admits that this > won't be > fixed until ta least Fedora 35 and later: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RF4GUWFIDIASBDKS2RUVDHTSAWCMCWL4/ > > The current modularity tech-lead strongly discourages default modular streams: > > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310 > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122502 > > > Yet despite all this, we got a proposal to allow default modular streams in > ELN. > The messaging about this proposal suggests that later, default modular > streams > might be proposed for Fedora as well. > > > """At present, these rules will apply only to Fedora ELN, but are written in > such a way as to be reusable for Fedora and EPEL in the future through > another > Change Proposal.""" -- https://fedoraproject.org/wiki/Changes/ModularPolicy > > > Fedora has decided that default modular streams are no-go. While I > admit that > such a decision can be reverted at any time based on significant > changes in the > technology, such changes have not happened and are not planned. Yet > strong > supporters of default modular streams try to allow them again and > again, despite > the enormous amount of feedback they've received including the feedback > from the > current modularity team and tech lead. > > > I sincerely don't understand the RHEL's need for default modular streams, but > when I tried to query the motivation behind this, the answers haven't made it > any better: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YIUXL2AWY3GKITU4TBUSKL2IUHDUPB26/ > > The idea that we let the maintainers decide how they want to ship the default > content is exactly what failed in Fedora in the first place. But if RHEL > people > feel strongly that we need default modular steams to succeed, so be it. What > I > don't understand is why do we need this in Fedora (ELN). It boils down to > this: > Is ELN part of Fedora and should it follow Fedora's feedback and Fedora's > opinions, or is it a RHEL project executed in the open, with decisions made > behind closed doors? > > I've heard several times that we need to have default modular streams in > Fedora > ELN to have a place to test them. In my opinion, we had this place, it was in > Fedora, we have tested them and they failed. Hence I don't understand what's > more there to test. > > OTOH, why don't just let the ELN SIG do this if it doesn't affect > "Fedora > proper"? Because I think it does. Since the beginning of the ELN > project, it has > been said that it ships Fedora rawhide content, built differently. Yet > if we > ship the defa
Re: btrfs default partitioning/subvolume
On Tue, Aug 11, 2020 at 7:55 AM Neal Becker wrote: > > I wonder if there's any information or discussion on the default partitioning > and subvoluming > scheme to be used for btrfs install? > > The only scheme I've used so far in the past is a single large partition with > one subvolume for /home and another for /root. I think it might be good to > have another for /snapshots. Hi, yeah it's a good question. There's some discussion upstream exploring a "big picture" approach. https://lore.kernel.org/linux-btrfs/20200721203340.275921-1-kreij...@libero.it/ I think Fedora needs a buttoned down design for a snapshot regime before creating more subvolumes or changing the layout, by default. There's nothing wrong with folks doing it themselves. We'll also have some docs on doing that so people who like to experiment and iterate, can do that. Btrfs subvolumes can go anywhere. They can be nested. Or they can all be at the top-level of the file system, and mounted into position by fstab options (or native system mount units) or a combination of the two. They can be read-only or writable. The nested approach seems cleaner at first, but then means rollback logic needs to be more sophisticated. Since there won't be automatic snapshots and rollbacks in Fedora 33, there's some breathing room to be deliberate about any changes to the default layout, and discuss alternatives/supplements. Is it useful and practical to make system rescue and reprovisioning easier as well? A location for snapshots is a good idea. Ages ago I asked some security folks about keeping snapshots of old binaries and libraries out of the search path, e.g. put them in a (temporarily mounted) top-level or snapshots subvolume, and they thought it seemed like a good idea. Maybe using nosuid noexec is enough. There's also native Btrfs encryption on the way later this year, that will leverage the existing kernel fscrypt implementation. That might have an impact on the design. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Mass Branching
On 12. 08. 20 1:09, Mohan Boddu wrote: On Tue, Aug 11, 2020 at 12:56 PM Tom Stellard wrote: On 8/11/20 12:44 PM, Kevin Fenzi wrote: On Mon, Aug 10, 2020 at 05:39:02PM -0700, Tom Stellard wrote: On 8/9/20 3:16 PM, Mohan Boddu wrote: Hello All, Fedora 33 will be branched from rawhide on August 11th 2020 as per the Fedora 33 schedule[1]. The process takes about a day and everything should be ready by August 12th 2020. You can still be able to build packages normally until then, but after the mass branching, rawhide and F33 will be separated. How will this affect any outstanding side-tags that inherit from the f33 tag? Will we need to re-tag the packages into an f34-based side-tag? Those side tags will continue to exist and point to f33/branched. You will want to create new f34 ones and build out things in those. Do I need to rebuild everything or can I just tag the current builds into the new f34 side-tag? I dont think bodhi will allow you to merge them into f34, you might have to rebuild them again. Note that there is no need to bump the release, as the new builds will have .fc34. -- 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: Fedora 33 Mass Branching
On Tue, Aug 11, 2020 at 09:56:10AM -0700, Tom Stellard wrote: > On 8/11/20 12:44 PM, Kevin Fenzi wrote: > > On Mon, Aug 10, 2020 at 05:39:02PM -0700, Tom Stellard wrote: > > > On 8/9/20 3:16 PM, Mohan Boddu wrote: > > > > Hello All, > > > > > > > > Fedora 33 will be branched from rawhide on August 11th 2020 as per the > > > > Fedora 33 schedule[1]. The process takes about a day and everything > > > > should be ready by August 12th 2020. You can still be able to build > > > > packages normally until then, but after the mass branching, rawhide > > > > and F33 will be separated. > > > > > > > > > > How will this affect any outstanding side-tags that inherit from the f33 > > > tag? Will we need to re-tag the packages into an f34-based side-tag? > > > > Those side tags will continue to exist and point to f33/branched. > > > > You will want to create new f34 ones and build out things in those. > > > > Do I need to rebuild everything or can I just tag the current builds into > the new f34 side-tag? I suppose you could do either... but it seems 'cleaner' to me to rebuild them. (they will get fc34 dist tags, etc). As time progresses the two will diverge more and more. So it's likely fine right now, might be ok tomorrow, then not so much. kevin 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: Review swaps
On Sun, Aug 9, 2020 at 1:44 PM Jerry James wrote: > Hello everybody. The latest version of ocaml-ppx-inline-test requires > ocaml-time-now, which we do not currently have in Fedora. That > package is at the terminus of a small tree of dependencies we don't > have. I would like to swap reviews for the following. Please let me > know what I can review for you in exchange. Thanks to Jared, #1 and #2 are done. Who has packages sitting in the review queue? You scratch my back and I'll scratch yours ... from 6 feet away while wearing masks, of course. Here is the rest of what I need: 3. ocaml-ppx-here https://bugzilla.redhat.com/show_bug.cgi?id=1862619 4. ocaml-ppx-assert, depends on 2 and 3 https://bugzilla.redhat.com/show_bug.cgi?id=1862620 5. ocaml-jst-config, depends on 4 https://bugzilla.redhat.com/show_bug.cgi?id=1862621 6. ocaml-ppx-enumerate https://bugzilla.redhat.com/show_bug.cgi?id=1862622 7. ocaml-ppx-hash https://bugzilla.redhat.com/show_bug.cgi?id=1862623 8. ocaml-octavius https://bugzilla.redhat.com/show_bug.cgi?id=1862624 9. ocaml-ppx-js-style, depends on 8 https://bugzilla.redhat.com/show_bug.cgi?id=1862625 10. ocaml-ppx-optcomp https://bugzilla.redhat.com/show_bug.cgi?id=1862626 11. ocaml-ppx-base, depends on 2, 6, 7, 9, and 10 https://bugzilla.redhat.com/show_bug.cgi?id=1862627 12. ocaml-time-now, depends on 1, 5, and 11 https://bugzilla.redhat.com/show_bug.cgi?id=1862628 Thanks! -- 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 33 Mass Branching
On Tue, Aug 11, 2020 at 12:56 PM Tom Stellard wrote: > > On 8/11/20 12:44 PM, Kevin Fenzi wrote: > > On Mon, Aug 10, 2020 at 05:39:02PM -0700, Tom Stellard wrote: > >> On 8/9/20 3:16 PM, Mohan Boddu wrote: > >>> Hello All, > >>> > >>> Fedora 33 will be branched from rawhide on August 11th 2020 as per the > >>> Fedora 33 schedule[1]. The process takes about a day and everything > >>> should be ready by August 12th 2020. You can still be able to build > >>> packages normally until then, but after the mass branching, rawhide > >>> and F33 will be separated. > >>> > >> > >> How will this affect any outstanding side-tags that inherit from the f33 > >> tag? Will we need to re-tag the packages into an f34-based side-tag? > > > > Those side tags will continue to exist and point to f33/branched. > > > > You will want to create new f34 ones and build out things in those. > > > > Do I need to rebuild everything or can I just tag the current builds > into the new f34 side-tag? I dont think bodhi will allow you to merge them into f34, you might have to rebuild them again. > > -Tom > > > kevin > > > > > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Schedule for Wednesday's FESCo Meeting (2020-08-12)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2020-08-12 14:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = F34 System-Wide Change: NSS CK_GCM_PARAMS change https://pagure.io/fesco/issue/2400 APPROVED (+4,0,-0) Update 3rd party repo policy https://pagure.io/fesco/issue/2416 APPROVED (+3,0,-0) F33 Self-Contained Change: DXVK as default wined3d backend on VK capable hardware https://pagure.io/fesco/issue/2456 APPROVED (+8,0,-0) F33 Self-Contained Change: Reserve resources for active users (Workstation) https://pagure.io/fesco/issue/2457 APPROVED (+9,0,-0) F33 Self-Contained Change: Ruby on Rails 6.0 https://pagure.io/fesco/issue/2458 APPROVED (+9,0,-0) F33 Self-Contained Change: X.org Utility Deaggregation https://pagure.io/fesco/issue/2459 APPROVED (+9,0,-0) = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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
aobook - reviving review request?
Hello all :) I was just going through the swath of "needinfo cancelled" emails and a certain package piqued my interest: https://bugzilla.redhat.com/show_bug.cgi?id=1289070 Just wanted to clarify, if I'm interested in this package, the closed bug report should not be re-opened and instead I should open a new one and request a review, correct? As a beginner Japanese learner this package is of personal interest, but it might be useful to other people as well. Cheers, 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
Fedora rawhide compose report: 20200811.n.0 changes
OLD: Fedora-Rawhide-20200810.n.0 NEW: Fedora-Rawhide-20200811.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 0 Dropped packages:9 Upgraded packages: 134 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:11.26 MiB Size of upgraded packages: 4.71 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -15.46 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20200811.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: lpg-2.0.17-33.fc33 Summary: LALR Parser Generator RPMs:lpg lpg-java lpg-java-compat Size:3.32 MiB Package: okteta4-4.14.3-65.fc32 Summary: Binary/hex editor for KDE4 RPMs:okteta4-devel okteta4-libs Size:5.93 MiB Package: python-gerrit-view-0.4.6-6.fc33 Summary: A set of tools to query/view Gerrit patch reviews and their Zuul status RPMs:python3-gerrit-view Size:31.59 KiB Package: python-jupyterlab-launcher-0.13.1-2.fc33 Summary: JupyterLab Launcher RPMs:python3-jupyterlab-launcher Size:51.38 KiB Package: rubygem-compass-import-once-1.0.5-14.fc33 Summary: Speed up your Sass compilation by making @import only import each file once RPMs:rubygem-compass-import-once rubygem-compass-import-once-doc Size:227.59 KiB Package: rubygem-occi-api-4.3.15-7.fc33 Summary: OCCI development library providing a high-level client API RPMs:rubygem-occi-api rubygem-occi-api-doc Size:326.96 KiB Package: rubygem-rhc-1.38.7-10.fc33 Summary: OpenShift Express Client Tools RPMs:rubygem-rhc rubygem-rhc-doc Size:858.00 KiB Package: rubygem-rmail-sup-1.0.1-12.fc33 Summary: A lightweight mail library written in ruby RPMs:rubygem-rmail-sup rubygem-rmail-sup-doc Size:427.07 KiB Package: viewmtn-0.10-26.20100308mtn0030ad67.fc32 Summary: Web interface for Monotone version control system RPMs:viewmtn Size:136.20 KiB = UPGRADED PACKAGES = Package: Box2D-2.4.0-1.fc33 Old package: Box2D-2.3.1-15.fc33 Summary: A 2D Physics Engine for Games RPMs: Box2D Box2D-devel Size: 3.54 MiB Size change: 340.86 KiB Changelog: * Mon Aug 10 2020 Gwyn Ciesla - 2.4.0-1 - 2.4.0 with patch for cmake shared libs. Package: GoldenCheetah-1:3.6-0.1.20200808git7c90abf.fc33 Old package: GoldenCheetah-4.0-0.2.20200614git5c84f7f.fc33 Summary: Cycling Performance Software RPMs: GoldenCheetah GoldenCheetah-data GoldenCheetah-doc Size: 35.18 MiB Size change: 788.18 KiB Changelog: * Sun Aug 09 2020 Martin Gansser - 3.6-0.1.20200908git7c90abf - Revert version 4.0 and use master git - Add epoch to allow install older version Package: InsightToolkit-4.13.3-1.fc33 Old package: InsightToolkit-4.13.1-5.fc33 Summary: Insight Toolkit library for medical image processing RPMs: InsightToolkit InsightToolkit-devel InsightToolkit-doc InsightToolkit-examples InsightToolkit-vtk InsightToolkit-vtk-devel Size: 77.17 MiB Size change: -436.35 KiB Changelog: * Mon Jul 27 2020 Fedora Release Engineering - 4.13.1-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Aug 01 2020 Fedora Release Engineering - 4.13.1-7 - Second attempt - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Wed Aug 05 2020 Orion Poplawski - 4.13.3-1 - Update to 4.13.3 - Use new cmake macros - Disable LTO for now - Disable gold linker Package: R-ape-5.4-3.fc33 Old package: R-ape-5.4-2.fc33 Summary: Analyses of Phylogenetics and Evolution RPMs: R-ape Size: 11.32 MiB Size change: -31.84 KiB Changelog: * Mon Aug 10 2020 Tom Callaway - 5.4-3 - rebuild for FlexiBLAS R Package: R-expm-0.999.4-8.fc33 Old package: R-expm-0.999.4-7.fc33 Summary: Computation of the matrix exponential and related quantities RPMs: R-expm Size: 1.07 MiB Size change: -698 B Changelog: * Mon Aug 10 2020 Tom Callaway - 0.999.4-8 - rebuild for FlexiBLAS R Package: R-gee-4.13.20-5.fc33 Old package: R-gee-4.13.20-4.fc33 Summary: Generalized Estimation Equation Solver RPMs: R-gee Size: 309.60 KiB Size change: -737 B Changelog: * Mon Aug 10 2020 Tom Callaway - 4.13.20-5 - rebuild for FlexiBLAS R Package: R-gss-2.2.2-4.fc33 Old package: R-gss-2.2.2-3.fc33 Summary: General Smoothing Splines RPMs: R-gss Size: 8.24 MiB Size change: 1.64 KiB Changelog: * Mon Aug 10 2020 Tom Callaway - 2.2.2-4 - rebuild for FlexiBLAS R Package: R-igraph-1.2.5-4.fc33 Old package: R-igraph-1.2.5-3.fc33 Summary: Network Analysis and Visualization RPMs: R-igraph Size: 17.75 MiB Size change: -10.09 KiB Changelog: * Mon Aug 10 2020 Tom Callaway - 1.2.5-4 - rebuild for FlexiBLAS
[Test-Announce] Fedora 33 Rawhide 20200811.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 33 Rawhide 20200811.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20200804.n.0: anaconda-33.24-1.fc33.src, 20200811.n.0: anaconda-33.25-1.fc33.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/33 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200811.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200811.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200811.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200811.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200811.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200811.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_33_Rawhide_20200811.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@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: Fedora 33 Mass Branching
On 8/11/20 12:44 PM, Kevin Fenzi wrote: On Mon, Aug 10, 2020 at 05:39:02PM -0700, Tom Stellard wrote: On 8/9/20 3:16 PM, Mohan Boddu wrote: Hello All, Fedora 33 will be branched from rawhide on August 11th 2020 as per the Fedora 33 schedule[1]. The process takes about a day and everything should be ready by August 12th 2020. You can still be able to build packages normally until then, but after the mass branching, rawhide and F33 will be separated. How will this affect any outstanding side-tags that inherit from the f33 tag? Will we need to re-tag the packages into an f34-based side-tag? Those side tags will continue to exist and point to f33/branched. You will want to create new f34 ones and build out things in those. Do I need to rebuild everything or can I just tag the current builds into the new f34 side-tag? -Tom kevin ___ 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: Fedora 33 Mass Branching
On Mon, Aug 10, 2020 at 05:39:02PM -0700, Tom Stellard wrote: > On 8/9/20 3:16 PM, Mohan Boddu wrote: > > Hello All, > > > > Fedora 33 will be branched from rawhide on August 11th 2020 as per the > > Fedora 33 schedule[1]. The process takes about a day and everything > > should be ready by August 12th 2020. You can still be able to build > > packages normally until then, but after the mass branching, rawhide > > and F33 will be separated. > > > > How will this affect any outstanding side-tags that inherit from the f33 > tag? Will we need to re-tag the packages into an f34-based side-tag? Those side tags will continue to exist and point to f33/branched. You will want to create new f34 ones and build out things in those. kevin 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: LTO and the F33 mass rebuild
On Sun, Aug 09, 2020 at 10:06:49PM -0600, Jeff Law wrote: > On Sun, 2020-08-09 at 12:02 +0200, Fabio Valentini wrote: > > On Sun, Aug 9, 2020 at 12:03 AM Jeff Law wrote: > > > So I've done two passes over the F33 build failures here: > > > > > > https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html > > > > Hi Jeff, > > > > Thanks for looking at the failures, it's really appreciated! > > > > Be aware that the f33-failures.html page is not complete though, since > > packages for which there was an attempted rebuild *after* the mass > > rebuild are removed from the list, whether the builds succeeded or > > not. So it's possible that you missed builds that fail for LTO-related > > issues, just because they're no longer showing up in the list. The > > list of bugs blocking the F33FTBFS bug in bugzilla [0] might be > > helpful here. And the f33-need-rebuild list [1] should give you a > > complete picture of everything that has not successfully been rebuilt > > for f33 yet. > ACK. I'm poking at the f33-need-rebuild.html list a bit. THere's a lot of > noise > in there -- things that haven't been built in a long time. Anyway, I'll keep > poking around. > > It would be helpful if there was a clean way to download failed log files and > such in batches so that I could run tools on them to look for common things > that > don't need my attention (like all the cmake failures). As it stands I have > to do > an insane amount of clickies to get to some basic data. It's been proposed to enable the koji 'save-failed-tree' plugin: https://pagure.io/releng/issue/8243 It might help for this sort of thing, as it lets you get a complete tar of the entire tree. I'll look into it more after we have staging koji back... kevin 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: Error building sugar-recall
Thanks! -- Ibiam Chihurumnaya ibiamchihurumn...@gmail.com On Tue, Aug 11, 2020 at 5:29 PM Miro Hrončok wrote: > On 11. 08. 20 17:21, Chihurumnaya Ibiam wrote: > > Good day, > > > > I got this error while trying to build a package, > > > > [WARNING] missing AppStream metadata, see `pydoc sugar3.bundle` > > + rm > > > /builddir/build/BUILDROOT/sugar-recall-7-1.fc32.x86_64/usr/share/applications/org.sugarlabs.RecallActivity.activity.desktop > > + %py_byte_compile /usr/bin/python3 > > > /builddir/build/BUILDROOT/sugar-recall-7-1.fc32.x86_64//usr/share/sugar/activities//Recall.activity/ > > /var/tmp/rpm-tmp.BZGgPt: line 41: fg: no job control > > > > Seems it's an issue with py_byte_compile. > > %py_byte_compile lives in python-rpm-macros. You need to BR python3-devel > or > similar in order to get it. > > -- > 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: Error building sugar-recall
On 11. 08. 20 17:21, Chihurumnaya Ibiam wrote: Good day, I got this error while trying to build a package, [WARNING] missing AppStream metadata, see `pydoc sugar3.bundle` + rm /builddir/build/BUILDROOT/sugar-recall-7-1.fc32.x86_64/usr/share/applications/org.sugarlabs.RecallActivity.activity.desktop + %py_byte_compile /usr/bin/python3 /builddir/build/BUILDROOT/sugar-recall-7-1.fc32.x86_64//usr/share/sugar/activities//Recall.activity/ /var/tmp/rpm-tmp.BZGgPt: line 41: fg: no job control Seems it's an issue with py_byte_compile. %py_byte_compile lives in python-rpm-macros. You need to BR python3-devel or similar in order to get it. -- 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: dummy libraries for proprietary dependencies (especially NVIDIA)
On Tue, Aug 11, 2020 at 2:11 PM Dave Love wrote: > Is there the possibility of building packages with dummy shims for > proprietary dynamic libraries that could be substituted at runtime > (i.e. a package BRs dummy-libthing-devel, and dynamic linker paths > provide the nasty real libthing at runtime)? Something like libglvnd, the "Vendor neutral GL dispatch library"? If that's the case, it is perhaps instructive to research the history of that library. In respect to CUDA in particular, there has been work (by Codeplay?) to allow applications written to oneAPI/SYCL to run on top of nvidia CUDA. Or maybe I am entirely misunderstanding your question. ___ 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: dummy libraries for proprietary dependencies (especially NVIDIA)
On Tue, Aug 11, 2020 at 03:11:03PM +0100, Dave Love wrote: > Is there the possibility of building packages with dummy shims for > proprietary dynamic libraries that could be substituted at runtime > (i.e. a package BRs dummy-libthing-devel, and dynamic linker paths > provide the nasty real libthing at runtime)? Obviously there are > potential technical and legal issues involved. I'm interested in > packages which are useful without the proprietary bits (such as parallel > performance tools with multiple targets or computational programs that > otherwise run on the CPU). > > I'm thinking specifically about CUDA and NVIDIA management and > performance stuff, but also more generally. Unfortunately, at least > until AMD GGPUs get well established, NVIDIA support is pretty much de > rigeur in HPC and machine learning application (if that isn't an HPC > subset). I thought about offload in libgomp as an example, but I found > what's involved difficult to follow; it's not immediately clear to me > what interfaces are used, and how. > > I suppose the first question is whether dummy libcuda etc. already > exists that could be used for packaging. I've looked without luck, but > maybe someone here knows. nbdkit provides a plugin[1] that uses VDDK if available. VDDK is a proprietary library with a poisonous license, exactly like the sort of thing you describe. The way it works is to dlopen the library and call the APIs via dlsym. This is hidden somewhat nicely so the plugin[2] looks like it's just calling the functions directly, but in fact it calls them through a function pointer indirection. Depending on how extreme your performance requirements are this might not be suitable, but for VDDK it's fine. There's essentially no packaging requirement at all. nbdkit RPM doesn't contain any proprietary code, doesn't depend on VDDK either at compile or run time, no dummy library is needed, etc. > Second, is the legal position on producing such a thing from header > information clear? I guess that would be a question for the legal > list, but I've failed to get mail to that in the past, and I guess > the answer is generally known. Thanks. You'll need to ask a lawyer (or Fedora legal list) but header files that simply describe APIs are not normally regarded as copyrightable, certain unusual and hopefully temporary judgements in the USA not withstanding. Rich. [1] https://libguestfs.org/nbdkit-vddk-plugin.1.html [2] https://github.com/libguestfs/nbdkit/tree/master/plugins/vddk -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: LTO and the F33 mass rebuild
On Tue, 2020-08-11 at 06:34 -0500, Richard Shaw wrote: > Looks like js8call is failing due to LTO... > > /usr/bin/ld: /tmp/js8call.Y0yEHy.ltrans36.ltrans.o: in function > `EqualizationToolsDialog::~EqualizationToolsDialog()': > /builddir/build/BUILD/js8call-2.2.0/EqualizationToolsDialog.hpp:12: undefined > reference to `pimpl::~pimpl()' > /usr/bin/ld: /tmp/js8call.Y0yEHy.ltrans36.ltrans.o: in function > `EqualizationToolsDialog::~EqualizationToolsDialog()': > /builddir/build/BUILD/js8call-2.2.0/EqualizationToolsDialog.hpp:12: undefined > reference to `pimpl::~pimpl()' > collect2: error: ld returned 1 exit status > > Disabling lto does indeed fix the build (finished while I was writing this). Thanks. For some reason js8call wasn't on the failing webpage. Thanks for taking care of it! 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
Error building sugar-recall
Good day, I got this error while trying to build a package, [WARNING] missing AppStream metadata, see `pydoc sugar3.bundle` + rm /builddir/build/BUILDROOT/sugar-recall-7-1.fc32.x86_64/usr/share/applications/org.sugarlabs.RecallActivity.activity.desktop + %py_byte_compile /usr/bin/python3 /builddir/build/BUILDROOT/sugar-recall-7-1.fc32.x86_64//usr/share/sugar/activities//Recall.activity/ /var/tmp/rpm-tmp.BZGgPt: line 41: fg: no job control Seems it's an issue with py_byte_compile. -- Ibiam Chihurumnaya ibiamchihurumn...@gmail.com ___ 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
dummy libraries for proprietary dependencies (especially NVIDIA)
Is there the possibility of building packages with dummy shims for proprietary dynamic libraries that could be substituted at runtime (i.e. a package BRs dummy-libthing-devel, and dynamic linker paths provide the nasty real libthing at runtime)? Obviously there are potential technical and legal issues involved. I'm interested in packages which are useful without the proprietary bits (such as parallel performance tools with multiple targets or computational programs that otherwise run on the CPU). I'm thinking specifically about CUDA and NVIDIA management and performance stuff, but also more generally. Unfortunately, at least until AMD GGPUs get well established, NVIDIA support is pretty much de rigeur in HPC and machine learning application (if that isn't an HPC subset). I thought about offload in libgomp as an example, but I found what's involved difficult to follow; it's not immediately clear to me what interfaces are used, and how. I suppose the first question is whether dummy libcuda etc. already exists that could be used for packaging. I've looked without luck, but maybe someone here knows. Second, is the legal position on producing such a thing from header information clear? I guess that would be a question for the legal list, but I've failed to get mail to that in the past, and I guess the answer is generally known. 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
btrfs default partitioning/subvolume
I wonder if there's any information or discussion on the default partitioning and subvoluming scheme to be used for btrfs install? The only scheme I've used so far in the past is a single large partition with one subvolume for /home and another for /root. I think it might be good to have another for /snapshots. Thanks, Neal -- *Those who don't understand recursion are doomed to repeat it* ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Zanata removal is soon, please finish migration
Le 11 août 2020 14:20:04 GMT+03:00, "Richard W.M. Jones" a écrit : >On Tue, Aug 11, 2020 at 05:28:26AM -, Jean-Baptiste Holcroft wrote: >> libguestfs https://bugzilla.redhat.com/show_bug.cgi?id=1787301 > >I believe we have now done everything on our side. > >> virt-top > >No bug ..? > >Rich. thanks for pointing you answered already, I'll configure libguestfs tomorrow. i also understand virt-top doesn't require migration (as anyone could create a new project in Zanata, we had many project that doesn't require migration) -- Jean-Baptiste ___ 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: LTO and the F33 mass rebuild
Looks like js8call is failing due to LTO... /usr/bin/ld: /tmp/js8call.Y0yEHy.ltrans36.ltrans.o: in function `EqualizationToolsDialog::~EqualizationToolsDialog()': /builddir/build/BUILD/js8call-2.2.0/EqualizationToolsDialog.hpp:12: undefined reference to `pimpl::~pimpl()' /usr/bin/ld: /tmp/js8call.Y0yEHy.ltrans36.ltrans.o: in function `EqualizationToolsDialog::~EqualizationToolsDialog()': /builddir/build/BUILD/js8call-2.2.0/EqualizationToolsDialog.hpp:12: undefined reference to `pimpl::~pimpl()' collect2: error: ld returned 1 exit status Disabling lto does indeed fix the build (finished while I was writing this). 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
Re: neuro-sig COPR group clean up
On Thu, Aug 06, 2020 20:23:33 +0200, Andy Mender wrote: > On Thu, 6 Aug 2020 at 19:30, Ankur Sinha wrote: > > Hello, > > We've got quite a few unmaintained repos on COPR under the neuro-sig > group. I intend to do a bit of housekeeping to remove projects there > that aren't in use any more. Please take a look and let me know if you > do not want me to delete a project: > > https://copr.fedorainfracloud.org/groups/g/neurofedora/coprs/ > > I will delete all projects apart from the neurofedora-extra copr on > Monday, the 10th of August. > > > Of some interest to me would be the python-joblib package, but I see that a > more recent version is already in the repos. Yes, the COPRs haven't been updated in some time. I've deleted the inactive ones now. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: Zanata removal is soon, please finish migration
On Tue, Aug 11, 2020 at 05:28:26AM -, Jean-Baptiste Holcroft wrote: > libguestfshttps://bugzilla.redhat.com/show_bug.cgi?id=1787301 I believe we have now done everything on our side. > virt-top No bug ..? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: Testing request: OpenConnect VPN with 2FA on Rawhide
In case it's not clear, note that client openconnect supports multiple VPN types, and they might behave differently (e.g. Global Protect, with a different sort of authentication flow). ___ 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: ppc64le copr
Silvie Chlupova writes: > Hi Dave, > at this point, we still don't have working ppc64le workers. Please see this > issue https://pagure.io/fedora-infrastructure/issue/9059. Unfortunately, I > can't give you better information at the moment. OK, thanks. I can sympathize, being in an infrastructure group. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers - php-true-punycode
Le 03/08/2020 à 12:26, Miro Hrončok a écrit : > php-true-punycode orphan 5 I will take this one back as used by laminas stack. Remi ___ 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
