[Bug 1758695] Plans for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1758695 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- perl-Time-ParseDate-2015.103-13.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-43c92c5ec0 -- 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 1758050] Upgrade perl-Test-TCP to 2.21
https://bugzilla.redhat.com/show_bug.cgi?id=1758050 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- perl-Test-TCP-2.21-1.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-65894aa457 -- 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 1758574] perl-ExtUtils-CChecker for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1758574 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-ExtUtils-CChecker-0.10-13.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7111331884 -- 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
[389-devel] 389 DS nightly 2019-10-06 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/10/06/report-389-ds-base-1.4.2.2-20191005gite049236.fc30.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
Failing f31 spins/labs/images
Hey everyone, it's time for another round of 'please fix your failing compose images'. This time it's important to land fixes before tuesday, as thats when final freeze for f31 starts. It may be possible to fix things after that, but it will require freeze breaks and overhead. Do it now and you will save everyone time later. ;) Python-Classroom: `` [pungi.global.log](https://kojipkgs.fedoraproject.org/compose/branched/Fedora-31-20191005.n.0/compose/../logs/global/pungi.global.log) - [38066743](https://koji.fedoraproject.org/koji/taskinfo?taskID=38066743) ``` [LIVE_IMAGES ] [ERROR ] [FAIL] Live (variant Labs, arch armhfp, subvariant Python_Classroom) failed, but going on anyway. [LIVE_IMAGES ] [ERROR ] LiveImage task failed: 38066743. See /mnt/koji/compose/branched/Fedora-31-20191005.n.0/logs/armhfp/liveimage-Fedora-Python-Classroom-armhfp-31-20191005.n.0.armhfp.log for more details. ``` Tons of broken deps. Might be related to 58502625d2f2c313390cad354a096ce5b625f049 where python38 and python36 were excluded? Not sure. Design-suite: - [38066749](https://koji.fedoraproject.org/koji/taskinfo?taskID=38066749) ``` [LIVE_MEDIA ] [ERROR ] [FAIL] Live media (variant Labs, arch *, subvariant Design_suite) failed, but going on anyway. [LIVE_MEDIA ] [ERROR ] Live media task failed: 38066749. See /mnt/koji/compose/branched/Fedora-31-20191005.n.0/logs/x86_64/livemedia-Labs-Design_suite.x86_64.log for more details. ``` Sparkleshare broken: DEBUG util.py:593: 2019-10-05 10:03:12,285: - nothing provides mono(notify-sharp) = 3.0.0.0 needed by sparkleshare-3.28-1.fc31.x86_64 DEBUG util.py:593: 2019-10-05 10:03:12,286: - nothing provides mono(webkit2-sharp) = 2.10.9.0 needed by sparkleshare-3.28-1.fc31.x86_64. Needs to be fixed or dropped. Scientific_KDE: - [38066752](https://koji.fedoraproject.org/koji/taskinfo?taskID=38066752) ``` [LIVE_MEDIA ] [ERROR ] [FAIL] Live media (variant Labs, arch *, subvariant Scientific_KDE) failed, but going on anyway. [LIVE_MEDIA ] [ERROR ] Live media task failed: 38066752. See /mnt/koji/compose/branched/Fedora-31-20191005.n.0/logs/x86_64/livemedia-Labs-Scientific_KDE.x86_64.log for more details. ``` Bunch of broken deps. May be related to the eclipse modular issues. Games: - [38066755](https://koji.fedoraproject.org/koji/taskinfo?taskID=38066755) ``` [LIVE_MEDIA ] [ERROR ] [FAIL] Live media (variant Labs, arch *, subvariant Games) failed, but going on anyway. [LIVE_MEDIA ] [ERROR ] Live media task failed: 38066755. See /mnt/koji/compose/branched/Fedora-31-20191005.n.0/logs/x86_64/livemedia-Labs-Games.x86_64.log for more details. ``` bunch of missing packages. Need to be dropped? Should be a easy PR for someone. :) DEBUG util.py:593: 2019-10-05 10:05:47,724: missing packages: btanks, childsplay, escape, gcompris, lmarbles, londonlaw. Jame_KDE: - [38066762](https://koji.fedoraproject.org/koji/taskinfo?taskID=38066762) ``` [LIVE_MEDIA ] [ERROR ] [FAIL] Live media (variant Labs, arch *, subvariant Jam_KDE) failed, but going on anyway. [LIVE_MEDIA ] [ERROR ] Live media task failed: 38066762. See /mnt/koji/compose/branched/Fedora-31-20191005.n.0/logs/x86_64/livemedia-Labs-Jam_KDE.x86_64.log for more details. ``` Missing packages: DEBUG util.py:593: 2019-10-05 10:14:25,511: missing packages: aj-snapshot, jack-rack, lv2-avw-plugins, lv2-fomp-plugins, lv2-triceratops, non-daw, non-mixer, non-sequencer, non-session-manager, seq24. Again, should be a easy fix. Container_Base: - [38066754](https://koji.fedoraproject.org/koji/taskinfo?taskID=38066754) ``` [ERROR ] [FAIL] Image build (variant Container, arch armhfp, subvariant Container_Base) failed, but going on anyway. [IMAGE_BUILD ] [INFO] [DONE ] Creating image (formats: docker, arches: aarch64-armhfp-ppc64le-s390x-x86_64, variant: Container, subvariant: Container_Base) (task id: 38066754) This is the armv7 container base. We really need to figure out why it's failing. I'm likely to debug this next week as I am trying to build out armv7 vm's on our new aarch64 hardware (the setup of which is very similar to this job). Container_minimal_base: ``` - [38066758](https://koji.fedoraproject.org/koji/taskinfo?taskID=38066758) ``` [ERROR ] [FAIL] Image build (variant Container, arch armhfp, subvariant Container_Minimal_Base) failed, but going on anyway. [IMAGE_BUILD ] [INFO] [DONE ] Creating image (formats: docker, arches: aarch64-armhfp-ppc64le-s390x-x86_64, variant: Container, subvariant: Container_Minimal_Base) (task id: 38066758) ``` Same thing as above. Scientific: (vagrant) - [38066764](https://koji.fedoraproject.org/koji/taskinfo?taskID=38066764) ``` [IMAGE_BUILD ] [ERROR ] [FAIL] Image build (variant Labs, arch *, subvariant Scientific) failed, but going on anyway. [IMAGE_BUILD ] [ERROR ] ImageBuild task failed: 38066764. See /mnt/koji/compose/branched/Fedora-31-20191005.n.0/logs
Re: New updates straight to obsolete after Epoch bump?!?
On Sat, Oct 05, 2019 at 01:35:03PM -0500, Richard Shaw wrote: > On Sat, Oct 5, 2019 at 1:17 PM Kevin Fenzi wrote: > > > On Thu, Oct 03, 2019 at 06:32:13PM -0500, Richard Shaw wrote: > > > Anyone have any ideas? I tried re-submitting them but they were obsoleted > > > by bodhi again. > > > > It looks like the newer pyside is now in > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a4f82aa58 > > perhaps try and get the author of that update to edit it and remove the > > new one and add the one you want? > > > > Nothing needs Pyside2 yet, I wonder if I should just let that one go to > stable and then try to push mine again? I suppose thats an option... might cause some churn if people install it and then have to downgrade, but if nothing depends on it... 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
Vim :Gbrowse support for pagure
Hello, I don't know how many of you are Vim users and what fraction of those use plugins. Anyway, there is a great, well-known plugin called vim-fugitive (by notorious Tim Pope), that provides a lot of cool features. My favorite one is probably `:Gbrowse` command, which opens the current file, line or visual selection in your web browser. Up until now, there was support for GitHub, GitLab, Bitbucket, and Gitee. The _problem_ is, that a lot of us moved to Pagure ... ... so I wrote a plugin enhancing the :Gbrowse functionality with Pagure support. Give it a try. If you find it (not) helpful, let me know! Code: https://github.com/FrostyX/vim-fugitive-pagure Blog post: http://frostyx.cz/posts/vim-gbrowse-support-for-pagure Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: epel8-playground and centos-stream?
On Sat, Oct 05, 2019 at 11:58:31AM -0700, Kevin Fenzi wrote: > So, question: when say RHEL8.1beta comes out. Is the Centos 8 stream > updating that? (ie, has all beta changes and continues from there?). > I think we need to be very careful with beta's. If we can get security > updates via centos 8 stream then great, but if not, that makes a known > pool of insecure software. :( As I understand it, CentOS Stream will get security updates (because no one wants a big pool of insecure software, and it's not good for users), but that the significant, expensive work that the Red Hat security team and Red Hat developers do to develop fixes should be available to paying customers first. That seems reasonable to me. Also, of course, many such fixes have embargo dates and _can't_ be made public early. The mechanisms for doing this aren't actually built yet. -- Matthew Miller Fedora Project Leader ___ 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
[Bug 1758050] Upgrade perl-Test-TCP to 2.21
https://bugzilla.redhat.com/show_bug.cgi?id=1758050 Fedora Update System changed: What|Removed |Added Status|ON_QA |MODIFIED --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2019-65894aa457 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-65894aa457 -- 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
[EPEL-devel] Re: epel8-playground and centos-stream?
On Wed, Sep 25, 2019 at 11:40:19AM -0400, Stephen Gallagher wrote: > On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa wrote: > > > > On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi wrote: > > > > > > After the announcement today of centos-stream, I wonder if it would make > > > sense to move epel8-playground to build against that instead of the > > > latest rhel8 release? > > > > > > It would make playground less usefull for testing new radical changes > > > against the current stable point release, but on the other hand, the > > > centos stream will become the next stable point release, so it would > > > allow people to test against that and get changes ready that they could > > > then push in after the next stable point release landed? > > > > > > What do folks think? Bad idea, good idea? > > I think that makes good sense; it will provide a guarantee of early > notice when an upcoming RHEL release might introduce a problematic > change (intentionally or otherwise) and provides Red Hat with feedback > and an opportunity to fix it before RHEL releases. It will also make > our minor release merge windows easier, since we should not get any > major surprises hitting only at Beta or GA. As mentioned downstream, if we want to know if epel builds ok/breaks by changes in the stream we might instead setup a koschei instance pointing to centos stream? Since as Tony indicated we don't mass rebuild or know when something would break there. > > If we decide *not* to do this, I think we need to at least have a > policy of updating the buildroot for EPEL8-playground to include the > RHEL minor release beta tree as a lesser version of the same process > as above. So, question: when say RHEL8.1beta comes out. Is the Centos 8 stream updating that? (ie, has all beta changes and continues from there?). I think we need to be very careful with beta's. If we can get security updates via centos 8 stream then great, but if not, that makes a known pool of insecure software. :( kevin signature.asc Description: PGP signature ___ 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
[Bug 1758695] Plans for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1758695 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-EPEL-2019-43c92c5ec0 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-43c92c5ec0 -- 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: New updates straight to obsolete after Epoch bump?!?
On Sat, Oct 5, 2019 at 1:17 PM Kevin Fenzi wrote: > On Thu, Oct 03, 2019 at 06:32:13PM -0500, Richard Shaw wrote: > > Anyone have any ideas? I tried re-submitting them but they were obsoleted > > by bodhi again. > > It looks like the newer pyside is now in > https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a4f82aa58 > perhaps try and get the author of that update to edit it and remove the > new one and add the one you want? > Nothing needs Pyside2 yet, I wonder if I should just let that one go to stable and then try to push mine again? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Defining the future of the packager workflow in Fedora
On Sat, Oct 05, 2019 at 02:35:59AM +0200, Kevin Kofler wrote: > Vít Ondruch wrote: > > It depends how you maintain your packages. My guess is (and I am sorry > > if I am mistaken) that you don't follow the > > > > https://fedoraproject.org/wiki/Updates_Policy#Philosophy > > > > If you followed this policy, then you would touch the stable branches > > just rarely and therefore keeping them fast forwardable would be just > > waste of time. > > It depends on what, how, and when upstream releases. > > If we have different upstream releases in different Fedora releases, then of > course those releases should have different specfiles. But if we are > shipping the same upstream release, I don't see why I should clone the > specfile n times. In order to reduce complexity and allow for easier automated changes? You could make a spec file for any package that "works" on every version/release of every rpm based distro. It would be full of if this then that and duplicated sections with subtle differences, it could even do all versions. Right now what we have is maintainer(s) preference on how complex they want their spec files to get before they just seperate our another copy for the complex case. I think thats bad for a number of reasons... ...snip section about why you would want to ship the same upstream release in multiple fedora releases... yes, thats all fine, but in a lot of cases you run into issues doing this, which means you have to drive up the complexity of your one spec file or just ship different ones per fedora release. I think this increasing complexity is bad for the project, and often bad for maintainers as well. On the one hand you only have to edit one spec file, but you have to figure out the logic and have no way to know if it's right without rebuilding it in all the places you want to use it and carefully checking each build. On the other you have to edit more spec files and you have to swap in context as to why say fedora 29 is doing X and master is doing Y, but it's a lot more clear what it's doing and why. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New updates straight to obsolete after Epoch bump?!?
On Thu, Oct 03, 2019 at 06:32:13PM -0500, Richard Shaw wrote: > Anyone have any ideas? I tried re-submitting them but they were obsoleted > by bodhi again. It looks like the newer pyside is now in https://bodhi.fedoraproject.org/updates/FEDORA-2019-2a4f82aa58 perhaps try and get the author of that update to edit it and remove the new one and add the one you want? 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
Fedora rawhide compose report: 20191005.n.0 changes
OLD: Fedora-Rawhide-20191004.n.1 NEW: Fedora-Rawhide-20191005.n.0 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 1 Dropped packages:0 Upgraded packages: 99 Downgraded packages: 0 Size of added packages: 31.64 KiB Size of dropped packages:0 B Size of upgraded packages: 2.54 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -60.68 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-armhfp-Rawhide-20191005.n.0-sda.raw.xz = DROPPED IMAGES = Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20191004.n.1-sda.raw.xz Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20191004.n.1-sda.raw.xz = ADDED PACKAGES = Package: mdevctl-0.50-1.fc32 Summary: Mediated device management and persistence utility RPMs:mdevctl Size:31.64 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: FlightGear-2019.1.1-3.fc32 Old package: FlightGear-2019.1.1-2.fc32 Summary: The FlightGear Flight Simulator RPMs: FlightGear Size: 33.87 MiB Size change: -1.57 KiB Changelog: * Tue Oct 01 2019 Gwyn Ciesla - 2019.1.1-3 - Rebuilt for new freeglut Package: FlightGear-Atlas-0.5.0-0.53.cvs20141002.fc32 Old package: FlightGear-Atlas-0.5.0-0.52.cvs20141002.fc31 Summary: Flightgear map tools RPMs: FlightGear-Atlas Size: 3.62 MiB Size change: -3.12 KiB Changelog: * Mon Sep 23 2019 Gwyn Ciesla - 0.5.0-0.53.cvs20141002 - Rebuilt for new freeglut Package: Io-language-2015-0.e64ff9.fc32.19 Old package: Io-language-2015-0.e64ff9.fc32.18 Summary: Io is a small, prototype-based programming language RPMs: Io-language Io-language-devel Io-language-extras Io-language-graphics-and-sound Io-language-mysql Io-language-postgresql Size: 6.34 MiB Size change: -4.05 KiB Changelog: * Tue Sep 17 2019 Gwyn Ciesla - 2015-0.e64ff9.19 - Rebuilt for new freeglut Package: OpenMesh-6.3-7.fc32 Old package: OpenMesh-6.3-6.fc31 Summary: A generic and efficient polygon mesh data structure RPMs: OpenMesh OpenMesh-devel OpenMesh-doc OpenMesh-tools Size: 21.01 MiB Size change: 26.01 KiB Changelog: * Tue Sep 17 2019 Gwyn Ciesla - 6.3-7 - Rebuilt for new freeglut Package: OpenSceneGraph-3.4.1-12.fc32 Old package: OpenSceneGraph-3.4.1-11.fc31 Summary: High performance real-time graphics toolkit RPMs: OpenSceneGraph OpenSceneGraph-Collada OpenSceneGraph-OpenEXR OpenSceneGraph-devel OpenSceneGraph-examples OpenSceneGraph-examples-SDL OpenSceneGraph-examples-fltk OpenSceneGraph-examples-gtk OpenSceneGraph-examples-qt OpenSceneGraph-gdal OpenSceneGraph-gstreamer OpenSceneGraph-libs OpenSceneGraph-qt OpenSceneGraph-qt-devel OpenThreads OpenThreads-devel Size: 65.92 MiB Size change: 119.57 KiB Changelog: * Tue Sep 17 2019 Gwyn Ciesla - 3.4.1-12 - Rebuilt for new freeglut Package: anaconda-32.7-1.fc32 Old package: anaconda-32.6-1.fc32 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 18.52 MiB Size change: 23.88 KiB Changelog: * Fri Oct 04 2019 Martin Kolman - 32.7-1 - network: split configure hostname task out of network installation task (#1757960) (rvykydal) - Switch to pypi pylint from RPM (jkonecny) - Allow to handle the return value of subprocess.run (vponcova) - Remove the unexpected keyword argument 'env' (vponcova) - Remove the assignment of the same variable to itself (vponcova) - Remove unused false positives (vponcova) - Improve updates repo configuration in GUI (#1670471) (mkolman) - Don't touch storage until it is ready (vponcova) - Run the manual partitioning task for the given requests (vponcova) - Set the locale for unit tests (vponcova) - Deprecate the current kickstart support for addons (vponcova) - Add kickstart support for the Baz module (vponcova) - Support the %addon sections in the kickstart specification (vponcova) - Handle the bootloader reset in the partitioning task (vponcova) - Fix the DBus patching functions (vponcova) - Patch DBus proxies in GUI and TUI simple import tests (vponcova) - Add DBus method for validation of selected disks (vponcova) - Enable faulthandler in DBus modules (vponcova) - Reset the storage and the playground of partitioning modules (vponcova) - Add support for getting an object path of a DBus proxy (vponcova) - Remove pointless '../../' to clean up NFS mounts (riehecky) Package: ark-19.08.1-1.fc32 Old package: ark-19.04.3-2.fc31 Summary: Archive manager RPMs: ark ark-libs Size: 7.43 MiB Size change: -3.55 KiB Changelog: * Fri Oct 04
Fedora-Rawhide-20191005.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 45 required tests failed, 6 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 8/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20191004.n.1): ID: 463695 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/463695 ID: 463708 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/463708 ID: 463715 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/463715 ID: 463731 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/463731 ID: 463736 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/463736 ID: 463742 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/463742 ID: 463797 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/463797 ID: 463798 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/463798 ID: 463812 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/463812 Soft failed openQA tests: 2/153 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20191004.n.1): ID: 463800 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/463800 ID: 463804 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/463804 Passed openQA tests: 131/153 (x86_64) New passes (same test not passed in Fedora-Rawhide-20191004.n.1): ID: 463663 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/463663 ID: 463664 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/463664 ID: 463665 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/463665 ID: 463666 Test: x86_64 Server-dvd-iso release_identification URL: https://openqa.fedoraproject.org/tests/463666 ID: 463667 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/463667 ID: 463668 Test: x86_64 Server-dvd-iso base_selinux URL: https://openqa.fedoraproject.org/tests/463668 ID: 463669 Test: x86_64 Server-dvd-iso base_services_start URL: https://openqa.fedoraproject.org/tests/463669 ID: 463670 Test: x86_64 Server-dvd-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/463670 ID: 463671 Test: x86_64 Server-dvd-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/463671 ID: 463672 Test: x86_64 Server-dvd-iso base_system_logging URL: https://openqa.fedoraproject.org/tests/463672 ID: 463673 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/463673 ID: 463674 Test: x86_64 Server-dvd-iso mediakit_fileconflicts URL: https://openqa.fedoraproject.org/tests/463674 ID: 463675 Test: x86_64 Server-dvd-iso mediakit_repoclosure URL: https://openqa.fedoraproject.org/tests/463675 ID: 463676 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/463676 ID: 463677 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/463677 ID: 463678 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/463678 ID: 463679 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/463679 ID: 463680 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/463680 ID: 463681 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/463681 ID: 463682 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/463682 ID: 463683 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/463683 ID: 463684 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/463684 ID: 463685 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/463685 ID: 463686 Test: x86_64 Server-dvd-iso realmd_join_sssd URL:
[EPEL-devel] Re: FreeRDP version updates.
Sounds like an amazing solution to me, I'll follow up on the link you've sent me along with the kodi link Stephen J Smoogen kindly offered me in order to reach a viable future solution. Thanks very much for getting back to me so soon and at the weekend on this matter. During the process I'm going to attempt to downgrade the FreeRDP-2.? version that's been installed to FreeRDP-version 1.? So that I may carry on with the APACHE guacamole developing I've been committed to for the last while, while they themselves also work towards supporting FreeRDP-2.x.x. I think it's just because they dont have developers around in the community whom have enough spare time to commit towards this support rollout. Kind regards, Darren Wise On 5 October 2019 16:27:28 BST, Matthew Miller wrote: >On Sat, Oct 05, 2019 at 11:22:59AM +0100, Darren Wise wrote: >> I also noticed that multiple versions are not maintained, could I >please >> be pointed to somewhere I could get a complete mirror of the EPEL >> repository and I'd be happy to maintain myself online? -Maybe I could >> start an repository online funded by myself which maintains multiple >> versions? > >So, we're not quite ready for this yet in EPEL, but allowing multiple >versions of packages to be maintained within the same, official >repository >is what the Modularity feature in Fedora and now RHEL 8 is for. Would >you be >interested in maintaining the versions you need as part of that? > >In the meantime, let me direct you to Copr, our system for building and >offering package repositories with a very low barrier to entry. Check >it out >at https://copr.fedorainfracloud.org/. This would be a great place to >start, >and then once we have modular EPEL up and running you could migrate >packages >to that. > >-- >Matthew Miller > >Fedora Project Leader >___ >epel-devel mailing list -- epel-de...@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-de...@lists.fedoraproject.org ___ epel-devel mailing list -- epel-de...@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-de...@lists.fedoraproject.org
[EPEL-devel] Re: FreeRDP version updates.
Heya, Thanks very much for getting back to me with my query, I've not dealt much with package management in this manner prior, however it's because I've never ran in to an issue like this myself in the past either just being a user of CentOS and updating. So I do apologise for this, but everything in the past has worked flawlessly and I've never needed to bother, if you understand me correctly.. "Dont fix it, if it ain't broken" metaphorically speaking.. Did you have packages which were updated and you were not aware it would happen? -Yes kind of, I knew they would be updated, but I did not realise they would cause so much further issues. Did you have packages which were not updated but you need them to be? -No. Did you have packages which installed which are broken? -No -However this issue is quite a spread one, APACHE Guacamole does require the freeRDP-1x versions in order to enable the utilisation of RDP connections, so APACHE guacamole needs an update too because FreeRDP version 2x has had such a change around they are still catching up developing ways and means of utilizing version 2x of FreeRDP. For this reason, I never even wanted to update to CentOS8 yet, but over the last month after doing an recompile and test VM install of Apache guacamole and then 'yum update' that rather then the FreeRDP 1x versions being used 2x has been placed within the packages which leaves me without the use of RDP. VNC, SSH connections are fine within APACHE guacamole. I traced it back to noticing that version 2 is now being used, so resorted to using my initial .iso as my yum package repository but am being left without freerdp-plugins-1.0.2. Because it's not listed within the install .iso repo (only freerdp, -devel, -libs) These are the updated versions being used after an yim update is initiated, which I assume would happen but was not prepared for the following issues rising from, doing said update. freerdp-2.0.0-1.rc4.el7.x86_64.rpm2019-08-22 21:2497K freerdp-devel-2.0.0-1.rc4.el7.i686.rpm2019-08-22 21:47125K freerdp-devel-2.0.0-1.rc4.el7.x86_64.rpm2019-08-22 21:24125K freerdp-libs-2.0.0-1.rc4.el7.i686.rpm2019-08-22 21:47735K freerdp-libs-2.0.0-1.rc4.el7.x86_64.rpm Would it be feasible to place within the EPEL7 repository the: FreeRDP-1.0.2.rc4.el7.i686.rpm FreeRDP-1.0.2.rc4.el7.x86_64.rpm, FreeRDP-devel-1.0.2.rc4.el7.i686.rpm FreeRDP-devel-1.0.2.rc4.el7.x86_64.rpm FreeRDP-libs-1.0.2.rc4.el7.i686.rpm FreeRDP-libs-1.0.2.rc4.el7.x86_64.rpm FreeRDP-plugins-1.0.2.rc4.el7.i686.rpm FreeRDP-plugins-1.0.2.rc4.el7.x86_64.rpm And then rename them too: FreeRDP1-1.0.2.rc4.el7.i686.rpm FreeRDP1-1.0.2.rc4.el7.x86_64.rpm, FreeRDP1-devel-1.0.2.rc4.el7.i686.rpm FreeRDP1-devel-1.0.2.rc4.el7.x86_64.rpm FreeRDP1-libs-1.0.2.rc4.el7.i686.rpm FreeRDP1-libs-1.0.2.rc4.el7.x86_64.rpm FreeRDP1-plugins-1.0.2.rc4.el7.x86_64.rpm FreeRDP1-plugins-1.0.2.rc4.el7.x86_64.rpm Which hopefully will allow future choice and further usability, afterall EPEL stands for Extra Packages for Enterprise Linux, I'd be happy to maintain them to the best if my ability in order to contribute towards the community and I'm sure it would assist many other facing my current issue which they have yet to run in to possibly. I've also noticed that the FreeRDP packages themselves are not directly installed by the EPEL, infact they reside on the .iso issued by the CentOS commumity and I should have spoken to them first rather then EPEL community directly, it was an base assumption they came from you guys after my initial yum update from a bare basic minimal install after inserting EPEL into my repo list. -Can the FreeRDP version 1x rpm's listed above be placed within the EPEL repo and rather then just be called FreeRDP > FreeRDP1- to represent an older version that user may call upon if needed. I'm just trying now to meet a global solution that's viable for people to utilise without forking, or creating further issues. Kind regards, Darren Wise On 5 October 2019 16:11:28 BST, Stephen John Smoogen wrote: >On Sat, 5 Oct 2019 at 06:23, Darren Wise wrote: >> >> Hey folks, >> >> Whom could I speak to about an EPEL package version update regarding >FreeRDP (freerdp-1.0.2-15.el7.x86_64, freerdp-libs-1.0.2-15.el7.x86_64, >freerdp-devel-1.0.2-15.el7.x86_64, freerdp-plugins-1.0.2-15.el7.x86_64) >verses the FreeRDP version 2.0 variants. >> >> The reason I asking is because I was relying on this version >currently within CentOS7 EPEL repository in order to develop for APACHE >Guacamole, however FreeRDP2.0 is not noticed when installed, the EPEL >update occurred (must have been) around the middle of September? 13th >and after? >> >> I also noticed that multiple versions are not maintained, could I >please be pointed to somewhere I could get a complete mirror of the >EPEL repository and I'd be happy to maintain myself online? >> -Maybe I could start an repository online funded by myself which >maintains multiple versions? >> > >Sorry
Re: Defining the future of the packager workflow in Fedora
On Wed, Oct 2, 2019 at 1:18 PM Ben Rosser wrote: > > 1. Creating new packages has become (more of) a pain since the > retirement of pkgdb2. I know I keep complaining about needing to > manually fetch Pagure API keys, but it is actually extremely annoying > when I go to request a repo and realize I need to first request a new > API key before doing anything else. The problem isn't the workflow, > per se, but the infrastructure: reviews could really use a better > platform than bugzilla. If reviews were more integrated into the > tooling, automatic checks like fedora-review could maybe be ran > automatically. Maybe approving a new package could even automatically > create the repository, without the requestor having to do anything! > This is a big one for me and I think part of the problem is we have both src.fedoraproject.org (a pagure instance) and pagure.io, which also is specifically for fedora but not in the fedoraproject.org domain. Then I get emails telling me my API key is about to expire and there's no links i the notification and I'm not entirely sure which pagure instance it is. THEN once I create new keys, because it's often enough to be annoying but not often enough to remember, I don't know which file to put it in... .config/fedrepo_req/config.ini ? or .config/rpkg/fedpkg.conf ? And google was almost useless this last time, "man fedpkg" was no help either I had to run: $ fedpkg request-repo --help To get the answer... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Defining the future of the packager workflow in Fedora
Miro Hrončok wrote:
> Your example is not valid. This is not a mass change, this was an
> individual change presented to the package maintainers via a PR that was
> not merged by me:
>
> https://src.fedoraproject.org/rpms/qt5-qtwebengine/pull-request/3
>
> Had there been a "please, make it build on F29" comment, I would have
> adapted it.
Well, your pull request did not state anywhere that it introduces a
construct that only works on F30 and newer, so I don't think it is fair to
shift the blame to the person who approved it (Rex Dieter). Your description
only stated "make it work both before and after python2 retirement", which
sounds as if it were fully backwards compatible.
It should be up to the person making this type of changes to test it on all
supported releases. Sure, this makes it harder to make packaging changes
across many packages, but IMHO, that is actually a beneficial side effect.
The goal should really be to not require this kind of changes at all,
because it also means that third-party packages have to adjust to them.
Instead, the packaging should remain backwards-compatible.
And in this case, I wonder whether the conditional is even needed or whether
we could just use the F29 version everywhere. As long as python27 Provides:
python2 (and it should!), I don't see why BuildRequires: python2 would not
be good enough and a file BuildRequires is needed. And python2-rpm-macros
are needed as BuildRequires because the specfile also uses %{__python2} in
the snippets. (Previously, the package had BuildRequires: python2-devel,
which drags in both python2 and python2-rpm-macros.) Something changed in
F30 to make python2-rpm-macros dragged in by default, this was not the case
in F29.
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
Re: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)
On Fri, 4 Oct 2019 at 20:10, Kevin Kofler wrote: > > Stephen John Smoogen wrote: > > What do you mean by breaking breaking because you use that term like a > > sledge hammer for anything from a 'pixel off' bug to 'too old software > > is in repos', 'too young software is in repos' , 'software is not in > > repos' to 'can't boot'. After a while, I assumed the only way I can't > > break a system is to never unbox it.. but I expect there is probably > > some way that is also a broken system. > > In this context, it is fairly clear what I meant: any current version of > Fedora (in around a year, this will mean any version still supported with > security updates at that point) will not run on those systems at all. It > will not even boot. > Actually it wasn't clear to me, so thank you for the clarification. Does it mean by this definition that Fedora is currently broken for ppc32, ia64, alpha and sparc because it no longer provides builds for them? Are what you wanting is that Fedora is more like Debian where we are building things for all platforms ever? -- 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
[EPEL-devel] Re: FreeRDP version updates.
On Sat, Oct 05, 2019 at 11:22:59AM +0100, Darren Wise wrote: > I also noticed that multiple versions are not maintained, could I please > be pointed to somewhere I could get a complete mirror of the EPEL > repository and I'd be happy to maintain myself online? -Maybe I could > start an repository online funded by myself which maintains multiple > versions? So, we're not quite ready for this yet in EPEL, but allowing multiple versions of packages to be maintained within the same, official repository is what the Modularity feature in Fedora and now RHEL 8 is for. Would you be interested in maintaining the versions you need as part of that? In the meantime, let me direct you to Copr, our system for building and offering package repositories with a very low barrier to entry. Check it out at https://copr.fedorainfracloud.org/. This would be a great place to start, and then once we have modular EPEL up and running you could migrate packages to that. -- Matthew Miller Fedora Project Leader ___ 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
[EPEL-devel] Re: FreeRDP version updates.
On Sat, 5 Oct 2019 at 06:23, Darren Wise wrote: > > Hey folks, > > Whom could I speak to about an EPEL package version update regarding FreeRDP > (freerdp-1.0.2-15.el7.x86_64, freerdp-libs-1.0.2-15.el7.x86_64, > freerdp-devel-1.0.2-15.el7.x86_64, freerdp-plugins-1.0.2-15.el7.x86_64) > verses the FreeRDP version 2.0 variants. > > The reason I asking is because I was relying on this version currently within > CentOS7 EPEL repository in order to develop for APACHE Guacamole, however > FreeRDP2.0 is not noticed when installed, the EPEL update occurred (must have > been) around the middle of September? 13th and after? > > I also noticed that multiple versions are not maintained, could I please be > pointed to somewhere I could get a complete mirror of the EPEL repository and > I'd be happy to maintain myself online? > -Maybe I could start an repository online funded by myself which maintains > multiple versions? > Sorry I am not parsing what you have problems with. Did you have packages which were updated and you were not aware it would happen? Did you have packages which were not updated but you need them to be? Did you have packages which installed which are broken? [It is ok if the answer to all of those are 'yes, and this is what I meant..' ] The complete mirror of the EPEL repository is whatever is in the repository at any time. If you are needing older versions of packages, you need to go spelunking through the koji.fedoraproject.org build system to find older versions of the packages. I wish there was an easier way to make this available.. but the tools are meant to do one thing well (take a source code, build it and put it ftp.) versus multiple things well. > Chances are I'm posting in the wrong place, but for me, this is an EPEL > development I was not expecting heh. > > Kind regards, > Darren Wise___ > 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 -- 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: Defining the future of the packager workflow in Fedora
On 05. 10. 19 2:16, Kevin Kofler wrote: Miro Hrončok wrote: It goes like this: - master and f31 are at the same commit "aa" - I push a change only possible in rawhide, commit "bb" to master (it includes release bump and changelog entry) - a commit relevant for both, "cc" is pushed to master (it includes release bump and changelog entry) - on f31, I run `git cherry-pick cc` => conflict I don't worry about having "Fedora 31 mass rebuild" or "Rebuilt for python 3.8" changelong entries in Fedora 29 (it gives me a little flinch, but nothing serious). i worry about the bb commit I cannot merge into f31 (e.g. if it implements some Fedora 32 change). Then obviously, people start inventing %if spaghetti. And %if is actually the correct fix for this issue. See, e.g., the one I had to add to qt5-qtwebengine after you broke it for F29 with your mass change: https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/05a52d121d49972989aea8127e22e25f0292333c?branch=master Your example is not valid. This is not a mass change, this was an individual change presented to the package maintainers via a PR that was not merged by me: https://src.fedoraproject.org/rpms/qt5-qtwebengine/pull-request/3 Had there been a "please, make it build on F29" comment, I would have adapted it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-31-20191005.n.0 compose check report
No missing expected images. Failed openQA tests: 6/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20191004.n.0): ID: 463524 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/463524 ID: 463563 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/463563 ID: 463574 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/463574 Old failures (same test failed in Fedora-31-20191004.n.0): ID: 463540 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/463540 ID: 463553 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/463553 ID: 463576 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/463576 ID: 463587 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/463587 Soft failed openQA tests: 2/153 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-31-20191004.n.0): ID: 463569 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/463569 Old soft failures (same test soft failed in Fedora-31-20191004.n.0): ID: 463657 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/463657 Passed openQA tests: 145/153 (x86_64) New passes (same test not passed in Fedora-31-20191004.n.0): ID: 463581 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/463581 ID: 463656 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/463656 Skipped non-gating openQA tests: 1 of 155 Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.06 to 0.17 Previous test data: https://openqa.fedoraproject.org/tests/463045#downloads Current test data: https://openqa.fedoraproject.org/tests/463544#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Average CPU usage changed from 22.81428571 to 11.55714286 Previous test data: https://openqa.fedoraproject.org/tests/463046#downloads Current test data: https://openqa.fedoraproject.org/tests/463545#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.20 to 0.38 Previous test data: https://openqa.fedoraproject.org/tests/463048#downloads Current test data: https://openqa.fedoraproject.org/tests/463547#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 916 MiB to 733 MiB 1 packages(s) removed since previous compose: libieee1284 System load changed from 2.00 to 1.31 Previous test data: https://openqa.fedoraproject.org/tests/463061#downloads Current test data: https://openqa.fedoraproject.org/tests/463560#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Used mem changed from 726 MiB to 883 MiB 1 packages(s) removed since previous compose: libieee1284 System load changed from 0.32 to 0.51 Previous test data: https://openqa.fedoraproject.org/tests/463063#downloads Current test data: https://openqa.fedoraproject.org/tests/463562#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Mount /run/user/1000 contents changed to 114.0824338% of previous size Previous test data: https://openqa.fedoraproject.org/tests/463079#downloads Current test data: https://openqa.fedoraproject.org/tests/463578#downloads Installed system changes in test x86_64 universal install_package_set_kde: System load changed from 0.89 to 3.58 Average CPU usage changed from 28.79523810 to 85.3667 Previous test data: https://openqa.fedoraproject.org/tests/463128#downloads Current test data: https://openqa.fedoraproject.org/tests/463627#downloads -- 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
Fedora 31 compose report: 20191005.n.0 changes
OLD: Fedora-31-20191004.n.0 NEW: Fedora-31-20191005.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 12 Dropped packages:0 Upgraded packages: 167 Downgraded packages: 1 Size of added packages: 13.45 MiB Size of dropped packages:0 B Size of upgraded packages: 5.19 GiB Size of downgraded packages: 26.64 MiB Size change of upgraded packages: -186.41 MiB Size change of downgraded packages: -45.27 KiB = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: cascadia-code-fonts-1909.16-1.fc31 Summary: A monospaced font designed for programming and terminal emulation RPMs:cascadia-code-fonts Size:97.25 KiB Package: doh-0.1-2.fc31 Summary: Application for DNS-over-HTTPS name resolves and lookups RPMs:doh Size:89.69 KiB Package: gnome-passwordsafe-3.32.0-2.fc31 Summary: Password manager for GNOME RPMs:gnome-passwordsafe Size:391.84 KiB Package: ladspa-swh-plugins-0.4.17-5.fc31 Summary: A set of audio plugins for LADSPA RPMs:ladspa-swh-plugins Size:2.36 MiB Package: libbpf-1:0.0.3-1.fc31 Summary: Libbpf library RPMs:libbpf libbpf-devel libbpf-static Size:780.54 KiB Package: perl-GStreamer-0.20-17.fc31 Summary: Perl bindings to version 0.10.x of the GStreamer framework RPMs:perl-GStreamer Size:1.29 MiB Package: powdertoy-94.1-4.fc31 Summary: Physics sandbox game RPMs:powdertoy Size:5.83 MiB Package: primecount-5.1-2.fc31 Summary: Fast prime counting function implementation RPMs:primecount primecount-devel primecount-libs Size:1.45 MiB Package: python-argon2-cffi-19.1.0-1.fc31 Summary: The secure Argon2 password hashing algorithm RPMs:python-argon2-cffi-doc python3-argon2-cffi Size:983.50 KiB Package: python-pykeepass-3.0.3-2.fc31 Summary: Python library to interact with keepass databases RPMs:python3-pykeepass Size:75.79 KiB Package: python-webscrapbook-0.6.2-1.fc31 Summary: A backend toolkit for management of WebScrapBook collection RPMs:python3-webscrapbook Size:67.96 KiB Package: rss2email-3.10-2.20190909git9c2d407.fc31 Summary: Deliver news from RSS feeds to your SMTP server as text or HTML mail RPMs:rss2email Size:84.90 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Lmod-8.1.17-3.fc31 Old package: Lmod-8.1.3-2.fc31 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.02 MiB Size change: 17.69 KiB Changelog: * Tue Jul 30 2019 Orion Poplawski - 8.1.10-1 - Update to 8.1.10 * Thu Aug 01 2019 Orion Poplawski - 8.1.10-2 - RHEL8 environment-modules uses alternatives * Sat Sep 21 2019 Zbigniew J??drzejewski-Szmek - 8.1.10-3 - Make sure /etc/profile.d/modules.sh has $MODULEPATH (#1461656) * Tue Sep 24 2019 Orion Poplawski - 8.1.17-1 - Update to 8.1.17 * Wed Sep 25 2019 Orion Poplawski - 8.1.17-2 - Make 00-modulepath.sh return 0 * Wed Sep 25 2019 Orion Poplawski - 8.1.17-3 - Make 00-modulepath.sh return 0, but not exit (bugz#1755666) Package: NetworkManager-1:1.20.4-1.fc31 Old package: NetworkManager-1:1.20.2-3.fc31 Summary: Network connection manager and user applications RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth NetworkManager-config-connectivity-fedora NetworkManager-config-server NetworkManager-dispatcher-routing-rules NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan Size: 26.76 MiB Size change: -9.99 KiB Changelog: * Mon Sep 30 2019 Thomas Haller - 1:1.20.4-1 - Update to 1.20.4 release - wifi: fix crash related to Wi-Fi P2P - initrd: handle rd.znet parameter for s390 (rh #1753975) - core: don't generate default-wired-connection if profile exists (rh #1727909) Package: R-microbenchmark-1.4.7-1.fc31 Old package: R-microbenchmark-1.4.6-3.fc31 Summary: Accurate Timing Functions RPMs: R-microbenchmark Size: 361.43 KiB Size change: 9.66 KiB Changelog: * Tue Sep 24 2019 Elliott Sales de Andrade - 1.4.7-1 - Update to latest version Package: aespipe-2.4e-5.fc31 Old package: aespipe-2.4e-4.fc31 Summary: AES-based encryption tool for tar/cpio and loop-aes imagemore RPMs: aespipe Size: 255.33 KiB Size change: 450 B Changelog: * Sun Aug 18 2019 Jirka Hladky - 2.4e-5 - Rebuild for F31 Package: analitza-19.08.0-2.fc31 Old package: analitza-19.04.3-2.fc31 Summary: Library of mathematical features RPMs: analitza analitza-devel Size: 3.76 MiB Size change: 867 B Changelog: * Mon Aug 19 2019 Rex Dieter - 19.08.0-1 - 19.08.0 * Wed Sep 25 2019 Jan Grulich - 19.08.0-2 - rebuild (qt5) Package: appmenu-qt5-0.3.0+16.10.20160628.1-18.fc31 Old package: appmenu-qt5-0.3.0+16.10.20160628.1-17.fc31 Summary: Support for global DBus-exported
Re: what to do without fedocal [was Re: CPE Team Weekly Update: 2019-10-04]
Let's start from the very beginning maybe. What are the use cases for the Fedora Calendar? * Group meetings These events need shared ownership, we submit them once and keep "forever". I think this is a good candidate for Git PR workflow used by OpenStack. * Test Days Test Days are always associated with the Test Day wiki page. We should just generate them automatically. * Scheduled infra outages Same here, infra outages should have a Taiga or Pagure issue associated with them. We can fetch the list and update calendar automatically. * Release schedule Afaik, it is also driven by wiki pages. If we agree on a format, we can create a dedicated ical feed out of them. * Personal Vacation Not used currently. Maybe instead of asking people to submit their entries we can setup some kind of aggregation of personal feeds, like planet.fedoraproject.org, but for calendars? I created a wiki page [1] to collect notes. Feel free to contribute. [1] https://fedoraproject.org/wiki/User:Bookwar/fedocal_notes -- Aleksandra Fedorova bookwar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1758758] mod_perl-2.0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1758758 --- Comment #1 from Upstream Release Monitoring --- The following Sources of the specfile are not valid URLs so we cannot automatically build the new version for you. Please use URLs in your Source declarations if possible. - perl.conf - perl.module.conf -- 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 1758758] New: mod_perl-2.0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1758758 Bug ID: 1758758 Summary: mod_perl-2.0.11 is available Product: Fedora Version: rawhide Status: NEW Component: mod_perl Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jkal...@redhat.com, jor...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.0.11 Current version/release in rawhide: 2.0.10-17.fc31 URL: http://search.cpan.org/dist/mod_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/1998/ -- 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 1758586] perl-MLDBM for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1758586 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/17711 https://pagure.io/releng/fedora-scm-requests/issue/17712 -- 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: Defining the future of the packager workflow in Fedora
Fabio Valentini wrote:
> Additionally, if-guarding every non-backwards compatible change will
> result in unmaintainable, brittle and broken .spec files pretty fast.
> Nobody should be expected to work through if-else-endif spaghetti (and I'm
> not even talking about automated tools here, which almost never will
> handle conditionals entirely correctly, and probably never can). And never
> mind that people don't actually remove conditionals for EOL fedora
> releases ...
I do, for most packages. At least when I need to work on the package anyway.
I wouldn't submit a build just for that.
Though for some packages, I get told to leave ancient conditionals in for
EPEL. (You can usually recognize them because the conditionals also include
%{?rhel}.)
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
Re: Modularity and the system-upgrade path
Fabio Valentini wrote: > Another benefit of this would be that the "*-modular" repositories > could be disabled by default, which would eliminate a whole lot of > upgrade issues for "normal users". > Only people who *actually want* alternate versions would enable > modules (and *-modular repos?), and they can then expected to know how > to handle upgrade issues. +1. I don't understand why Modularity was not implemented that way to begin with. > I think that letting people drop ownership and maintenance of "normal > packages" and *only* doing modules instead was a mistake. But that's > just my opinion ;) +1, not just yours. ;-) 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 1758596] perl-FreezeThaw for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1758596 Paul Howarth changed: What|Removed |Added Status|NEW |ASSIGNED CC||p...@city-fan.org Assignee|andr...@bawue.net |p...@city-fan.org --- Comment #1 from Paul Howarth --- https://pagure.io/releng/fedora-scm-requests/issue/17709 https://pagure.io/releng/fedora-scm-requests/issue/17710 -- 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: what to do without fedocal [was Re: CPE Team Weekly Update: 2019-10-04]
Hi, Matthew, On Fri, Oct 4, 2019 at 9:47 PM Matthew Miller wrote: > > On Fri, Oct 04, 2019 at 05:58:19PM +0100, Aoife Moloney wrote: > >Fedocal: If no maintainer is found by October 18th, it will be > >decommissioned. > > This is pretty huge, since we use this to keep IRC meeting channels > coordinated. We used to use this to track people's vacations and > away-from-project time, but I don't think many people are reliably doing > that anymore, so from my point of view it's the meetings that are the big > thing. That is: > > 1. Looking to find the next meetings for a particular team > 2. Finding an empty meeting spot for a new reoccuring or one-off meeting > 3. The fancy channel bot stuff which knows about upcoming meetings. > > If no one steps up to take on maintaining this app, I'm going to set up a > wiki or docs site page to cover #1 and #2. We'll lose #3, and probably some > other stuff, but... I don't see a good immediate alternative. I filed an issue [1] to take over the maintenance of the app. Btw, it would be easier to find maintainers if expectations were set in advance, so that they know what they are applying for. But I'd like to keep this discussion going. While I am stepping in to _maintain_ the app and infra for it, I don't have plans to _develop_ it further in its current form. Thus I think we should consider alternatives and how we can migrate from a Fedora specific app, to some simple and easy to maintain tooling. To give an example: in OpenStack meetings are stored in a git repo [2], then set of scripts renders jinja template to show them on web and ical-feed, so you can import the entire set into the calendar of your choice. With additional JS magic [3] one can render a nice interactive calendar on top of it. [1] https://pagure.io/fedora-infrastructure/issue/8274 [2] https://opendev.org/opendev/irc-meetings/ [3] https://fullcalendar.io/docs/events-array -- Aleksandra Fedorova bookwar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity and the system-upgrade path
On Fri, Oct 4, 2019 at 9:32 PM Miro Hrončok wrote:
>
> On 04. 10. 19 16:57, Stephen Gallagher wrote:
> > Right now, there are two conflicting requirements in Fedora Modularity
> > that we need to resolve.
> >
> > 1. Once a user has selected a stream, updates should follow that
> > stream and not introduce incompatiblities. Selected streams should not
> > be changed without direct action from the user.
> > 2. So far as possible, Modularity should be invisible to those who
> > don't specifically need it. This means being able to set default
> > streams so that `yum install package` works for module-provided
> > content.
> >
> > Where this becomes an issue is at system-upgrade time (moving from
> > Fedora 30->31 or continuously tracking Rawhide). Because of
> > requirement 1, we cannot automatically move users between streams, but
> > in the case of release upgrades we often want to move to a new default
> > for the distribution.
>
>
> Wouldn't it be easier if the "default stream" would just behave like a regular
> package?
>
> I can think of two solutions of that:
>
> 1. (drastic for modular maintainers)
>
> We keep miantaining the default versions of things as ursine packages. We only
> modularize alternate versions.
>
> Pros: Users who don't want alternate versions won't be affected by
> imperfections
> of our modular design. No Ursa Major/Prime needed in the buildroot.
>
> Cons: Modular maintainers who do modules with just one stream because it is
> easier for them would need to rollback to what's easier for everybody else but
> them. Modular maintainers who do multiple modular streams would need to
> maintain
> both the alternate streams and ursine packages.
I think this is the best way forward, and I don't think it's "drastic"
for maintainers. They *already* maintain a default branch, for which
similar Packaging / Update Guidelines apply than for non-modular
packages. They could even use a package.cfg file to automatically
build stuff for multiple fedora branches ...
In my opinion, this is also the most "fair" approach, because it
doesn't shift the maintenance burden from one packager to *everyone
else*.
It results in the least disruption for users who want default versions
of things.
It means no more disruptions for packagers who rely on the packages in
question - they can just target the default ("ursine") versions.
Another benefit of this would be that the "*-modular" repositories
could be disabled by default, which would eliminate a whole lot of
upgrade issues for "normal users".
Only people who *actually want* alternate versions would enable
modules (and *-modular repos?), and they can then expected to know how
to handle upgrade issues.
> 2. (potentially dangerous consequences?)
>
> We put the default modular stream into our regular repos, similarly to what we
> try to do in the buildroot. "dnf install Foo" would install the Foo package
> and
> would not enbale any streams or modules. The modular maintainers would keep
> maintaining the modules as now, the infrastructure would compose the defaults
> into the regular repo (or an additional but default-enabled one).
>
> Pros: Maintainers would keep doing what they desire.
>
> Cons: We would need to make this technically possible and figure out all the
> corner cases (however AFAIK this needs to be done for the "modules in
> buildroot"
> thing as well).
I see some issues with this approach. For example, the modularized
Java packages dropped a whole lot of "cruft", which now makes these
packages slightly incompatible with the non-modular packages - this
includes dropping Epoch from packages, dropping subpackages without
obsoleting them, etc. This is probably not a problem for module
streams, but it definitely *is* a problem if such modular packages
start to get treated like "normal packages".
> WDYT?
I think that letting people drop ownership and maintenance of "normal
packages" and *only* doing modules instead was a mistake. But that's
just my opinion ;)
Fabio
> --
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 1758574] perl-ExtUtils-CChecker for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1758574 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2019-7111331884 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7111331884 -- 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
[EPEL-devel] FreeRDP version updates.
Hey folks, Whom could I speak to about an EPEL package version update regarding FreeRDP (freerdp-1.0.2-15.el7.x86_64, freerdp-libs-1.0.2-15.el7.x86_64, freerdp-devel-1.0.2-15.el7.x86_64, freerdp-plugins-1.0.2-15.el7.x86_64) verses the FreeRDP version 2.0 variants. The reason I asking is because I was relying on this version currently within CentOS7 EPEL repository in order to develop for APACHE Guacamole, however FreeRDP2.0 is not noticed when installed, the EPEL update occurred (must have been) around the middle of September? 13th and after? I also noticed that multiple versions are not maintained, could I please be pointed to somewhere I could get a complete mirror of the EPEL repository and I'd be happy to maintain myself online? -Maybe I could start an repository online funded by myself which maintains multiple versions? Chances are I'm posting in the wrong place, but for me, this is an EPEL development I was not expecting heh. Kind regards, Darren Wise___ 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
Intent to retire libvtemm
Hi, I'm the "upstream maintainer" of libvtemm. In quotes, because last change I have made to the project was 8 years ago. It depends on an orphaned package vte (which is based on gtk2). It's also a leaf package. I don't think it makes sense to even orphan it. I intend to retire the package within the week. It is also first time I'll do anything related to fedora packaging since years, so hopefully I won't break anything. Cheers, Krzesimir ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Defining the future of the packager workflow in Fedora
On Sat, Oct 5, 2019, 02:17 Kevin Kofler wrote: > Miro Hrončok wrote: > > It goes like this: > > > > - master and f31 are at the same commit "aa" > > - I push a change only possible in rawhide, commit "bb" to master > > (it includes release bump and changelog entry) > > - a commit relevant for both, "cc" is pushed to master > > (it includes release bump and changelog entry) > > - on f31, I run `git cherry-pick cc` => conflict > > > > I don't worry about having "Fedora 31 mass rebuild" or "Rebuilt for > python > > 3.8" changelong entries in Fedora 29 (it gives me a little flinch, but > > nothing serious). i worry about the bb commit I cannot merge into f31 > > (e.g. if it implements some Fedora 32 change). > > > > Then obviously, people start inventing %if spaghetti. > > And %if is actually the correct fix for this issue. > > See, e.g., the one I had to add to qt5-qtwebengine after you broke it for > F29 with your mass change: > > https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/05a52d121d49972989aea8127e22e25f0292333c?branch=master > > IMHO, mass changes are only acceptable if the result builds on all > supported > Fedora releases. Breaking the build for F29 is only acceptable after it > reaches EOL. So your mass change should have included this %if, or ideally > an update pushed to F29 to make the conditional unnecessary. > That's your opinion. Some packagers (like me) actually maintain the branches for each fedora release separately. Doing mass changes that way would also place a pretty big burden upon anyone who actually wants to work on fedora-wide improvements. Additionally, if-guarding every non-backwards compatible change will result in unmaintainable, brittle and broken .spec files pretty fast. Nobody should be expected to work through if-else-endif spaghetti (and I'm not even talking about automated tools here, which almost never will handle conditionals entirely correctly, and probably never can). And never mind that people don't actually remove conditionals for EOL fedora releases ... Fabio > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
