Re: koji build fails on arch armv7hl
I get the same error message [1] this morning: MemoryError During handling of the above exception, another exception occurred: [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=41455137 ___ 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-Cloud-30-20200211.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
[EPEL-devel] Re: Removing baseurl= from default repo files
On Mon, Feb 10, 2020, at 1:36 PM, Stephen John Smoogen wrote: > > For the longest time, the Fedora Project has included a baseurl= line > in its configs as an alternative to the basic metalink= line. EPEL has > followed along, and I expect a lot of users have some sort of > sed/awk/ed script which looks for a #baseurl and does something with > it. > > The upstream configs in Fedora's repo files are changing to only have > the metalink= line in them, and a couple of Pull Requests to make the > changes to the EPEL config files have been placed. > > https://src.fedoraproject.org/rpms/epel-release/pull-request/6 > https://src.fedoraproject.org/rpms/epel-release/pull-request/7 > > I am announcing the change here so that people can be aware before this > starts to show up in EPEL in the next month or so. > This will definitely break a bunch of scripts. Can we at least change it to point to example.com if the server load is too great? I use this to point to local mirrors when mirror manager is not an option. V/r, James Cassell ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Review swaps
On Mon, Feb 10, 2020 at 1:40 PM Jerry James wrote: > It turns out that, in addition to the above, I need 3 other packages > to update Frama-C properly, which means I need to swap six reviews in > all. Let's try this again. I managed to forget one (I really need seven reviews), and two have been taken. This is the list of the five packages for which I still need reviews: ocaml-lablgtk3: https://bugzilla.redhat.com/show_bug.cgi?id=1796271 ocaml-ppx-deriving (requires ocaml-ppxfind and ocaml-ppx-tools, both under review): https://bugzilla.redhat.com/show_bug.cgi?id=1798798 ocaml-ppx-deriving-yojson (requires ocaml-ppx-deriving): https://bugzilla.redhat.com/show_bug.cgi?id=1801421 ocaml-stdint: https://bugzilla.redhat.com/show_bug.cgi?id=1801422 ocaml-zmq (requires ocaml-stdint): https://bugzilla.redhat.com/show_bug.cgi?id=1801423 I will swap reviews with you. If you've got easy reviews, I'll even do 2-for-1. 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
[Bug 1801515] perl-Modern-Perl-1.20200211 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1801515 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Modern-Perl-1.20200211-1.fc30.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=41454730 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1801515] New: perl-Modern-Perl-1.20200211 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1801515 Bug ID: 1801515 Summary: perl-Modern-Perl-1.20200211 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Modern-Perl Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.20200211 Current version/release in rawhide: 1.20200201-1.fc32 URL: http://search.cpan.org/dist/Modern-Perl/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3076/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1801515] perl-Modern-Perl-1.20200211 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1801515 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1662375 --> https://bugzilla.redhat.com/attachment.cgi?id=1662375=edit [patch] Update to 1.20200211 (#1801515) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: swap-on-ZRAM by default
On Monday, February 10, 2020 12:03:25 PM MST Robbie Harwood wrote: > "John M. Harris Jr" writes: > > On Saturday, January 25, 2020 2:52:05 PM MST Chris Murphy wrote: > >> Question and (pre)proposal: > >> > >> Can Fedora converge on a single swap-on-ZRAM implementation, and if > >> so, which one? Fedora Workstation WG wants to move to swap-on-ZRAM by > >> default in Fedora 33, and the working group needs to pick something > >> soon. > > > > Using swap on zram disables the ability to hibernate, making it a > > non-starter for many users. If this is going to be thrown into > > anything, the user needs to be asked whether they want it or not in > > the installer, otherwise you're just taking away features. > > I thought you told me that the workstation group considers hibernation > unsupported? (id:2368390.zu9c8gp...@marvin.jharris.pw) > > Thanks, > --Robbie They do, but that doesn't negate the fact that it is actually supported (you can hibernate your system), and using swap on zram outright breaks hibernation (for obvious reasons). -- John M. Harris, Jr. Splentity ___ 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
[389-devel] 389 DS nightly 2020-02-11 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/11/report-389-ds-base-1.4.3.2-20200211git827c97d.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity Team (weekly)
Dear all, You are kindly invited to the meeting: Modularity Team (weekly) on 2020-02-11 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Team. More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/) The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open=Meeting). Source: https://apps.fedoraproject.org/calendar/meeting/9480/ ___ 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: Guile exception caught in /usr/lib/rpm/find-debuginfo.sh
Hi Dan, Sounds like you need to add explicit '--without-guile' to GDB_MINIMAL_CONFIGURE_FLAGS. Otherwise it autodetects to enabled. -- With best regards, Aleksei ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
CMake could not find Boost components
Hi, CMake finds Boost, but then fails to find its components. Here's the log with -DBoost_DEBUG=1: https://download.copr.fedorainfracloud.org/results/iucar/rstudio/fedora-31-x86_64/01235199-rstudio/builder-live.log Is there anything special I should do for cmake to find them? Any help would be appreciated. Regards, Iñaki ___ 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: Guile exception caught in /usr/lib/rpm/find-debuginfo.sh
On Mon, Feb 10, 2020 at 4:35 PM Dan Čermák wrote: > Hi list, > > I've just ran a mockbuild in Rawhide and the following output from > /usr/lib/rpm/find-debuginfo.sh caught my attention: > > --8<---cut here---start->8--- > /usr/lib/rpm/find-debuginfo.sh -j2 --strict-build-id -m -i --build-id-seed > 1.3-1.fc32 --unique-debug-suffix -1.3-1.fc32.x86_64 --unique-debug-src-base > ocaml-ppxfind-1.3-1.fc32.x86_64 --run-dwz --dwz-low-mem-die-limit 1000 > --dwz-max-die-limit 11000 -S debugsourcefiles.list > /builddir/build/BUILD/ppxfind-1.3 > explicitly decompress any DWARF compressed ELF sections in > /builddir/build/BUILDROOT/ocaml-ppxfind-1.3-1.fc32.x86_64/usr/bin/ppxfind > extracting debug info from > /builddir/build/BUILDROOT/ocaml-ppxfind-1.3-1.fc32.x86_64/usr/bin/ppxfind > Exception caught while booting Guile. > > /usr/bin/gdb.minimal: warning: Could not complete Guile gdb module > initialization from: > /usr/share/gdb/guile/gdb/boot.scm. > Limited Guile support is available. > Suggest passing --data-directory=/path/to/gdb/data-directory. > --8<---cut here---end--->8--- > > Is this known/an issue? That's been happening on every build for a little while now. I'm not sure when it started. > P.S.: I really hope this isn't my fault, as I've re-enabled Guile > support in gdb :-( Well, the file it is complaining about not being able to find is in gdb-headless, but we only get gdb-minimal in the buildroots. If debuginfo generation does not need GDB's guile support, then the warning is probably harmless, if a bit alarming. :-) -- 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
Guile exception caught in /usr/lib/rpm/find-debuginfo.sh
Hi list, I've just ran a mockbuild in Rawhide and the following output from /usr/lib/rpm/find-debuginfo.sh caught my attention: --8<---cut here---start->8--- /usr/lib/rpm/find-debuginfo.sh -j2 --strict-build-id -m -i --build-id-seed 1.3-1.fc32 --unique-debug-suffix -1.3-1.fc32.x86_64 --unique-debug-src-base ocaml-ppxfind-1.3-1.fc32.x86_64 --run-dwz --dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S debugsourcefiles.list /builddir/build/BUILD/ppxfind-1.3 explicitly decompress any DWARF compressed ELF sections in /builddir/build/BUILDROOT/ocaml-ppxfind-1.3-1.fc32.x86_64/usr/bin/ppxfind extracting debug info from /builddir/build/BUILDROOT/ocaml-ppxfind-1.3-1.fc32.x86_64/usr/bin/ppxfind Exception caught while booting Guile. /usr/bin/gdb.minimal: warning: Could not complete Guile gdb module initialization from: /usr/share/gdb/guile/gdb/boot.scm. Limited Guile support is available. Suggest passing --data-directory=/path/to/gdb/data-directory. --8<---cut here---end--->8--- Is this known/an issue? Thanks in advance, Dan P.S.: I really hope this isn't my fault, as I've re-enabled Guile support in gdb :-( 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 swap: mediawiki-lastmodified
On Mon, 2020-02-10 at 16:00 -0700, Jerry James wrote: > On Mon, Feb 10, 2020 at 3:57 PM Sérgio Basto > wrote: > > As it seems to be easy one , I take it and swap with > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1796268 > > > > nodejs-p-try > > > > OK ? > > Sorry, Sérgio, I grabbed Ankur's review just as you were sending > this. No problem , no worries > But see my reply to him. I've got 6 reviews on my list. Would you > like to swap one of mine for nodejs-p-try? > -- > 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 -- Sérgio M. B. ___ 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 swap: mediawiki-lastmodified
On Mon, Feb 10, 2020 22:57:06 +, Sérgio Basto wrote: > On Mon, 2020-02-10 at 22:51 +, Ankur Sinha wrote: > > Hello, > > > > Would anyone like to swap reviews please? I'd like to get > > mediawiki-lastmodified[1] packaged so we can use it with our wiki. It > > adds a "Last updated ..." text to wiki pages so we know how current > > or > > outdated they may be. > > > > The review is here (should hopefully be a simple one): > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1801464 > > > > [1] https://www.mediawiki.org/wiki/Extension:LastModified > > > As it seems to be easy one , I take it and swap with > > https://bugzilla.redhat.com/show_bug.cgi?id=1796268 Jerry already took it, but I can review this for you anyway. No worries :) -- 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: Review swaps
On Mon, Feb 10, 2020 13:40:31 -0700, Jerry James wrote: > On Wed, Feb 5, 2020 at 8:16 PM Jerry James wrote: > > The latest release of Frama-C needs ocaml-ppx-deriving, which in turn > > needs two other packages we don't have in Fedora. I'm willing to swap > > reviews for the following: > > > > ocaml-ppx-tools: > > https://bugzilla.redhat.com/show_bug.cgi?id=1798797 > > Thanks for taking mediawiki-lastmodified, Jerry. I've taken this one to begin with. -- 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: Review swap: mediawiki-lastmodified
On Mon, Feb 10, 2020 at 3:57 PM Sérgio Basto wrote: > As it seems to be easy one , I take it and swap with > > https://bugzilla.redhat.com/show_bug.cgi?id=1796268 > > nodejs-p-try > > OK ? Sorry, Sérgio, I grabbed Ankur's review just as you were sending this. But see my reply to him. I've got 6 reviews on my list. Would you like to swap one of mine for nodejs-p-try? -- 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: Review swap: mediawiki-lastmodified
Hi Ankur, On Mon, Feb 10, 2020 at 3:52 PM Ankur Sinha wrote: > Would anyone like to swap reviews please? I'd like to get > mediawiki-lastmodified[1] packaged so we can use it with our wiki. It > adds a "Last updated ..." text to wiki pages so we know how current or > outdated they may be. I just asked for swaps a couple of hours ago: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FWZMAL6DEPLEQKQG5V4AOFBRZDMSH7Z3/ If you could take one of those, please, I will take this review. 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: Review swap: mediawiki-lastmodified
On Mon, 2020-02-10 at 22:51 +, Ankur Sinha wrote: > Hello, > > Would anyone like to swap reviews please? I'd like to get > mediawiki-lastmodified[1] packaged so we can use it with our wiki. It > adds a "Last updated ..." text to wiki pages so we know how current > or > outdated they may be. > > The review is here (should hopefully be a simple one): > > https://bugzilla.redhat.com/show_bug.cgi?id=1801464 > > [1] https://www.mediawiki.org/wiki/Extension:LastModified As it seems to be easy one , I take it and swap with https://bugzilla.redhat.com/show_bug.cgi?id=1796268 nodejs-p-try OK ? > ___ > 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 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review swap: mediawiki-lastmodified
Hello, Would anyone like to swap reviews please? I'd like to get mediawiki-lastmodified[1] packaged so we can use it with our wiki. It adds a "Last updated ..." text to wiki pages so we know how current or outdated they may be. The review is here (should hopefully be a simple one): https://bugzilla.redhat.com/show_bug.cgi?id=1801464 [1] https://www.mediawiki.org/wiki/Extension:LastModified -- 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: kernel rpm split
On Thu, 2020-02-06 at 14:13 -0500, Josh Boyer wrote: > On Thu, Feb 6, 2020 at 1:56 PM Zbigniew Jędrzejewski-Szmek > wrote: > > Hello kernel maintainers, hello Fedora developers, > > > > I'm looking into the split of kernel packages. The split into > > subpackages > > seems interesting, but there are many dependencies between the > > packages, > > so it is usual to end up with all of them installed. > > > > E.g. for a simple VM, by design, kernel-core contains a basic set > > of > > modules that should be enough to boot. I see that in a standard > > libvirt guest, the only modules from kernel-modules that are loaded > > are for sound hardware and "usbnet", all which I'd be fine without. > > > > Another example: we'd like to explore building an initramfs > > directly > > from rpms, without dracut, only systemd and a standard packages to > > bring up the hardware. Some modules need to be installed, so the > > kernel can load the from the initramfs, but the kernel itself > > should > > not, since it is provided "externally" by the boot loader. > > > > But: > > the basic modules are in one rpm with kernel-core > > kernel-core Requires linux-firmware (which is 240MB) > > kernel-modules Requires kernel-uname-r, which is provided by > > kernel-core > > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > > > Would it be possible to make some changes: > > > > - split out the modules from kernel-core package into a new > > subpackage > > kernel-basic-modules, kernel-core can Recommend or Require it > > There has to be a *really* good benefit to do this, and I haven't > seen > one described. The more splitting we do, the more management both on > the client machines and for the kernel maintainers themselves. The > way modules are filtered is terrible (I wrote it, so I can say that) > and requires people to keep it updated as the upstream kernel changes > module dependencies. > The way modules are filtered is indeed difficult and requires a lot of human care and attention, but perhaps this is a good opportunity to rethink how it works a bit. I'm obviously not crazy about advocating for something that makes my job harder, but I'm willing to entertain doing some work so I can later not do any work in that area again. Furthermore, this particular issue is on my radar anyway due to my last run-in with it. All that to say that I *hope* we can improve how we divvy up modules enough that it won't be a blocker for this proposal (and kernel maintainers will live in a land filled with sunshine and rainbows). > Can you describe in more detail why you need something smaller than > kernel-core? I'm not understanding your usecase. > > > - remove the Requires on kernel-core (or change to Recommends) from > > kernel-modules, so it can be installed standalone > > That makes no sense. The modules are unusable without the main > vmlinux binary. Why would we do that and risk people making their > machines unbootable? > > > - move the Requires:linux-firmware (or change to Recommends) from > > kernel-core, > > have kernel Requires:linux-firmware > > > > I think this would be useful for playing with various minimization > > scenarios. > > This one might be feasible. We did the split before Recommends > support was present. It's often been requested for the VM case. I > do > still have concerns that it can lead to unbootable physical machines, > but if dnf defaults to installing Recommended packages that might be > possible. > > josh > ___ > 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: Review swaps
On Wed, Feb 5, 2020 at 8:16 PM Jerry James wrote: > The latest release of Frama-C needs ocaml-ppx-deriving, which in turn > needs two other packages we don't have in Fedora. I'm willing to swap > reviews for the following: > > ocaml-ppxfind: > https://bugzilla.redhat.com/show_bug.cgi?id=1798796 > > ocaml-ppx-tools: > https://bugzilla.redhat.com/show_bug.cgi?id=1798797 > > ocaml-ppx-deriving (requires the two above): > https://bugzilla.redhat.com/show_bug.cgi?id=1798798 > > Let me know what I can review for you in exchange. Thanks, It turns out that, in addition to the above, I need 3 other packages to update Frama-C properly, which means I need to swap six reviews in all. Here are the other 3: ocaml-ppx-deriving-yojson (requires ocaml-ppx-deriving): https://bugzilla.redhat.com/show_bug.cgi?id=1801421 ocaml-stdint: https://bugzilla.redhat.com/show_bug.cgi?id=1801422 ocaml-zmq (requires ocaml-stdint): https://bugzilla.redhat.com/show_bug.cgi?id=1801423 Let me know what you need reviewed. Thank you, -- 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: kernel rpm split
On 2020-02-07 09:56, Stephen John Smoogen wrote: On Fri, 7 Feb 2020 at 09:28, Zbigniew Jędrzejewski-Szmek mailto:zbys...@in.waw.pl>> wrote: On Fri, Feb 07, 2020 at 08:37:05AM -0500, Neal Gompa wrote: > On Fri, Feb 7, 2020 at 8:27 AM Zbigniew Jędrzejewski-Szmek > mailto:zbys...@in.waw.pl>> wrote: > > > > On Fri, Feb 07, 2020 at 12:09:37PM +, Richard W.M. Jones wrote: > > > > > > I'd strongly suggest you look at supermin before going any further. > > > > Supermin is an interesting project, but at this point we're not > > looking for a tool to craft the image. We're still at an earlier stage > > of changing how we do some rpm packages so that it is easy to do an > > installation that is small without custom logic. > > > > The idea is that the initramfs, once you include lvm, md, dm, encryption, > > networking, clevis, emergency utilities, scsi, iscsi, raid in various > > flavours, some graphics drivers, usb, bluetooth, etc, is a lot like a > > the full distribution. Things would be a lot easier if we could just > > use the same tools and daemons from the same packages as in the > > host. Supermin (and other tools) have support for creating something > > custom and small, and here the goal is the opposite: to do "standard". > > > > Fedora currently uses dracut, and the problem is that nobody has a > > good grasp on what goes in dracut. There's a lot of custom logic and > > custom code and reimplementation of things, and people who deal with > > the same functionality in the host system don't necessarily know what > > happens in the initramfs. In the past such a setup made sense, but now > > it seems that the tradeoffs are different. > > > > I'm genuinely surprised by this. [...] The main problem with > dracut is the same problem with all initramfs generators: it has to > prepare an environment that works in the worst circumstances. It's > compounded by the restriction that everything is written in shell, and > POSIX shell at that (because Debian). Well, look at it from the other side: the host machine also needs to work in the same circumstances, since we need things to work also after we switch to the host. And the actual code that we use in the host — the libraries, the binaries, configuration — is the same, since we don't do different compilations for the initramfs. In the host we have switched away from the shell for machine boot, but for some reason we still keep it for the initramfs, along with a large amount of custom logic. > The dracut package, while very large, > has a pretty understandable framework model. Sure, it *can* be understood, but should it? Do we gain anything by having the initramfs so different from the host? The initial My problem here is that we continually get told we are full of Not Invented Here(NIH) solutions by people in other communities and we should be doing something Debian and different communities use.. And here is one of the places we do agree with other distributions, but it is now a "bah its crap and you can do something better that works with your tools." We knew that years ago and we have known that time and time again. The issue is that we end up with another 'NIH' tool which our limited manpower are going to know and as soon as XYZ developer walks off to $ABC startup we have an unbootable and unmaintained mess. AKA where we were before dracut. If we are hell bent on repeating history, please let us try to learn from it first. Please allow me to weigh in here, whilst I straddle this fence since I have a vested stake here, though I only have $0.02 to vote with just like anyone else. On one hand, I like the idea being proposed. I mean, it shouldn't be that different of an environment than what you're trying to boot into. The whole process has a a lot of complexity that seems wasteful in some cases but affords flexibility in others. Nobody likes waiting for dracut to do its thing. I've literally done so hundreds of times in the last few weeks as I prepare for an in-service, in-place upgrade of several hundred nodes running a custom Fedora Live spin to a newer custom Fedora Live spin. I've done so successfully shepherding them from Fedora 10 to 25 and am about to jump them all to F29. The magic all happens via a custom initrd that does a switcheraroo of the LiveOS and syslinux directories. So, one reboot into the magic initrd to do the switch and another reboot from there into the new distro. (I should note, that the hundreds of dracut runs are its fault, but instead for dev work related to how the new payload is managed. Nonetheless, I've done a lot of waiting in testing due to dracut runs.) On the other hand, I remember the madness of trying to maintain local patches
Re: Getting an error on rawhide importing wx
On 2/10/20 1:26 PM, Miro Hrončok wrote: On 10. 02. 20 17:56, Steven A. Falco wrote: There appears to be something wrong with python wx: rawhide# python Python 3.8.1 (default, Jan 30 2020, 00:00:00) [GCC 10.0.1 20200126 (Red Hat 10.0.1-0.6)] on linux Type "help", "copyright", "credits" or "license" for more information. import wx Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 17, in from wx.core import * File "/usr/lib64/python3.8/site-packages/wx/core.py", line 12, in from ._core import * ImportError: /usr/lib64/python3.8/site-packages/wx/_core.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_createERmm, version WXU_3.0 Should I write a bug for this or am I doing something wrong? We have encountered the same problem when rebuilding stuff against Python 3.9: https://bugzilla.redhat.com/show_bug.cgi?id=1801244 Thanks. I added a comment to that bug. I found that by rebuilding python3 and python-wxpython4 I could then import wx without error. Steve ___ 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: swap-on-ZRAM by default
"John M. Harris Jr" writes: > On Saturday, January 25, 2020 2:52:05 PM MST Chris Murphy wrote: > >> Question and (pre)proposal: >> >> Can Fedora converge on a single swap-on-ZRAM implementation, and if >> so, which one? Fedora Workstation WG wants to move to swap-on-ZRAM by >> default in Fedora 33, and the working group needs to pick something >> soon. > > Using swap on zram disables the ability to hibernate, making it a > non-starter for many users. If this is going to be thrown into > anything, the user needs to be asked whether they want it or not in > the installer, otherwise you're just taking away features. I thought you told me that the workstation group considers hibernation unsupported? (id:2368390.zu9c8gp...@marvin.jharris.pw) Thanks, --Robbie 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
ldc soname bump in rawhide
Hi all, I just built new ldc 1.20.0 that comes with a soname bump in rawhide. I've rebuilt all packages using it, with the exception of the following three that are FTBFS (and already failed in the F32 mass rebuild): appstream-generator containers glibd Package maintainers BCC'd. -- Kalev ___ 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
[EPEL-devel] Removing baseurl= from default repo files
For the longest time, the Fedora Project has included a baseurl= line in its configs as an alternative to the basic metalink= line. EPEL has followed along, and I expect a lot of users have some sort of sed/awk/ed script which looks for a #baseurl and does something with it. The upstream configs in Fedora's repo files are changing to only have the metalink= line in them, and a couple of Pull Requests to make the changes to the EPEL config files have been placed. https://src.fedoraproject.org/rpms/epel-release/pull-request/6 https://src.fedoraproject.org/rpms/epel-release/pull-request/7 I am announcing the change here so that people can be aware before this starts to show up in EPEL in the next month or so. -- Stephen J Smoogen. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Getting an error on rawhide importing wx
On 10. 02. 20 17:56, Steven A. Falco wrote: There appears to be something wrong with python wx: rawhide# python Python 3.8.1 (default, Jan 30 2020, 00:00:00) [GCC 10.0.1 20200126 (Red Hat 10.0.1-0.6)] on linux Type "help", "copyright", "credits" or "license" for more information. import wx Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 17, in from wx.core import * File "/usr/lib64/python3.8/site-packages/wx/core.py", line 12, in from ._core import * ImportError: /usr/lib64/python3.8/site-packages/wx/_core.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_createERmm, version WXU_3.0 Should I write a bug for this or am I doing something wrong? We have encountered the same problem when rebuilding stuff against Python 3.9: https://bugzilla.redhat.com/show_bug.cgi?id=1801244 -- 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
[EPEL-devel] KDE Plasma Desktop available for EPEL8
Hello, The KDE Plasma Desktop is now available for standard EPEL8. ## How to install ### First: install epel-release rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm ### Second: Enable codeready-builder or PowerTools subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms If CentOS 8 do dnf config-manager --enable PowerTools ### Third: install KDE dnf group install "KDE Plasma Workspaces" (Optional) dnf group install kde-desktop (Optional) dnf group install kde-media (Optional) dnf --enablerepo=epel-testing group install kde-apps [1] (Optional) dnf --enablerepo=epel-testing group install okular [1] ### (Optional) Fourth: Set sddm as desktop manager systemctl set-default graphical.target [if in multi-user.target] dnf install sddm\* systemctl enable sddm -f reboot Note1: There are some packages missing due to RHEL8 not releasing some key -devel packages. Most notable are plasma-nm* and kmail/kaddressbook (and everything related to that). Note2: Any packages related to telepathy are also missing. This is due to telepathy's current dependency on python2-dbus, which will not be in RHEL8. Note3: There are no packages that are qt4 based. Note4: There were over a hundred more kde/plasma/qt5 related packages, and I didn't know which ones people were actually using. So if you have a favorite KDE/Plasma/QT5 application that isn't currently available in epel8, and isn't in the list above, let me know and we'll see if we can get it in. Troy [1] - Still in epel-testing. I will send a follow up email when it is out. -- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-00865efa86 -- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-bda6808b41 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Change proposal discussion - Optimize SquashFS Size
On Mon, Feb 10, 2020 at 3:30 AM John M. Harris Jr wrote: > As for the software available, that's called choice. I know > it's a relative unknown in the GNOME world, as one option is shoved down > everyones' throat, but it's a key part of the KDE ideology, as well as GNU/ > Linux itself. > John, it's obvious from your posts in this list that you're not a fan of GNOME. I'd kindly ask you to please refrain from attacking GNOME, especially when the discussion at hand isn't about GNOME itself. It's not in keeping with the "be excellent to each other" spirit that Fedora likes to keep in its mailing lists. -- Jared Smith ___ 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: koji build error
Hey Tom,
Thanks for helping me out, I replaced all the hardcoded directories with
macros and the build is now successful for all architectures .
Here is the successful koji build
https://koji.fedoraproject.org/koji/taskinfo?taskID=41450255
Thanks again,
Harsh
On Mon, Feb 10, 2020 at 9:46 PM Tom Hughes wrote:
> You have hard coded /usr/lib64 in your spec but that is not the path
> on 32 bit systems - use %{_libdir} instead and it will work.
>
> In general you should be using macros rather than hard coding paths
> in fact - this is just one case where it goes very wrong if you don't.
>
> Tom
>
> On 10/02/2020 16:11, Harsh Jain wrote:
> > but I still can't figure out where the errors are in the build logs
> > .Sorry the message was broken into 2 .
> > Thanks ,
> > Harsh
> >
> > On Mon, Feb 10, 2020 at 9:40 PM Harsh Jain > > wrote:
> >
> > Thanks for telling me, turns out it was missing a few more
> > dependencies, I rebuilt the package and it now seems to build on all
> > except arch armv7hl and i686
> > here is the new koji build
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41448837
> > , I've updated the spec file and rpm here
> > https://github.com/a-mere-peasant/elementary-tweaks-fedora
> >
> > On Mon, Feb 10, 2020 at 7:15 PM Tom Hughes > > wrote:
> >
> > On 10/02/2020 13:31, Harsh Jain wrote:
> >
> > > I am trying to package elementary-tweaks and am getting
> > failed build in
> > > koji
> > > I cannot find where the build is failing. This is my first
> time
> > > packaging something and have no idea where to look for errors
> > in the
> > > build logs . Any help is appreciated . Here is the build
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=41447194
> > > and here are the spec and rpm files
> > > https://github.com/a-mere-peasant/elementary-tweaks-fedora
> >
> > You appear to be mussing a BuildRequire for switchboard-devel.
> >
> > Tom
> >
> > --
> > Tom Hughes (t...@compton.nu )
> > http://compton.nu/
> >
>
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>
___
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: 20200210.n.0 changes
OLD: Fedora-Rawhide-20200209.n.0 NEW: Fedora-Rawhide-20200210.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 4 Dropped packages:0 Upgraded packages: 65 Downgraded packages: 0 Size of added packages: 1.89 MiB Size of dropped packages:0 B Size of upgraded packages: 508.61 MiB Size of downgraded packages: 0 B Size change of upgraded packages: -16.71 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: grim-1.3.0-2.module_f32+7695+b798cb85 Summary: Grab images from a Wayland compositor RPMs:grim Size:115.55 KiB Package: python-pathtools-0.1.2-20.fc32 Summary: Pattern matching and various utilities for file systems paths RPMs:python3-pathtools Size:153.54 KiB Package: slurp-1.2.0-2.module_f32+7701+7f0b4eb5 Summary: Select a region in a Wayland compositor RPMs:slurp Size:109.39 KiB Package: waybar-0.9.0-1.fc32 Summary: Highly customizable Wayland bar for Sway and Wlroots based compositors RPMs:waybar Size:1.52 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: alsa-lib-1.2.1.2-6.fc32 Old package: alsa-lib-1.2.1.2-5.fc32 Summary: The Advanced Linux Sound Architecture (ALSA) library RPMs: alsa-lib alsa-lib-devel alsa-topology alsa-ucm Size: 7.36 MiB Size change: 172.02 KiB Changelog: * Sun Feb 09 2020 Jaroslav Kysela - 1.2.1.2-6 - More UCM2 related fixes Package: avogadro2-1.93.0-1.fc32 Old package: avogadro2-1.91.0-6.fc32 Summary: Advanced molecular editor RPMs: avogadro2 Size: 11.37 MiB Size change: -553 B Changelog: * Sun Feb 09 2020 Antonio Trande - 1.93.0-1 - Release 1.93.0 Package: avogadro2-libs-1.93.0-1.fc32 Old package: avogadro2-libs-1.92.1-2.fc32 Summary: Avogadro2 libraries RPMs: avogadro2-libs avogadro2-libs-devel avogadro2-libs-doc Size: 16.61 MiB Size change: 858.11 KiB Changelog: * Thu Feb 06 2020 Antonio Trande - 1.93.0-1 - Release 1.93.0 Package: aws-2019-2.fc32 Old package: aws-2018-5.fc31 Summary: Ada Web Server RPMs: aws aws-devel aws-doc aws-tools Size: 20.80 MiB Size change: 1.64 MiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 2018-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sun Feb 09 2020 Bj??rn Persson - 2018-6 - Adapted to compiler and API changes in GCC 10. * Sun Feb 09 2020 Pavel Zhukov - 2019-2 - New release (2019) build with gcc10 (#1800306) Package: clamav-0.102.2-1.fc32 Old package: clamav-0.101.5-8.fc32 Summary: End-user tools for the Clam Antivirus scanner RPMs: clamav clamav-data clamav-devel clamav-filesystem clamav-lib clamav-milter clamav-update clamd Size: 177.46 MiB Size change: 5.06 MiB Changelog: * Tue Feb 04 2020 S??rgio Basto - 0.101.5-9 - Add a message warning that We now provide clamav-freshclam.service systemd unit instead old scripts * Sun Feb 09 2020 Orion Poplawski - 0.101.5-10 - Re-add clamav-update.cron (bz#1800226) - Add conditional old_freshclam * Sun Feb 09 2020 Orion Poplawski - 0.102.2-1 - Update to 0.102.2 - Drop supporting deprecated options for F32+ and EL8+ - Drop old umask patch Package: danmaq-0.2.3.1-8.fc32 Old package: danmaq-0.2.3.1-6.fc31 Summary: A small client side Qt program to play danmaku on any screen RPMs: danmaq Size: 377.76 KiB Size change: -14.39 KiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 0.2.3.1-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sun Feb 09 2020 Zamir SUN - 0.2.3.1-8 - Fix FTBFS in Fedora 32 - Resolves 1799269 Package: gap-pkg-digraphs-1.1.1-1.fc32 Old package: gap-pkg-digraphs-1.0.3-2.fc32 Summary: GAP package for digraphs and multidigraphs RPMs: gap-pkg-digraphs gap-pkg-digraphs-doc Size: 4.00 MiB Size change: 323.83 KiB Changelog: * Sat Feb 08 2020 Jerry James - 1.1.1-1 - Version 1.1.1 - Drop upstreamed -overflow patch - Bundle modified bliss Package: gap-pkg-semigroups-3.2.3-1.fc32 Old package: gap-pkg-semigroups-3.2.2-2.fc32 Summary: GAP methods for semigroups RPMs: gap-pkg-semigroups gap-pkg-semigroups-doc Size: 4.78 MiB Size change: 8.31 KiB Changelog: * Sat Feb 08 2020 Jerry James - 3.2.3-1 - Version 3.2.3 Package: gnugo-3.8-22.fc32 Old package: gnugo-3.8-21.fc31 Summary: Text based go program RPMs: gnugo Size: 7.10 MiB Size change: 63.96 KiB Changelog: * Sun Feb 09 2020 Michel Alexandre Salim - 3.8-22 - Workaround for GCC 10's -fno-common - Modernize spec Package: golang-github-boltdb-bolt-1.3.1-10.fc32 Old package: golang-github-boltdb-bolt-1.3.1-8.fc31 Summary: Embedded key/value database for Go RPMs: boltdb golang-github-boltdb-bolt-devel Size
Re: Copr Build System - review of 2019 and vote for features in 2020
On Mon, Feb 10, 2020 at 01:46:14AM -0700, John M. Harris Jr wrote: > So long as people are willing to maintain it, why restrict peoples' ability > to > work on something, especially while users are stuck on that version, or > forced > to move elsewhere if they cannot get a fix and cannot upgrade? A nummber of reasons: Resources: * storage space on fast storage instead of archives * mirror space * signing cycles * build cycles * compose cycles False sense of security: Something might be updated because the maintainer wants to keep it up to date there, but no one else does so 30 other things are inscure/broken, making users thing things are up to date when they are not. You would have to have some way to allow feedback/bug reports only to those people who are wanting to keep it alive, while not bothering people who don't wish to. 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
Getting an error on rawhide importing wx
There appears to be something wrong with python wx: rawhide# python Python 3.8.1 (default, Jan 30 2020, 00:00:00) [GCC 10.0.1 20200126 (Red Hat 10.0.1-0.6)] on linux Type "help", "copyright", "credits" or "license" for more information. import wx Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.8/site-packages/wx/__init__.py", line 17, in from wx.core import * File "/usr/lib64/python3.8/site-packages/wx/core.py", line 12, in from ._core import * ImportError: /usr/lib64/python3.8/site-packages/wx/_core.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE9_M_createERmm, version WXU_3.0 Should I write a bug for this or am I doing something wrong? Steve ___ 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: Packaging of Ansible collections
James Cassell (fedoraproj...@cyberpear.com) said: > > > I guess if would be enough to put the files somewhere under > > > /usr/share/ansible, but not sure. Also I'm not sure what download URL > > > could > > > be used. > > > > What is the goal of downstream collection packaging here - what collections > > are you looking to package and why? > > Same reason as openshift-ansible or ceph-ansible or ansible-freeipa, or > any pip-installable package. Unfortunately, ansible is kicking all the > community modules out of core, so things like ini_file won't work without > the appropriate collection installed. Yes, but there will be a deliverable/distribution that will be produced with the goal of allowing playbooks to work more or less as they do now; the goal is that community content can be maintained on its own release stream as it's needed, but delivery can still be in the form of a larger community package. Bill ___ 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: Packaging of Ansible collections
The goal is to be able to use ansible with collections installed via RPM without having to connect to the internet. On Mon, Feb 10, 2020 at 4:45 PM Bill Nottingham wrote: > > Igor Gnatenko (ignatenkobr...@fedoraproject.org) said: > > Hello, > > > > Did anybody had an experience of packaging Ansible collections into an RPM? > > > > I guess if would be enough to put the files somewhere under > > /usr/share/ansible, but not sure. Also I'm not sure what download URL could > > be used. > > What is the goal of downstream collection packaging here - what collections > are you looking to package and why? > > Bill > ___ > 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
Orphaning dump
Hi all, I plan to orphan `dump` package. The upstream is dead and I don't see much benefit for using FS-specific tool over a generic one either. I see its bugs though (it doesn't build with -fno-common, problems with endianness, flaky support for ext4, …). So unless some brave soul wants to take over its maintenance I'll orphan it. amanda has dependency on it but that dependency can be removed. Regards, Václav Doležal ___ 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-20200210.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 25 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 98/169 (x86_64), 1/2 (arm) Old failures (same test failed in Fedora-Rawhide-20200209.n.0): ID: 519084 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/519084 ID: 519085 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/519085 ID: 519087 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/519087 ID: 519092 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/519092 ID: 519097 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/519097 ID: 519098 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/519098 ID: 519099 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/519099 ID: 519100 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/519100 ID: 519101 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/519101 ID: 519109 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/519109 ID: 519114 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/519114 ID: 519117 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/519117 ID: 519124 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/519124 ID: 519125 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/519125 ID: 519126 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/519126 ID: 519127 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/519127 ID: 519128 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/519128 ID: 519143 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/519143 ID: 519148 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/519148 ID: 519152 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/519152 ID: 519154 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/519154 ID: 519161 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/519161 ID: 519163 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/519163 ID: 519164 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/519164 ID: 519175 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/519175 ID: 519176 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/519176 ID: 519177 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/519177 ID: 519178 Test: x86_64 universal install_kickstart_firewall_configured **GATING** URL: https://openqa.fedoraproject.org/tests/519178 ID: 519179 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/519179 ID: 519180 Test: x86_64 universal install_repository_http_variation **GATING** URL: https://openqa.fedoraproject.org/tests/519180 ID: 519181 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/519181 ID: 519182 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/519182 ID: 519183 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/519183 ID: 519185 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/519185 ID: 519186 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/519186 ID: 519187 Test: x86_64 universal install_multi@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/519187 ID: 519188 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/519188 ID: 519189 Test: x86_64 universal install_blivet_no_swap URL:
[Bug 1781758] Co-maintainer request (to maintain EPEL8 branch)
https://bugzilla.redhat.com/show_bug.cgi?id=1781758 Fedora Admin XMLRPC Client changed: What|Removed |Added Assignee|dd...@cpan.org |extras-orphan@fedoraproject ||.org --- Comment #1 from Fedora Admin XMLRPC Client --- This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Orphaning owncloud and nextcloud
No problem! sorry for the delay On Mon, Feb 10, 2020 at 7:01 AM Christian Glombek wrote: > > This is excellent news! Thank you, Iván! > > > On Sat, Feb 8, 2020 at 9:34 PM Ivan Chavero wrote: > >> >> >> On Sat, Feb 8, 2020 at 1:43 PM Miro Hrončok wrote: >> >>> On 08. 02. 20 20:29, Ivan Chavero wrote: >>> > The nextcloud package updated for 18.0.0 is now on rawhide, 31 and 30 >>> , sorry >>> > for the delay. I had to do a >>> > mayo refactor and careful testing. >>> >>> Thanks for the update. Is such a major overhaul applicable for already >>> released >>> Fedoras? >>> >> >> The refactor was only for the spec file and patches, the file locations >> and configuration files are the same so it >> should not affect updates. >> >> >>> >>> Could you please close the relevant bugzillas as well? >>> >> >> I've set the main bug [1] as MODIFIED and closed other bugs as duplicates >> it. There are other bugs >> related to the previous version that I will close as CURRENTRELEASE. >> >> Cheers, >> Iván >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1710115 >> >>> >>> -- >>> 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
[Bug 1781741] Co-maintainer request (to maintain EPEL8 branch)
https://bugzilla.redhat.com/show_bug.cgi?id=1781741 Fedora Admin XMLRPC Client changed: What|Removed |Added Assignee|dd...@cpan.org |extras-orphan@fedoraproject ||.org --- Comment #1 from Fedora Admin XMLRPC Client --- This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1661251] Fails due to uninitialised value
https://bugzilla.redhat.com/show_bug.cgi?id=1661251 Fedora Admin XMLRPC Client changed: What|Removed |Added Assignee|dd...@cpan.org |extras-orphan@fedoraproject ||.org --- Comment #1 from Fedora Admin XMLRPC Client --- This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1765510] Request to update perl-Protocol-WebSocket to 0.26 for EPEL 7
https://bugzilla.redhat.com/show_bug.cgi?id=1765510 Fedora Admin XMLRPC Client changed: What|Removed |Added Assignee|dd...@cpan.org |extras-orphan@fedoraproject ||.org --- Comment #1 from Fedora Admin XMLRPC Client --- This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1795179] Non-responsive maintainer check for ddick
https://bugzilla.redhat.com/show_bug.cgi?id=1795179 Fedora Admin XMLRPC Client changed: What|Removed |Added Assignee|dd...@cpan.org |xav...@bachelot.org --- Comment #1 from Fedora Admin XMLRPC Client --- This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1757318] Request to build perl-REST-Client for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1757318 Fedora Admin XMLRPC Client changed: What|Removed |Added Assignee|dd...@cpan.org |extras-orphan@fedoraproject ||.org --- Comment #1 from Fedora Admin XMLRPC Client --- This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Packaging of Ansible collections
L On Mon, Feb 10, 2020, at 10:33 AM, Bill Nottingham wrote: > Igor Gnatenko (ignatenkobr...@fedoraproject.org) said: > > Hello, > > > > Did anybody had an experience of packaging Ansible collections into an RPM? > > > > I guess if would be enough to put the files somewhere under > > /usr/share/ansible, but not sure. Also I'm not sure what download URL could > > be used. > > What is the goal of downstream collection packaging here - what collections > are you looking to package and why? > Same reason as openshift-ansible or ceph-ansible or ansible-freeipa, or any pip-installable package. Unfortunately, ansible is kicking all the community modules out of core, so things like ini_file won't work without the appropriate collection installed. V/r, James Cassell ___ 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: koji build error
You have hard coded /usr/lib64 in your spec but that is not the path
on 32 bit systems - use %{_libdir} instead and it will work.
In general you should be using macros rather than hard coding paths
in fact - this is just one case where it goes very wrong if you don't.
Tom
On 10/02/2020 16:11, Harsh Jain wrote:
but I still can't figure out where the errors are in the build logs
.Sorry the message was broken into 2 .
Thanks ,
Harsh
On Mon, Feb 10, 2020 at 9:40 PM Harsh Jain > wrote:
Thanks for telling me, turns out it was missing a few more
dependencies, I rebuilt the package and it now seems to build on all
except arch armv7hl and i686
here is the new koji build
https://koji.fedoraproject.org/koji/taskinfo?taskID=41448837
, I've updated the spec file and rpm here
https://github.com/a-mere-peasant/elementary-tweaks-fedora
On Mon, Feb 10, 2020 at 7:15 PM Tom Hughes mailto:t...@compton.nu>> wrote:
On 10/02/2020 13:31, Harsh Jain wrote:
> I am trying to package elementary-tweaks and am getting
failed build in
> koji
> I cannot find where the build is failing. This is my first time
> packaging something and have no idea where to look for errors
in the
> build logs . Any help is appreciated . Here is the build
> https://koji.fedoraproject.org/koji/taskinfo?taskID=41447194
> and here are the spec and rpm files
> https://github.com/a-mere-peasant/elementary-tweaks-fedora
You appear to be mussing a BuildRequire for switchboard-devel.
Tom
--
Tom Hughes (t...@compton.nu )
http://compton.nu/
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: koji build fails on arch armv7hl
I'm getting this on s390x. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, February 10, 2020 9:43 AM, Stephen John Smoogen wrote: > On Mon, 10 Feb 2020 at 10:24, Stephen John Smoogen wrote: > > > Linux buildvm-armv7-07.arm.fedoraproject.org 5.3.13-300.fc31.armv7hl+lpae > > #1 SMP Mon Nov 25 17:13:28 UTC 2019 armv7l armv7l armv7l GNU/Linux > > > > will work with release engineering to see if they can take this builder out > > and reboot it. > > > > System has been rebooted. > > -- > Stephen J Smoogen. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji build error
but I still can't figure out where the errors are in the build logs .Sorry the message was broken into 2 . Thanks , Harsh On Mon, Feb 10, 2020 at 9:40 PM Harsh Jain wrote: > Thanks for telling me, turns out it was missing a few more dependencies, I > rebuilt the package and it now seems to build on all except arch armv7hl > and i686 > here is the new koji build > https://koji.fedoraproject.org/koji/taskinfo?taskID=41448837 > , I've updated the spec file and rpm here > https://github.com/a-mere-peasant/elementary-tweaks-fedora > > On Mon, Feb 10, 2020 at 7:15 PM Tom Hughes wrote: > >> On 10/02/2020 13:31, Harsh Jain wrote: >> >> > I am trying to package elementary-tweaks and am getting failed build in >> > koji >> > I cannot find where the build is failing. This is my first time >> > packaging something and have no idea where to look for errors in the >> > build logs . Any help is appreciated . Here is the build >> > https://koji.fedoraproject.org/koji/taskinfo?taskID=41447194 >> > and here are the spec and rpm files >> > https://github.com/a-mere-peasant/elementary-tweaks-fedora >> >> You appear to be mussing a BuildRequire for switchboard-devel. >> >> Tom >> >> -- >> Tom Hughes (t...@compton.nu) >> http://compton.nu/ >> > ___ 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: koji build error
Thanks for telling me, turns out it was missing a few more dependencies, I rebuilt the package and it now seems to build on all except arch armv7hl and i686 here is the new koji build https://koji.fedoraproject.org/koji/taskinfo?taskID=41448837 , I've updated the spec file and rpm here https://github.com/a-mere-peasant/elementary-tweaks-fedora On Mon, Feb 10, 2020 at 7:15 PM Tom Hughes wrote: > On 10/02/2020 13:31, Harsh Jain wrote: > > > I am trying to package elementary-tweaks and am getting failed build in > > koji > > I cannot find where the build is failing. This is my first time > > packaging something and have no idea where to look for errors in the > > build logs . Any help is appreciated . Here is the build > > https://koji.fedoraproject.org/koji/taskinfo?taskID=41447194 > > and here are the spec and rpm files > > https://github.com/a-mere-peasant/elementary-tweaks-fedora > > You appear to be mussing a BuildRequire for switchboard-devel. > > Tom > > -- > Tom Hughes (t...@compton.nu) > http://compton.nu/ > ___ 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: Change proposal discussion - Optimize SquashFS Size
On Mon, Feb 10, 2020 at 9:25 AM John M. Harris Jr wrote: > On Thursday, February 6, 2020 7:33:52 AM MST Kevin Kofler wrote: > > Kamil Paral wrote: > > > > > Yet you're one of the few people caring about the KDE spin, where major > > > applications are duplicated or triplicated.There are 3 different web > > > browsers(!), 2 different package managers, 2 file managers. > > When you say "few people caring about the KDE spin", do you mean using it, > or > working on it? Well, this is what happens if one doesn't communicate in his native language. I wanted to say "people taking care of the KDE spin", meaning maintaining/fixing/developing. > If you're referring to users, I don't know what you're basing > this claim on. As for the software available, that's called choice. I know > it's a relative unknown in the GNOME world, as one option is shoved down > everyones' throat, but it's a key part of the KDE ideology, as well as GNU/ > Linux itself. > Assume good intentions. As is clear from previous conversation, this was not about KDE ideology, but about reducing the spin size, as Kevin complained. ___ 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: Change proposal discussion - Optimize SquashFS Size
On Sat, Feb 8, 2020 at 2:01 PM Bohdan Khomutskyi
wrote:
> I'd suggest not selecting any specific area to concentrate on, but to
> achieve an all-good solution that will combine the benefits, without
> specializing in one particular area.
>
Even if you can achieve some modest improvement in all areas together, you
still need to decide whether you prefer "50% improvement in area 1, and 2%
improvement in area 2 and 3" or "5% improvement in area 1, 2 and 3" (random
numbers used). So you need to decide your priorities, and usually not in
absolute scale ("area 1 is the top-most priority at all costs") but in
relative scale ("I'm willing to sacrifice that much in area 2 in order to
improve area 1 by this much"). Of course this is hard to codify, unless you
fancy writing a science paper with complicated equations, but mostly it's
enough to look at the numbers and pick the candidate that feels like
satisfying your preferences in the best way.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CPE Weekly: 2020-02-08
On Sat, Feb 8, 2020 at 10:39 PM Aoife Moloney wrote: > Hi everyone, > > > Welcome (back!) to the CPE team weekly project update mail! > If I can have a suggestion, add some formatting. I find these emails *extremely* hard to read. I never know what is a headline (but isn't), what should be a bullet point (but isn't), there are too many empty lines (including your signature) - I'm simply completely lost in the structure of the document. It feels like it has been exported from somewhere where it contained some formatting, but it has been munched through several systems and only plaintext in the lowest common denominator survived. If you can add either HTML formatting or at least plain-text formatting (something Markdown-style, doesn't need to conform to that format), it will make the report 97.3% more readable. Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji build fails on arch armv7hl
On Mon, 10 Feb 2020 at 10:24, Stephen John Smoogen wrote: > > > > Linux buildvm-armv7-07.arm.fedoraproject.org 5.3.13-300.fc31.armv7hl+lpae > #1 SMP Mon Nov 25 17:13:28 UTC 2019 armv7l armv7l armv7l GNU/Linux > > will work with release engineering to see if they can take this builder > out and reboot it. > > System has been rebooted. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packaging of Ansible collections
Igor Gnatenko (ignatenkobr...@fedoraproject.org) said: > Hello, > > Did anybody had an experience of packaging Ansible collections into an RPM? > > I guess if would be enough to put the files somewhere under > /usr/share/ansible, but not sure. Also I'm not sure what download URL could > be used. What is the goal of downstream collection packaging here - what collections are you looking to package and why? Bill ___ 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
Summary/Minutes from today's FESCo Meeting (2020-02-10)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 = #fedora-meeting-1: FESCO (2020-02-10) = Meeting started by sgallagh at 15:00:03 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2020-02-10/fesco.2020-02-10-15.00.log.html . Meeting summary - --- * init process (sgallagh, 15:00:03) * #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) (sgallagh, 15:02:30) * FESCo will wait one more week for feedback on the Change Proposal but is generally in favor (sgallagh, 15:16:23) * Next week's chair (sgallagh, 15:16:33) * ACTION: dcantrell to chair Feb 17 meeting (sgallagh, 15:17:16) * Open Floor (sgallagh, 15:17:39) * LINK: https://pagure.io/fesco/issue/2338 (mhroncok, 15:18:19) * LINK: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IN5GRXPY6AP5C4WNOV7GNDQ3Z5NRMTSJ/ (mhroncok, 15:22:08) * ACTION: FESCo members are requested to chime in on the devel list thread "RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers" (sgallagh, 15:29:52) * FESCo is collecting feedback about our security policy. The current policy has not been followed yet, and we want to start doing that but also be more friendly to the maintainers. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IN5GRXPY6AP5C4WNOV7GNDQ3Z5NRMTSJ/ (mhroncok, 15:30:50) Meeting ended at 15:35:22 UTC. Action Items - * dcantrell to chair Feb 17 meeting * FESCo members are requested to chime in on the devel list thread "RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers" Action Items, by person - --- * dcantrel * dcantrell to chair Feb 17 meeting * dcantrell * dcantrell to chair Feb 17 meeting * **UNASSIGNED** * FESCo members are requested to chime in on the devel list thread "RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers" People Present (lines said) - --- * sgallagh (56) * mhroncok (47) * dcantrell (25) * nirik (24) * zodbot (13) * zbyszek (10) * pwhalen (5) * bookwar (4) * decathorpe (4) * bcotton (1) * smooge (1) * ignatenkobrain (0) * dcantrel (0) * contyk (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -BEGIN PGP SIGNATURE- Version: Mailvelope v4.2.1 Comment: https://www.mailvelope.com wsBcBAEBCgAGBQJeQXhyAAoJEBjBIKj7Ux0TL50H/RweQjeOdKNBUS42mT7O ND5F2qz+yOTmdtLV0D6hk8J7/rG2Bjif0zc/lzkww1Yup3T13MtpJMYzrai9 EUfTb9Wb2qWLpUfQ/XAzV41FbnSqNZs3J42TrGrK+Vz3H7GIV0zEBArmdVsM qZvMTaR/qIKCSf/RrCXEA5v1xFZ0a4A7U6n5PlB2UnKWhptDVRfK3tFtYDWJ 9Gsd5+oRHKFX5PW77q5tFb6jMl5332q7kLFqZnlNMOEl+fdsXyDDZEGyUoMh AchKF61gbQ2BD0MNhzFNCeNXHcdjP/0pyEyimWZUz4op9lDFpKyWjPE3Mf0g 9Sng+bc2xG7Ot+77LyjOS9o= =RpTx -END 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: koji build fails on arch armv7hl
On Mon, 10 Feb 2020 at 10:07, John Reiser wrote:
> On 2/10/20 6:20 AM, Martin Gansser wrote:
>
> > the koji build on armv7h fails by this command:
> > koji build rawhide --arch=armv7hl --scratch
> /home/martin/rpmbuild/SRPMS/speed-dreams-2.2.2-6.fc31.src.rpm
>
> >File "/usr/lib/python3.7/site-packages/requests/models.py", line 828,
> in content
> > self._content = b''.join(self.iter_content(CONTENT_CHUNK_SIZE)) or
> b''
> > MemoryError
>
> Internet search says "python Memory Error" probably means running out of
> address space,
> such as on a 32-bit armv7hl. What uses lots of address space? Could
> there be
> too much contention from other jobs on the machine? Paging space (swap
> space)
> is a "temporary" constraint on address space of every running processes
>
>
The armv7 builders are virtual machines with 24 GB of ram per system. I
believe that there is only 1 build per builder at a time so this build is
going to contend with itself. However, I believe any process is going to be
limited to something under 4GB (3.6?) so that is going to be the 'first'
thing to look at. The next thing would be to look to see if there are
'hardware' errors on the guest.
And yes.. yes there are:
[2268887.373175] Alignment trap: not handling instruction ed848a00 at
[<004d0b50>]
[2268887.375306] 8<--- cut here ---
[2268887.376417] Unhandled fault: alignment exception (0xa21) at 0x00c95129
[2268887.379468] pgd = 9ff51f2a
[2268887.380644] [00c95129] *pgd=54cbf003, *pmd=4aa90003,
*pte=e4b530ef5f
[2268887.383027] Alignment trap: not handling instruction ed848a00 at
[<004d0b50>]
[2268887.385491] 8<--- cut here ---
[2268887.386614] Unhandled fault: alignment exception (0xa21) at 0x00c9512a
[2268887.388768] pgd = 9ff51f2a
[Mon Feb 10 06:19:07 2020] Alignment trap: not handling instruction
ed848b00 at [<00490e50>]
[Mon Feb 10 06:19:07 2020] 8<--- cut here ---
[Mon Feb 10 06:19:07 2020] Unhandled fault: alignment exception (0xa21) at
0x00ef5141
[Mon Feb 10 06:19:07 2020] pgd = ffe2d8d0
[Mon Feb 10 06:19:07 2020] [00ef5141] *pgd=467ee003, *pmd=434bb003,
*pte=e4a9dd4f5f
[Mon Feb 10 06:19:07 2020] Alignment trap: not handling instruction
ed848b00 at [<00490e50>]
[Mon Feb 10 06:19:07 2020] 8<--- cut here ---
[Mon Feb 10 06:19:07 2020] Unhandled fault: alignment exception (0xa21) at
0x00ef5142
[Mon Feb 10 06:19:07 2020] pgd = ffe2d8d0
[Mon Feb 10 06:19:07 2020] [00ef5142] *pgd=467ee003, *pmd=434bb003,
*pte=e4a9dd4f5f
Linux buildvm-armv7-07.arm.fedoraproject.org 5.3.13-300.fc31.armv7hl+lpae
#1 SMP Mon Nov 25 17:13:28 UTC 2019 armv7l armv7l armv7l GNU/Linux
will work with release engineering to see if they can take this builder out
and reboot it.
> > During handling of the above exception, another exception occurred:
>
> >File "/usr/sbin/kojid", line 1339, in handler
> > fn = self.localPath("work/%s" % pkg)
> >File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 489, in
> localPath
> > resp.close()
> > UnboundLocalError: local variable 'resp' referenced before assignment
>
> That's a bug in the exception handler.
> ___
> 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
>
--
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji build fails on arch armv7hl
On 2/10/20 6:20 AM, Martin Gansser wrote:
the koji build on armv7h fails by this command:
koji build rawhide --arch=armv7hl --scratch
/home/martin/rpmbuild/SRPMS/speed-dreams-2.2.2-6.fc31.src.rpm
File "/usr/lib/python3.7/site-packages/requests/models.py", line 828, in
content
self._content = b''.join(self.iter_content(CONTENT_CHUNK_SIZE)) or b''
MemoryError
Internet search says "python Memory Error" probably means running out of
address space,
such as on a 32-bit armv7hl. What uses lots of address space? Could there be
too much contention from other jobs on the machine? Paging space (swap space)
is a "temporary" constraint on address space of every running processes
During handling of the above exception, another exception occurred:
File "/usr/sbin/kojid", line 1339, in handler
fn = self.localPath("work/%s" % pkg)
File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 489, in localPath
resp.close()
UnboundLocalError: local variable 'resp' referenced before assignment
That's a bug in the exception handler.
___
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: [Retired] gstreamer & gstreamer-plugins-base
> > > > > As long as it builds and functions, why remove it? > > > > > > > > Because it has lots of critical vulnerabilities and endangers end-user > > > > devices. > > > > > > Please name a couple. Nobody has provided a single specific case of an > > > unfixed security vulnerability affecting gstreamer 0.10.x yet. > > > > CVE-2016-9634, CVE-2016-9635, CVE-2016-9636, CVE-2016-9808, > > CVE-2016-9807, CVE-2016-9445, CVE-2016-9446, CVE-2016-9447, > > CVE-2016-9809 > > I asked for unfixed ones. All the above are fixed in RHEL7 and most are > fixed in RHEL6 as well. Also most of them are low impact. So, where are > all the critical ones that are not fixed? What's this got to do with RHEL? ___ 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: [Retired] gstreamer & gstreamer-plugins-base
On Monday, 10 February 2020 at 15:32, Peter Robinson wrote: > > On Monday, 10 February 2020 at 10:07, Vitaly Zaitsev via devel wrote: > > > On 10.02.2020 09:43, John M. Harris Jr wrote: > > > > As long as it builds and functions, why remove it? > > > > > > Because it has lots of critical vulnerabilities and endangers end-user > > > devices. > > > > Please name a couple. Nobody has provided a single specific case of an > > unfixed security vulnerability affecting gstreamer 0.10.x yet. > > CVE-2016-9634, CVE-2016-9635, CVE-2016-9636, CVE-2016-9808, > CVE-2016-9807, CVE-2016-9445, CVE-2016-9446, CVE-2016-9447, > CVE-2016-9809 I asked for unfixed ones. All the above are fixed in RHEL7 and most are fixed in RHEL6 as well. Also most of them are low impact. So, where are all the critical ones that are not fixed? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help needed to get dependencies in EPEL 8 for pagure
On 2/8/20 8:59 PM, Neal Gompa wrote: > Hey all, > > I've been trying to get Pagure into EPEL 8 for a couple of months now > so that we can upgrade our Pagure instances to RHEL 8[1]. > > Thankfully, most of Pagure's dependencies *are* now present in EPEL 8, > so there's only a few that need to be added. > > The list of Pagure dependencies missing are below: > > * gitolite3: limb Headed to updates-testing. > * python-jenkins: cottsay > * python-binaryornot: pingou > * python-celery: bowlofeggs, mrunge, pingou, ngompa > * python-flask-wtf: pingou > * python-wtforms: kumarpraveen, pjp, sundaram > * python-pygit2: pwalter > > Celery is in a special position here, because it has a number of > missing dependencies, too (which is why I haven't branched and built > it yet): > > * python-kombu: mrunge, pingou, fab, pjp, sundaram > * python-billiard: mrunge, pingou, fab, pjp, sundaram > * python-amqp: eharney > * python-vine: mrunge > * python-case: mrunge > > A note here: RHEL 8 ships libgit2 0.26.8, so we need pygit2 0.26.x. > This is already what we ship in the EPEL 7 branch, so that can just be > branched into a new epel8 branch and built. > > Fortunately, I only need Python 3 variants of all these things, as > Pagure is Python 3 in Fedora and I intend to keep it that way for EPEL > 8. This is also a prerequisite for dropping Python 2 support in Pagure > for 6.0, as we need all Pagure production servers to be able to move > to Python 3 first (and our servers run RHEL instead of Fedora). > > Thank you all in advance! > > [1]: > https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/RI5RQOPLWHV2V3XPVD3YDYNZEOIO4SYL/ > -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie ___ 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
[EPEL-devel] Retiring mingw-* packages from EPEL 7
If you're in the CC line, then I'm intending to retire your package *in the EPEL 7 branch only* in the next few days. I will also close any bugs filed against the package in RHEL or EPEL 7. As we will remove packages such as mingw-filesystem, mingw-gcc etc from EPEL 7 too, your package will likely no longer be compilable. That's the immediate reason for retiring these packages. Use Fedora for Windows development instead. For the longer reasons for this, see: https://pagure.io/fesco/issue/2333 https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/RXU4G27Q7FVR4DMI7OMQDUQ22GAFMBME/ Full list of packages (107) below. Note that some of these are dead packages in Fedora. mingw-angleproject mingw-atk mingw-binutils mingw-boost mingw-bzip2 mingw-cairo mingw-c-ares mingw-cmocka mingw-crt mingw-curl mingw-dbus mingw-dlfcn mingw-enchant mingw-expat mingw-filesystem mingw-flac mingw-fontconfig mingw-freetype mingw-gcc mingw-gdb mingw-gdk-pixbuf mingw-gettext mingw-glib2 mingw-glib-networking mingw-gmp mingw-gnutls mingw-gsm mingw-gstreamer1 mingw-gstreamer1-plugins-base mingw-gtk2 mingw-gtk3 mingw-harfbuzz mingw-headers mingw-hunspell mingw-icu mingw-jasper mingw-libffi mingw-libgcrypt mingw-libgpg-error mingw-libidn mingw-libidn2 mingw-libjpeg-turbo mingw-libogg mingw-libpng mingw-libsoup mingw-libssh2 mingw-libtasn1 mingw-libtheora mingw-libtiff mingw-libvorbis mingw-libwebp mingw-libxml2 mingw-libxslt mingw-llvm mingw-log4c mingw-nettle mingw-nsis mingw-nspr mingw-openssl mingw-opus mingw-p11-kit mingw-pango mingw-pcre mingw-pdcurses mingw-physfs mingw-pixman mingw-pkg-config mingw-qt mingw-qt5-qt3d mingw-qt5-qtactiveqt mingw-qt5-qtbase mingw-qt5-qtdeclarative mingw-qt5-qtgraphicaleffects mingw-qt5-qtimageformats mingw-qt5-qtlocation mingw-qt5-qtmultimedia mingw-qt5-qtquick1 mingw-qt5-qtscript mingw-qt5-qtsensors mingw-qt5-qtsvg mingw-qt5-qtsystems mingw-qt5-qttools mingw-qt5-qttranslations mingw-qt5-qtwebkit mingw-qt5-qtwebsockets mingw-qt5-qtwinextras mingw-qt5-qtxmlpatterns mingw-readline mingw-SDL mingw-SDL2 mingw-SDL2_image mingw-SDL2_mixer mingw-SDL_image mingw-SDL_mixer mingw-speex mingw-sqlite mingw-tcl mingw-termcap mingw-w64-tools mingw-wavpack mingw-webkitgtk mingw-webkitgtk3 mingw-win-iconv mingw-winpthreads mingw-winstorecompat mingw-xz mingw-zlib Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: [Retired] gstreamer & gstreamer-plugins-base
> On Monday, 10 February 2020 at 10:07, Vitaly Zaitsev via devel wrote: > > On 10.02.2020 09:43, John M. Harris Jr wrote: > > > As long as it builds and functions, why remove it? > > > > Because it has lots of critical vulnerabilities and endangers end-user > > devices. > > Please name a couple. Nobody has provided a single specific case of an > unfixed security vulnerability affecting gstreamer 0.10.x yet. CVE-2016-9634, CVE-2016-9635, CVE-2016-9636, CVE-2016-9808, CVE-2016-9807, CVE-2016-9445, CVE-2016-9445, CVE-2016-9447, CVE-2016-9809. there's others, not to mention issues likely found and fixed in gst1 that weren't back ported to the 0.10 series, and even if there were bugs backported to the Fedora releases given there's no upstream support it would a "scrape the internet" for the fixes scenario. The issues with media and vulnerabilities are well known, Google has had many many large issues with android with the same sort of issues which caused them to completely rewrite their media stack to run completely sandboxed, somthing that the old version of gstreamer doesn't support. ___ 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: [Retired] gstreamer & gstreamer-plugins-base
On Monday, 10 February 2020 at 10:07, Vitaly Zaitsev via devel wrote: > On 10.02.2020 09:43, John M. Harris Jr wrote: > > As long as it builds and functions, why remove it? > > Because it has lots of critical vulnerabilities and endangers end-user > devices. Please name a couple. Nobody has provided a single specific case of an unfixed security vulnerability affecting gstreamer 0.10.x yet. Something like https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ and https://blogs.gnome.org/mcatanzaro/2017/02/08/an-update-on-webkit-security-updates/ for gstreamer would be great to drive the point about security status of the old 0.10 branch. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
koji build fails on arch armv7hl
Hi,
the koji build on armv7h fails by this command:
koji build rawhide --arch=armv7hl --scratch
/home/martin/rpmbuild/SRPMS/speed-dreams-2.2.2-6.fc31.src.rpm
error message:
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 482, in localPath
resp = requests.get(url)
File "/usr/lib/python3.7/site-packages/requests/api.py", line 75, in get
return request('get', url, params=params, **kwargs)
File "/usr/lib/python3.7/site-packages/requests/api.py", line 60, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 533, in
request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 686, in
send
r.content
File "/usr/lib/python3.7/site-packages/requests/models.py", line 828, in
content
self._content = b''.join(self.iter_content(CONTENT_CHUNK_SIZE)) or b''
MemoryError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/koji/daemon.py", line 1294, in runTask
response = (handler.run(),)
File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 313, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python3.7/site-packages/koji/util.py", line 263, in
call_with_argcheck
return func(*args, **kwargs)
File "/usr/sbin/kojid", line 1339, in handler
fn = self.localPath("work/%s" % pkg)
File "/usr/lib/python3.7/site-packages/koji/tasks.py", line 489, in localPath
resp.close()
UnboundLocalError: local variable 'resp' referenced before assignment
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=41447762
how can i fix this ?
___
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: Late Fedora 32 Self-Contained Change proposal: ARM Release Criteria Changes
Heya, 20/2/10 14:46(e)an, Ben Cotton igorleak idatzi zuen: FESCo is considering[1] the late Change proposal[2] below. == Summary == Proposed changes to the Desktop release criteria for ARM and AArch64 in Fedora 32: * drop Xfce on 32-bit ARM from release blocking desktops * add Workstation on AArch64 to release blocking desktops == Owner == * Name: [[User:pwhalen| Paul Whalen]] * Email: pwha...@fedoraproject.org * Responsible WG: ARM SIG == Detailed Description == In Fedora 32 we will have a couple new additions to release blocking deliverables including IoT and CoreOS. In order to reduce the overall test coverage and release blocking desktops we propose no longer blocking on the 32-Bit ARM Xfce Desktop spin, and adding Workstation on AArch64 as a release blocking desktop. The AArch64 Workstation image has been available for a number of Fedora releases and contains the same package set as x86_64 where it is heavily tested. I don't see nor coreos nor iot on https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking . Shouldn't they be already listed there to be blocker deliverables in Fedora 32? Release blocking image changes: * Drop: Spins/armhfp/images/Fedora-Xfce-armhfp-_RELEASE_MILESTONE_-sda.raw.xz * Add: Workstation/aarch64/images/Fedora-Workstation-aarch64-_RELEASE_MILESTONE_-sda.raw.xz == Benefit to Fedora == This change will reduce the release blocking desktops and potential for blocker bugs. == Scope == * Proposal owners: Changes to the Wiki including testing templates, release criteria and deliverables. * Other developers: N/A (not a System Wide Change) * Release engineering: Small tweaks to the pungi config to make the compose fail on AArch64 Workstation and not fail on armhfp Xfce. The AArch64 Workstation spin has been available for a number of years. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == N/A (not a System Wide Change) == User Experience == The same Desktop experience enjoyed on x86_64. The Armhfp Xfce Desktop spin will still be produced and tested to ensure functionality. == Dependencies == N/A (not a System Wide Change) == Documentation == This change will require some updates to Release Criteria, release blocking deliverables lists and testing matrices. ___ 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
Open NeuroFedora meeting: 1600 UTC on Tuesday, 11th February
Hello everyone, You are invited to attend the next Open NeuroFedora team meeting this week on Tuesday at 1600UTC in #fedora-neuro on IRC (Freenode): https://webchat.freenode.net/?channels=#fedora-neuro You can convert the meeting time to your local time using: $ date --date='TZ="UTC" 1500 next Tue' or use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NeuroFedora+meeting=20200211T16=1440=1 The meeting will be chaired by @ankursinha. The agenda for the meeting is: - Introductions and roll call. - Tasks from last week's meeting: NA - Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Neuroscience query of the week. - Next meeting day, and chair. - Open floor. In the "Neuroscience query of the week" section, attendees can ask about/discuss a neuroscience topic that they are curious about. A few tickets on Pagure need comments. Please go through them beforehand and add your feedback. We hope to see you there! -- 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
Late Fedora 32 Self-Contained Change proposal: ARM Release Criteria Changes
FESCo is considering[1] the late Change proposal[2] below. == Summary == Proposed changes to the Desktop release criteria for ARM and AArch64 in Fedora 32: * drop Xfce on 32-bit ARM from release blocking desktops * add Workstation on AArch64 to release blocking desktops == Owner == * Name: [[User:pwhalen| Paul Whalen]] * Email: pwha...@fedoraproject.org * Responsible WG: ARM SIG == Detailed Description == In Fedora 32 we will have a couple new additions to release blocking deliverables including IoT and CoreOS. In order to reduce the overall test coverage and release blocking desktops we propose no longer blocking on the 32-Bit ARM Xfce Desktop spin, and adding Workstation on AArch64 as a release blocking desktop. The AArch64 Workstation image has been available for a number of Fedora releases and contains the same package set as x86_64 where it is heavily tested. Release blocking image changes: * Drop: Spins/armhfp/images/Fedora-Xfce-armhfp-_RELEASE_MILESTONE_-sda.raw.xz * Add: Workstation/aarch64/images/Fedora-Workstation-aarch64-_RELEASE_MILESTONE_-sda.raw.xz == Benefit to Fedora == This change will reduce the release blocking desktops and potential for blocker bugs. == Scope == * Proposal owners: Changes to the Wiki including testing templates, release criteria and deliverables. * Other developers: N/A (not a System Wide Change) * Release engineering: Small tweaks to the pungi config to make the compose fail on AArch64 Workstation and not fail on armhfp Xfce. The AArch64 Workstation spin has been available for a number of years. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == N/A (not a System Wide Change) == User Experience == The same Desktop experience enjoyed on x86_64. The Armhfp Xfce Desktop spin will still be produced and tested to ensure functionality. == Dependencies == N/A (not a System Wide Change) == Documentation == This change will require some updates to Release Criteria, release blocking deliverables lists and testing matrices. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org
Late Fedora 32 Self-Contained Change proposal: ARM Release Criteria Changes
FESCo is considering[1] the late Change proposal[2] below. == Summary == Proposed changes to the Desktop release criteria for ARM and AArch64 in Fedora 32: * drop Xfce on 32-bit ARM from release blocking desktops * add Workstation on AArch64 to release blocking desktops == Owner == * Name: [[User:pwhalen| Paul Whalen]] * Email: pwha...@fedoraproject.org * Responsible WG: ARM SIG == Detailed Description == In Fedora 32 we will have a couple new additions to release blocking deliverables including IoT and CoreOS. In order to reduce the overall test coverage and release blocking desktops we propose no longer blocking on the 32-Bit ARM Xfce Desktop spin, and adding Workstation on AArch64 as a release blocking desktop. The AArch64 Workstation image has been available for a number of Fedora releases and contains the same package set as x86_64 where it is heavily tested. Release blocking image changes: * Drop: Spins/armhfp/images/Fedora-Xfce-armhfp-_RELEASE_MILESTONE_-sda.raw.xz * Add: Workstation/aarch64/images/Fedora-Workstation-aarch64-_RELEASE_MILESTONE_-sda.raw.xz == Benefit to Fedora == This change will reduce the release blocking desktops and potential for blocker bugs. == Scope == * Proposal owners: Changes to the Wiki including testing templates, release criteria and deliverables. * Other developers: N/A (not a System Wide Change) * Release engineering: Small tweaks to the pungi config to make the compose fail on AArch64 Workstation and not fail on armhfp Xfce. The AArch64 Workstation spin has been available for a number of years. * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == N/A (not a System Wide Change) == User Experience == The same Desktop experience enjoyed on x86_64. The Armhfp Xfce Desktop spin will still be produced and tested to ensure functionality. == Dependencies == N/A (not a System Wide Change) == Documentation == This change will require some updates to Release Criteria, release blocking deliverables lists and testing matrices. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: koji build error
On 10/02/2020 13:31, Harsh Jain wrote: I am trying to package elementary-tweaks and am getting failed build in koji I cannot find where the build is failing. This is my first time packaging something and have no idea where to look for errors in the build logs . Any help is appreciated . Here is the build https://koji.fedoraproject.org/koji/taskinfo?taskID=41447194 and here are the spec and rpm files https://github.com/a-mere-peasant/elementary-tweaks-fedora You appear to be mussing a BuildRequire for switchboard-devel. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-02-10.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change argyllcms orphan, rhughes 2 weeks ago clang7.0 orphan, sergesanspaille, 0 weeks ago tstellar exciting marcindulak, orphan 3 weeks ago felix-scr-maven-pluginjerboaa, jkang, orphan 0 weeks ago hibernate lef, odubaj, orphan 1 weeks ago htmlcleaner besser82, marcindulak, orphan3 weeks ago ini4j orphan 0 weeks ago java-augeas bkearney, orphan 2 weeks ago jboss-transaction-1.2-api orphan 4 weeks ago jettison mizdebsk, orphan 4 weeks ago jetty-artifact-remote-resources mizdebsk, orphan 4 weeks ago jetty-assembly-descriptorsmizdebsk, orphan 4 weeks ago jetty-test-policy mizdebsk, orphan 4 weeks ago llvm7.0 jistone, orphan, 0 weeks ago sergesanspaille, tstellar maven-jarsigner-pluginjcapik, mizdebsk, orphan 2 weeks ago maven-shared-jarsignermizdebsk, orphan 2 weeks ago python-bz2filebesser82, orphan 0 weeks ago rubygem-pam bkearney, orphan 2 weeks ago slack-cleaner orphan 4 weeks ago sugar-moonbkearney, orphan 2 weeks ago sugar-turtleart bkearney, erikos, orphan, sdz2 weeks ago swingxorphan 5 weeks ago The following packages require above mentioned packages: Depending on: argyllcms (1), status change: 2020-01-22 (2 weeks ago) foo2zjs (maintained by: cjatherton) foo2zjs-0.20170412-13.fc32.x86_64 requires argyllcms = 1.9.2-8.fc31 Depending on: llvm7.0 (1), status change: 2020-02-06 (0 weeks ago) clang7.0 (maintained by: orphan, sergesanspaille, tstellar) clang7.0-7.0.1-10.fc31.1.src requires llvm7.0-devel = 7.0.1-4.fc32.2, llvm7.0-static = 7.0.1-4.fc32.2 clang7.0-libs-7.0.1-10.fc31.1.i686 requires libLLVM-7.so, libLLVM-7.so(LLVM_7) clang7.0-libs-7.0.1-10.fc31.1.x86_64 requires libLLVM-7.so()(64bit), libLLVM-7.so(LLVM_7)(64bit) Depending on: maven-jarsigner-plugin (1), status change: 2020-01-26 (2 weeks ago) jetty-test-policy (maintained by: mizdebsk, orphan) jetty-test-policy-1.2-23.fc32.src requires mvn(org.apache.maven.plugins:maven-jarsigner-plugin) = 1.4 Depending on: maven-shared-jarsigner (2), status change: 2020-01-26 (2 weeks ago) maven-jarsigner-plugin (maintained by: jcapik, mizdebsk, orphan) maven-jarsigner-plugin-1.4-10.fc32.noarch requires mvn(org.apache.maven.shared:maven-jarsigner) = 1.3.2 maven-jarsigner-plugin-1.4-10.fc32.src requires mvn(org.apache.maven.shared:maven-jarsigner) = 1.3.2 jetty-test-policy (maintained by: mizdebsk, orphan) jetty-test-policy-1.2-23.fc32.src requires mvn(org.apache.maven.plugins:maven-jarsigner-plugin) = 1.4 Affected (co)maintainers besser82: python-bz2file, htmlcleaner bkearney: rubygem-pam, java-augeas, sugar-moon, sugar-turtleart cjatherton: argyllcms erikos: sugar-turtleart jcapik: maven-shared-jarsigner, maven-jarsigner-plugin jerboaa: felix-scr-maven-plugin jistone: llvm7.0 jkang: felix-scr-maven-plugin lef: hibernate marcindulak: exciting, htmlcleaner mizdebsk: maven-shared-jarsigner, jettison, jetty-artifact-remote-resources, jetty-test-policy, jetty-assembly-descriptors, maven-jarsigner-plugin odubaj: hibernate rhughes: argyllcms sdz: sugar-turtleart sergesanspaille: llvm7.0, clang7.0 tstellar: llvm7.0, clang7.0 -- The script creating this output is run
Schedule for Mondays's FESCo Meeting (2020-02-10)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Following is the list of topics that will be discussed in the FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 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-02-10 15: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 = Nonresponsive maintainer: David Dick (ddick) https://pagure.io/fesco/issue/2338 APPROVED (+4, 0, -0) F32 Self-Contained Change: PostgreSQL 12 https://pagure.io/fesco/issue/2337 APPROVED (+3, 0, -0) Approve new Workstation WG governance document https://pagure.io/fesco/issue/2336 APPROVED (+6,0,-0) F32 Self-Contained Change: Python3-rdiff-backup https://pagure.io/fesco/issue/2335 APPROVED(+5,0,-0) F32 Self-Contained Change: Update Haskell packages to Stackage LTS 14 https://pagure.io/fesco/issue/2334 APPROVED (+5,0,-0) Nonresponsive maintainer: Steve Jenkins stevej https://pagure.io/fesco/issue/2330 APPROVED (+5,0,-1) Python2 exception for mailman https://pagure.io/fesco/issue/2312 APPROVED (+3,0,-0) = New business = #topic #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE (32bit), Add Workstation(64bit) https://pagure.io/fesco/issue/2339 = 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. -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5BWyAACgkQRduFpWgo bRFsuQwAgIBqiBm5nRDeRl7EciZC1+QknkV2Je9ODmy+mo52JF3HorcuZdUoW85B q8MhBYvFfHJkElQMzpyQR4EYOHBhWy2JALo7Sc07ehHha9kR3FlIAreLgBBZq5vP W7pt0Yf3ajufRUgPVo9hdQt6iF37xQ+GuIwyYYUzkadFGW5y7ZBg+GtUZ66VM6C9 Nq9rE6HkfhrZ5/nI2sDYnePA+gLhGbMrW1sTbIzCo6DI2n0h0R45NUiGeuUZ9JBR 4TVhFg70VbtQ/D6mWVosYoQRK0BX8+YnMmS36uNxkEszDjzU6AmO0om9wFG/+w1l 6hcWjq4rBY4T3qj5k2Dg6rH8mNkiRxuyC0mv7+4MIPjdIwv7JWz7QMkbKuqL9HT3 fsuNHwkFuQ0yjEF7p35XsBIgwWi+rF3gby+3cE6cHfZvFyHWXL6PxmRpy1i0wl5f ywuYdAfRuvKhDOTWMhvWYMLwEnoQ4gI2m+yqiTGvC8c8rnI7IDXMPGy8ogu+7eYP MWFKY6F4 =276U -END 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
koji build error
Hey, I am trying to package elementary-tweaks and am getting failed build in koji I cannot find where the build is failing. This is my first time packaging something and have no idea where to look for errors in the build logs . Any help is appreciated . Here is the build https://koji.fedoraproject.org/koji/taskinfo?taskID=41447194 and here are the spec and rpm files https://github.com/a-mere-peasant/elementary-tweaks-fedora Thanks, Harsh ___ 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: Orphaning owncloud and nextcloud
This is excellent news! Thank you, Iván! On Sat, Feb 8, 2020 at 9:34 PM Ivan Chavero wrote: > > > On Sat, Feb 8, 2020 at 1:43 PM Miro Hrončok wrote: > >> On 08. 02. 20 20:29, Ivan Chavero wrote: >> > The nextcloud package updated for 18.0.0 is now on rawhide, 31 and 30 , >> sorry >> > for the delay. I had to do a >> > mayo refactor and careful testing. >> >> Thanks for the update. Is such a major overhaul applicable for already >> released >> Fedoras? >> > > The refactor was only for the spec file and patches, the file locations > and configuration files are the same so it > should not affect updates. > > >> >> Could you please close the relevant bugzillas as well? >> > > I've set the main bug [1] as MODIFIED and closed other bugs as duplicates > it. There are other bugs > related to the previous version that I will close as CURRENTRELEASE. > > Cheers, > Iván > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1710115 > >> >> -- >> 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: Highlights from the latest Copr release
Pavel Raiskup wrote: > - The EOL chroot policy scripts responsible for notifying users about > upcoming removals were fixed, users should now always be notified - and > if for some reason they are not, the EOL chroot will not be removed. This is still inherently flawed and unsafe because you have absolutely no way of guaranteeing that the notification mail actually reached the maintainer, only that it has been sent. E-mail is not a certified delivery mechanism. The whole concept of opt-out deletion is inherently flawed. It is unacceptable to delete user data without explicit confirmation. And of course, the fix comes too late for the repositories that you folks already irremediably destroyed with your deletion rampage. E.g., the latest release of Kannolo, Kannolo 27, is now missing one of its default repositories and I have no way to fix that (and neither do you, for that matter – the only way the problem could be solved would be to allow building for Fedora 27 again, then I could simply build the packages again). Kevin Kofler ___ 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
[Bug 1801108] Upgrade perl-XML-Hash-LX to 0.07
https://bugzilla.redhat.com/show_bug.cgi?id=1801108 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-XML-Hash-LX-0.70.0-1.f ||c32 Resolution|--- |RAWHIDE Last Closed||2020-02-10 12:21:47 --- Comment #1 from Petr Pisar --- This release disabled loading external data. Incompatible change. Suitable for Rawhide only. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: Any issues booting Rawhide kernel-5.6.0-0.rc0.git1.2.fc32.x86_64?
On Thu, Feb 06, 2020 at 03:10:47PM -0600, Bruno Wolff III wrote: > On Thu, Feb 06, 2020 at 07:32:09 -0600, > Bruno Wolff III wrote: > > > >5.6.0-0.rc0.git2.1.fc32.x86_64 works. If last nights rawhide > >compose finishes successfully this morning, there should be a > >working kernel in the repo. The nodebug repo hasn't been updated > >since the work around was implemented, so right now you can't get > >a good one there either. You can get a good kernel from koji > >though. > > The compose failed, but there is now a working kernel in the nodebug > repo. Can finally now confirm that the latest nodebug kernel works, thanks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 09, 2020 14:23:12 -0500, Neal Gompa wrote: > On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini wrote: > > > > > > > > What are our other options? (Of course, I assume bundling the Gradle > > > binary for Fedora is out.) > > > > - Option 1: Convert package build systems from gradle to maven. > > Pro: Works with current packaging tools. > > Con: might make package updates harder. > > > > As I think we can see here, this option doesn't really scale well and > causes more problems than it solves. I'll have a look at this to see what the effort required here is. If it can be done automatically, it may not be so hard. I found this, for example: https://github.com/tvaughan77/gradle2maven > > - Option 2: Bring back gradle, possibly in a multi-step bootstrapping > > process (like Neal outlined), with a "full-bundled" build is done > > first to get things off the ground, and after that, components can be > > de-bundled one after another. > > Pro: no changes necessary for packages built with gradle. > > Con: Lots of work packaging gradle and its ecosystem. > > > > At least initially, it shouldn't be bad, and unbundling can be done > iteratively with relatively little pain. This has the benefit of > unlocking most of the JVM ecosystem for Fedora again, as Gradle has > become the most popular option for building stuff on the JVM. I certainly see your point, but given the (perceived?) lack of Java focussed man-power in the community at the moment, it is hard to say if: - we'll have enough resources to unbundle it in the short-term future; - we'll have enough resources to maintain the whole unbundled ecosystem in the long-term future. I.e., will this last in the long term, or will we be having such a conversation again soon? I guess we can just keep the bundled version as long as we need to, but before we go down this option: how many folks in the community can commit to helping maintain Gradle, at least in its bundled form, in the long term, say till F34 release? If we don't have enough resources for this, then the initial effort may not be worth investing in the first place. I can help with general packaging, I don't do a lot of Java, and I certainly don't do a lot of Gradle, so I would not want to be the single or main point-of-contact for this. My focus in Fedora is SciTech/NeuroFedora, and I do not have cycles to also prioritise Java/Gradle work. > -- 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2020-02-10.txt grep it for your FAS username and follow the dependency chain. Package (co)maintainers Status Change argyllcms orphan, rhughes 2 weeks ago clang7.0 orphan, sergesanspaille, 0 weeks ago tstellar exciting marcindulak, orphan 3 weeks ago felix-scr-maven-pluginjerboaa, jkang, orphan 0 weeks ago hibernate lef, odubaj, orphan 1 weeks ago htmlcleaner besser82, marcindulak, orphan3 weeks ago ini4j orphan 0 weeks ago java-augeas bkearney, orphan 2 weeks ago jboss-transaction-1.2-api orphan 4 weeks ago jettison mizdebsk, orphan 4 weeks ago jetty-artifact-remote-resources mizdebsk, orphan 4 weeks ago jetty-assembly-descriptorsmizdebsk, orphan 4 weeks ago jetty-test-policy mizdebsk, orphan 4 weeks ago llvm7.0 jistone, orphan, 0 weeks ago sergesanspaille, tstellar maven-jarsigner-pluginjcapik, mizdebsk, orphan 2 weeks ago maven-shared-jarsignermizdebsk, orphan 2 weeks ago python-bz2filebesser82, orphan 0 weeks ago rubygem-pam bkearney, orphan 2 weeks ago slack-cleaner orphan 4 weeks ago sugar-moonbkearney, orphan 2 weeks ago sugar-turtleart bkearney, erikos, orphan, sdz2 weeks ago swingxorphan 5 weeks ago The following packages require above mentioned packages: Depending on: argyllcms (1), status change: 2020-01-22 (2 weeks ago) foo2zjs (maintained by: cjatherton) foo2zjs-0.20170412-13.fc32.x86_64 requires argyllcms = 1.9.2-8.fc31 Depending on: llvm7.0 (1), status change: 2020-02-06 (0 weeks ago) clang7.0 (maintained by: orphan, sergesanspaille, tstellar) clang7.0-7.0.1-10.fc31.1.src requires llvm7.0-devel = 7.0.1-4.fc32.2, llvm7.0-static = 7.0.1-4.fc32.2 clang7.0-libs-7.0.1-10.fc31.1.i686 requires libLLVM-7.so, libLLVM-7.so(LLVM_7) clang7.0-libs-7.0.1-10.fc31.1.x86_64 requires libLLVM-7.so()(64bit), libLLVM-7.so(LLVM_7)(64bit) Depending on: maven-jarsigner-plugin (1), status change: 2020-01-26 (2 weeks ago) jetty-test-policy (maintained by: mizdebsk, orphan) jetty-test-policy-1.2-23.fc32.src requires mvn(org.apache.maven.plugins:maven-jarsigner-plugin) = 1.4 Depending on: maven-shared-jarsigner (2), status change: 2020-01-26 (2 weeks ago) maven-jarsigner-plugin (maintained by: jcapik, mizdebsk, orphan) maven-jarsigner-plugin-1.4-10.fc32.noarch requires mvn(org.apache.maven.shared:maven-jarsigner) = 1.3.2 maven-jarsigner-plugin-1.4-10.fc32.src requires mvn(org.apache.maven.shared:maven-jarsigner) = 1.3.2 jetty-test-policy (maintained by: mizdebsk, orphan) jetty-test-policy-1.2-23.fc32.src requires mvn(org.apache.maven.plugins:maven-jarsigner-plugin) = 1.4 Affected (co)maintainers besser82: python-bz2file, htmlcleaner bkearney: rubygem-pam, java-augeas, sugar-moon, sugar-turtleart cjatherton: argyllcms erikos: sugar-turtleart jcapik: maven-shared-jarsigner, maven-jarsigner-plugin jerboaa: felix-scr-maven-plugin jistone: llvm7.0 jkang: felix-scr-maven-plugin lef: hibernate marcindulak: exciting, htmlcleaner mizdebsk: maven-shared-jarsigner, jettison, jetty-artifact-remote-resources, jetty-test-policy, jetty-assembly-descriptors, maven-jarsigner-plugin odubaj: hibernate rhughes: argyllcms sdz: sugar-turtleart sergesanspaille: llvm7.0, clang7.0 tstellar: llvm7.0, clang7.0 -- The script creating this output is run
Re: g++ 10: static declared in extern "C" inline function
On Mon, 10 Feb 2020 at 06:45, Sam Varshavchik wrote:
>
> Iñaki Ucar writes:
>
> > On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik wrote:
> > >
> > > Iñaki Ucar writes:
> > >
> > > > Thoughts?
> > > >
> > > > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
> > >
> > > I managed to find the part of the C++ standard that specified the
> > > semantics
> > > of extern "C" linkage, it is [dcl.link]. The term used is "language
> > linkage".
> > >
> > > There is no such thing as an inline function in C. That code compiles C++
> > > code with C language linkage.
> > >
> > > Reading the C++ standard,, all that the standard seems to specify is
> > > language linkage of declarations. Quoting:
> > >
> > > # Every implementation shall provide for linkage to functions written in
> > the C
> > > # programming language, "C", and linkage to C ++ functions, "C++".
> > > #
> > > # [ Example:
> > > # complex sqrt(complex);
> > > # // C++ linkage by default
> > > # extern "C" {
> > > # double sqrt(double);
> > > # // C linkage
> > > # }
> > > # — end example ]
> > >
> > > The standard does not seem to specify the definitions of functions inside
> > > a language linkage specification. Either that is unspecified and therefore
> > > is a compiler extension; or it is clear that the only thing that belongs
> > > inside extern "C" is C code, and there's no such thing as inline functions
> > > in C, so declaring C++ code with C linkage would also be considered a
> > > compiler extension.
I missed that bit in your previous email: of course there are inline
functions in C since C99.
> > > This code compiles in gcc 9, but not in gcc 10. That's life, for compiler
> > > extensions.
> >
> > So, summing up, nothing wrong with that code according to the
> > standard. Therefore, since this is a regression that breaks previous
> > behaviour, I'd say this is a bug in gcc, right?
>
> No, exactly the opposite. As I wrote:
>
> > > Reading the C++ standard,, all that the standard seems to specify is
> > > language linkage of declarations.
>
> The code that fails to compile is not a declaration. It defines an inline
> C++ function. I find nothing in C++ standard that specifies function
> definitions inside linkage specifications.
>
> This is a declaration:
>
> void foo();
>
> This is a definition:
>
> void bar()
> {
> }
What are you talking about? The same chapter you referenced,
[dcl.link], talks about definitions. Of course if you declare
something that will be available from C, you need to define it at some
point. Whether it's defined there or just declared and defined later
doesn't matter. The linkage only refers to the visibility of the
symbol, but it doesn't change the fact that every declaraction needs a
definition somewhere, and that must be (in this case) valid C++ code,
because it will be compiled with a C++ compiler.
Iñaki
___
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: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 09, 2020 20:49:19 +0100, Jun Aruga wrote: > > netcdf-java[1] uses the Gradle build system, and is required to update > hdfview[2] to the latest version. Gradle, however, was retired[3] as > "out of date, broken, fails to build, basically unmaintainable". > > Checking the build.grade file (gradle recipe filei) of netcdf-java, is > it possible to build and run it with "javac" and "java" command > without "gradle"? > https://github.com/Unidata/netcdf-java/blob/master/build.gradle I'm sure it must be doable, but it brings us back to the same issue of packagers having to interpret Gradle build files to implement the build manually. It'll probably be easier to migrate them to Maven files if we do go down this road. -- 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: 13 packages still requiring Python 3.7 in Fedora 32
On 10. 02. 20 9:33, John M. Harris Jr wrote: One potential solution would be to keep Python 3.7 for now, instead of causing needless breakage. Could you please elaborate on how do we do that? Do you propose to revert python3 from 3.8 back to 3.7 and start bootstrapping all the Python packages back with 3.7, 2 weeks before the beta freeze? How would you deal with the number of packages that would fail to build with 3.7 for unrelated reasons? I suppose it would be way more over 13. Do you consider 13 broken packages from 3583 a needless breakage? Do you propose Fedora to stay on one Python version forever to avoid needless breakage? What happens when this Python version is no longer maintained upstream? I am sorry, none of this sounds like something we want, so what do you actually propose? -- 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
Fedora-Cloud-31-20200210.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
[rpms/perl-Scalar-List-Utils] PR #1: Spec file cleanups: Use make_build and make_install macros
adelton closed without merging a pull-request against the project: `perl-Scalar-List-Utils` that you are following. Closed pull-request: `` Spec file cleanups: Use make_build and make_install macros `` https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[rpms/perl-Scalar-List-Utils] PR #1: Spec file cleanups: Use make_build and make_install macros
adelton commented on the pull-request: `Spec file cleanups: Use make_build and make_install macros` that you are following: `` Thank you, merged as 1e6e78f8a4da0249afbf04a35db9ca0445b9b974 (with small typo fix). `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: %{make_install} and the Perl/Tips wiki
On Fri, Feb 07, 2020 at 11:57:57AM +0100, Petr Pisar wrote: > On Thu, Feb 06, 2020 at 09:08:58AM +0100, Jan Pazdziora wrote: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_parallel_make > > and > > https://fedoraproject.org/wiki/Perl/Tips#ExtUtils::MakeMaker [...] > > Would it make sense to start the section with the best-practice > > examples, and move the "historical" approach that is no longer > > promoted to separate list? > > That's a good idea. I added few examples there. Awesome, thank you. -- Jan Pazdziora Senior Principal Software Engineer, Security Engineering, Red Hat ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
HEADS UP: python-cffi 1.14.0 in rawhide, possibly Fedora 31
Hello. There is updated python-cffi 1.14.0 in rawhide, updated from 1.13.2. With a possible update in Fedora 31 from 1.12.3. https://cffi.readthedocs.io/en/latest/whatsnew.html There should be no backward incompatible changes apart from a new deprecation in 1.13.1. (If your package was not affected by this already in rawhide and your Fedora 31 version is the same, you shouldn't get affected by it.) It would be appreciated if you could please check if all your dependent packages build and work fine, and report back trough Bugzilla or here. Thanks Maintainers by package: freecell-solver shlomif freeipa abbra fcami ipa-maint jhrozek mkosek pvoborni rcritten simo twoerner libolm xvitaly ocrmypdf qulogic printrun churchyard python-argon2-cffi atim paulcarroty python-autobahn jujens python-bcryptpingou williamjmorenor python-cairocffi brouhaha fschwarz jdulaney python-cryptography ayrx bowlofeggs cheimes itamarjp jcline noodles npmccallum python-lmdb pspacek python-nnpy tdawson python-persistentjjames python-pillowmiminar smani python-pycares fantom python-pygit2pwalter python-pynaclignatenkobrain python-snappyjujens python-xcffibcicku jdulaney qtilecicku jdulaney rpy alexlan jamatos weasyprint brouhaha fschwarz Packages by maintainer: abbra freeipa alexlan rpy atimpython-argon2-cffi ayrxpython-cryptography bowlofeggs python-cryptography brouhahapython-cairocffi weasyprint cheimes python-cryptography churchyard printrun cicku python-xcffib qtile fantom python-pycares fcami freeipa fschwarzpython-cairocffi weasyprint ignatenkobrain python-pynacl ipa-maint freeipa itamarjppython-cryptography jamatos rpy jcline python-cryptography jdulaneypython-cairocffi python-xcffib qtile jhrozek freeipa jjames python-persistent jujens python-autobahn python-snappy miminar python-pillow mkosek freeipa noodles python-cryptography npmccallum python-cryptography paulcarroty python-argon2-cffi pingou python-bcrypt pspacek python-lmdb pvobornifreeipa pwalter python-pygit2 qulogic ocrmypdf rcrittenfreeipa shlomif freecell-solver simofreeipa smani python-pillow tdawson python-nnpy twoernerfreeipa williamjmorenor python-bcrypt xvitaly libolm -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
HEADS UP: python-cffi 1.14.0 in rawhide, possibly Fedora 31
Hello. There is updated python-cffi 1.14.0 in rawhide, updated from 1.13.2. With a possible update in Fedora 31 from 1.12.3. https://cffi.readthedocs.io/en/latest/whatsnew.html There should be no backward incompatible changes apart from a new deprecation in 1.13.1. (If your package was not affected by this already in rawhide and your Fedora 31 version is the same, you shouldn't get affected by it.) It would be appreciated if you could please check if all your dependent packages build and work fine, and report back trough Bugzilla or here. Thanks Maintainers by package: freecell-solver shlomif freeipa abbra fcami ipa-maint jhrozek mkosek pvoborni rcritten simo twoerner libolm xvitaly ocrmypdf qulogic printrun churchyard python-argon2-cffi atim paulcarroty python-autobahn jujens python-bcryptpingou williamjmorenor python-cairocffi brouhaha fschwarz jdulaney python-cryptography ayrx bowlofeggs cheimes itamarjp jcline noodles npmccallum python-lmdb pspacek python-nnpy tdawson python-persistentjjames python-pillowmiminar smani python-pycares fantom python-pygit2pwalter python-pynaclignatenkobrain python-snappyjujens python-xcffibcicku jdulaney qtilecicku jdulaney rpy alexlan jamatos weasyprint brouhaha fschwarz Packages by maintainer: abbra freeipa alexlan rpy atimpython-argon2-cffi ayrxpython-cryptography bowlofeggs python-cryptography brouhahapython-cairocffi weasyprint cheimes python-cryptography churchyard printrun cicku python-xcffib qtile fantom python-pycares fcami freeipa fschwarzpython-cairocffi weasyprint ignatenkobrain python-pynacl ipa-maint freeipa itamarjppython-cryptography jamatos rpy jcline python-cryptography jdulaneypython-cairocffi python-xcffib qtile jhrozek freeipa jjames python-persistent jujens python-autobahn python-snappy miminar python-pillow mkosek freeipa noodles python-cryptography npmccallum python-cryptography paulcarroty python-argon2-cffi pingou python-bcrypt pspacek python-lmdb pvobornifreeipa pwalter python-pygit2 qulogic ocrmypdf rcrittenfreeipa shlomif freecell-solver simofreeipa smani python-pillow tdawson python-nnpy twoernerfreeipa williamjmorenor python-bcrypt xvitaly libolm -- 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
[Bug 1800830] perl-PPIx-Regexp-0.069 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1800830 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-PPIx-Regexp-0.069-1.fc ||32 Resolution|--- |RAWHIDE Last Closed||2020-02-10 10:02:53 --- Comment #1 from Petr Pisar --- This release disabled PPIx::Regexp::StringTokenizer. Suitable for Rawhide only. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: swap-on-ZRAM by default
Hi, On 2/10/20 9:44 AM, John M. Harris Jr wrote: On Saturday, February 8, 2020 9:40:09 PM MST John Reiser wrote: John M. Harris Jr wrote: Using swap on zram disables the ability to hibernate, making it a non-starter for many users. If this is going to be thrown into anything, the user needs to be asked whether they want it or not in the installer, otherwise you're just taking away features. Why not create a utility program to convert dynamically between swap-on-zram and swap-on-disk? I personally believe swap-on-zram is a waste of RAM to begin with, Is this based on actual experience with it? Because I have actually been using it and the average compression ratio is about 1:3 so if you have 6G of RAM and say 2G ends up being used as zswap that gives you 4G RAM + 6G of _very_ fast swap, which works out much better then just 6G of RAM + slow swap. I've mostly been using this on machines with 1G / 2 G of RAM where using zswap is the difference between being able to run a modern browser with a few tabs, or not being able to run a modern browser at all. zswap really helps a lot, so you really should give it an actual serious honest test ride, rather then "believing" something about it. Regards, Hans ___ 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
[Bug 1800830] perl-PPIx-Regexp-0.069 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1800830 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1801108] New: Upgrade perl-XML-Hash-LX to 0.07
https://bugzilla.redhat.com/show_bug.cgi?id=1801108 Bug ID: 1801108 Summary: Upgrade perl-XML-Hash-LX to 0.07 Product: Fedora Version: rawhide Status: NEW Component: perl-XML-Hash-LX Assignee: ppi...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest Fedora delivers 0.60.300 version. Upstream released 0.07. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1800466] Upgrade perl-CGI-Simple to 1.24
https://bugzilla.redhat.com/show_bug.cgi?id=1800466 Jitka Plesnikova changed: What|Removed |Added Summary|Upgrade perl-CGI-Simple to |Upgrade perl-CGI-Simple to |1.23|1.24 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1796925] perl-DBD-ODBC-1.61 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1796925 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Resolution|--- |RAWHIDE Assignee|holca...@gmail.com |jples...@redhat.com Doc Type|--- |If docs needed, set a value Last Closed||2020-02-10 09:17:40 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: [Retired] gstreamer & gstreamer-plugins-base
On 10.02.2020 09:43, John M. Harris Jr wrote: > As long as it builds and functions, why remove it? Because it has lots of critical vulnerabilities and endangers end-user devices. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Retired] gstreamer & gstreamer-plugins-base
On Mon, 10 Feb 2020, 08:44 John M. Harris Jr, wrote: > On Sunday, February 9, 2020 3:54:51 PM MST Neal Gompa wrote: > > On Sun, Feb 9, 2020 at 5:36 PM John M. Harris Jr > > wrote: > > > > > > > > > On Friday, January 31, 2020 7:58:55 AM MST Peter Robinson wrote: > > > > > > > Feankly if a proprietary piece of software hasn't migrated in 8+ > years > > > > I > > > > would be looking for a replacement. > > > > > > > > > > > > Proprietary software works at the speed of eventually. This is why RHEL > > > maintains compat libraries going back a ridiculous amount of time, and > > > why > > > RHEL 5, for example, is still used today. > > > > > > > > > > > > At some point, someone has to push to eject button. Speaking from > > experience, it's rare that ISVs are willing to be proactive and move > > forward as the community does. The difference between FOSS ISVs and > > proprietary software ISVs is that the community cannot do anything to > > help fix software for the latter. They only move forward when forced to. > > > > I'm sorry, but it simply does not make sense to keep gstreamer0.10 in > > Fedora anymore. I don't say that lightly: the first package I ever > > contributed to Fedora was a pygtk2 application using gstreamer0.10 > > called oggconvert. But it is dead this days, and I retired it for > > Fedora 31. Nobody is caring for these things, and stuff like this is > > usually a source of major security issues. > > > > Even today, those people using RHEL 5 are only *now* moving to RHEL 7 > > because it was EOLed three years ago. Folks depending on RHEL 6 who > > are slow to move are starting their plans to move to RHEL 8. It is > > what it is. But Fedora is not RHEL. Fedora is supposed to be the place > > where everything happens first. And if we want RHEL releases without > > old, unmaintained stuff, we have to chuck it in Fedora first. > > I don't know about you, but I'd rather the software keeps working, rather > than > ceasing to function because a library it depends on is no longer > available. As > long as it builds and functions, why remove it? > Because it implies it's supported for things like security updates and related things where in reality the gst 0.10 series hasn't been for the best part of a decade and when it comes to media and dealing with internet streams/media that is a real life security problem. The fact it builds is but one part of the overall problem. -- > John M. Harris, Jr. > Splentity > > ___ > 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: can't build speed-dreams for rawhide
it was my mistake, I took the wrong patch that still had qhull as a requirement. Regards Martin ___ 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: Copr Build System - review of 2019 and vote for features in 2020
On Thursday, January 30, 2020 6:31:37 PM MST Kevin Fenzi wrote: > On Thu, Jan 23, 2020 at 11:07:21AM -0700, John M. Harris Jr wrote: > > EOL is not, literally, EOL. EOL just means the complete end of support, in > > commercial products. Still doesn't mean systems with that version > > installed > > cease to exist. In Fedora, it simply means that it gets little attention, > > but contributors are free to do what they like, for the most part. > > Systems with that version continue to live. > > Sure, but it also means there's no way to push updates for it, bugs > aren't allowed for that version and support channels are likely to just > tell you to upgrade if theres a difficult problem. > > See https://fedoraproject.org/wiki/Fedora-EOL-Support > > > Pretty soon, in fact as of the next release, we'll have users who are > > actually stuck on an EOL release. > > There will always be such users for a variety of reasons. > > kevin So long as people are willing to maintain it, why restrict peoples' ability to work on something, especially while users are stuck on that version, or forced to move elsewhere if they cannot get a fix and cannot upgrade? -- John M. Harris, Jr. Splentity ___ 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: swap-on-ZRAM by default
On Saturday, February 8, 2020 9:40:09 PM MST John Reiser wrote: > John M. Harris Jr wrote: > > > > Using swap on zram disables the ability to hibernate, making it a > > non-starter for many users. If this is going to be thrown into anything, > > the user needs to be asked whether they want it or not in the installer, > > otherwise you're just taking away features. > > > Why not create a utility program to convert dynamically between > swap-on-zram and swap-on-disk? I personally believe swap-on-zram is a waste of RAM to begin with, so I still believe it's important that it should be an install-time option, even if there is such a program that simply runs `swapon` or `swapoff` and the relevant commands to destroy the zram device. -- John M. Harris, Jr. Splentity ___ 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
