[Bug 1672088] perl-Mojolicious version clash with perl-IO-Socket-SSL
https://bugzilla.redhat.com/show_bug.cgi?id=1672088 --- Comment #2 from Emmanuel Seyman --- I pointed this bug out on Freenode/#mojo and got the following response: 12:51 < eseyman> FYI, https://bugzilla.redhat.com/show_bug.cgi?id=1672088 12:58 < kraih> hahaha, yea, good luck with that proposal! 13:01 < kraih> there's been security relevant changes in IO::Socket::SSL that we now rely on, we will never downgrade that dependency Given that perl-IO-Socket-SSL in RHEL has several backported security fixes, I'm tempted to do what Petr suggests. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora 30 Mass Rebuild
Hi all, Per the Fedora 30 schedule[1] we started a mass rebuild for Fedora 30 on Jan 31st 2019. We did a mass rebuild for Fedora 30 for the changes listed in: https://pagure.io/releng/issue/8086 Mass rebuild was done in a side tag (f30-rebuild) and are now getting moved over to f30. Failures can be seen https://kojipkgs.fedoraproject.org/mass-rebuild/f30-failures.html Things still needing rebuilt https://kojipkgs.fedoraproject.org/mass-rebuild/f30-need-rebuild.html 19097 builds have been tagged into f30, there s currently 1787 failed builds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on freenode, by dropping an email to our list[2] or filing an issue in pagure[3] Regards, Mohan Boddu. [1] https://fedoraproject.org/wiki/Releases/30/Schedule [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://pagure.io/releng/ ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
package managemt symlink
Dear Fedora mailing list community, I am Sören alias Valor Naram and I founded the project "goeasyLinux". I will help to make linux more user friendly. A short introduction to "goeasyLinux" can be found at https://github.com/ValorNaram/goeasylinux/blob/master/README.md The specification I wrote in order to make a cross platform symlink to package management systems: https://github.com/ValorNaram/goeasylinux/blob/master/package%20management/package%20install.md With your help I want to make package installing/removing equal on all linux systems without disturbing the diversity we have across linux distributions. In order to do that we need just a symlink, no replacement of existing software. I think you did something similar in the past. Best wishes Sören alias Valor Naram ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1672481] New: perl-Glib-Object-Introspection-0.047 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672481 Bug ID: 1672481 Summary: perl-Glib-Object-Introspection-0.047 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Glib-Object-Introspection Keywords: FutureFeature, Triaged Assignee: berra...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: berra...@redhat.com, dd...@cpan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.047 Current version/release in rawhide: 0.046-2.fc30 URL: http://search.cpan.org/dist/Glib-Object-Introspection/ 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/2924/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1672082] perl-Inline-0.81 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672082 --- Comment #5 from Fedora Update System --- perl-Inline-0.81-1.fc29 has been pushed to the Fedora 29 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-2019-a01e1d8e4f -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: MBI (Playground 2.0)
On 2/4/19 4:03 PM, Neal Gompa wrote: > Aside from the times when it falls over for various reasons, I've had > entire days where I wait for a build to even start, because people who > use it for doing things like building KDE, chromium, or the Linux > kernel occupy literally all the available builder slots for a long > time. There aren't that many slots and it's easy to fill that up. > There's usually a large queue of packages to build, but not enough > builders to allow them to get done. Well, thats not supposed to be the case. Each user is given a limited amount of slots, so if say I dumped 100 kernels on it, it would only do a few of those at a time. So, sounds like a bug in allowing people more slots than they should have? > That indicates two things: > 1. The builders are weak and so builds take a long time (which means > slots are held up longer) Could be indeed. Could look at increasing the size... > 2. The demand and popularity of the service isn't being handled > appropriately (i.e. it should get more builders provisioned). Well, there's another issue here that seems to be a copr bug (see below) > I don't do things like build kernels often, but when I do, it usually > doesn't take all day. But stuff like Chromium is hard to build > locally, so I appreciate that we have somewhere to build and publish. > > But, as of right now, there are 16 tasks running, with 85 tasks > waiting for a builder. Yeah, but copr is allocated the following: 150 instances 200 vcps 488 GB ram So, either copr is loosing track of it's builders or openstack is doing something odd and not really providing that. I know openstack has accounting issues, but I do see about 65 or so builder instances, so I think this is on the copr side. So, fixing this would go a long way to helping out. Additionally, sometimes jobs finish, but copr shows them as still running. For example, the oldest job now: https://copr.fedorainfracloud.org/coprs/omos/kernel-testing/ which copr shows running for 11 hours, the logs show it's done (I don't know how long ago as there's no timestamps). > I wish we had visualizations like the ones OBS has[1][2], so that we > have an idea of how stuff is occupied and know at a glance that we're > over capacity. > > All I know right now is that it's easy to see that COPR gets into a > state where I just wind up waiting for builds to even start. > > [1]: https://build.opensuse.org/monitor > [2]: https://build.opensuse.org/monitor/old Well, we do have: https://copr.fedorainfracloud.org/status/stats/ but some of it doesn't match up with osbs, since copr builders are dynamic. kevin 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1672470] New: perl-HTTP-BrowserDetect-3.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672470 Bug ID: 1672470 Summary: perl-HTTP-BrowserDetect-3.21 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-BrowserDetect Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org, st...@silug.org Target Milestone: --- Classification: Fedora Latest upstream release: 3.21 Current version/release in rawhide: 3.20-1.fc30 URL: http://search.cpan.org/dist/HTTP-BrowserDetect/ 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/5936/ -- 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://getfedora.org/code-of-conduct.html 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-02-05 - 91% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/02/05/report-389-ds-base-1.4.1.1-20190205git24271fe.fc29.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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[Bug 1668818] perl-File-BOM-0.15-9.fc30 FTBFS: t/01..bom.t with Encode 2.99
https://bugzilla.redhat.com/show_bug.cgi?id=1668818 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-File-BOM-0.15-8.fc28 |perl-File-BOM-0.15-8.fc28 ||perl-File-BOM-0.15-10.fc29 --- Comment #6 from Fedora Update System --- perl-File-BOM-0.15-10.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1669415] perl-Pod-Markdown-Github-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1669415 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Pod-Markdown-Github-0. |perl-Pod-Markdown-Github-0. |04-1.fc30 |04-1.fc30 |perl-Pod-Markdown-Github-0. |perl-Pod-Markdown-Github-0. |04-1.fc28 |04-1.fc28 ||perl-Pod-Markdown-Github-0. ||04-1.fc29 --- Comment #7 from Fedora Update System --- perl-Pod-Markdown-Github-0.04-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity WG (weekly)
Dear all, You are kindly invited to the meeting: Modularity WG (weekly) on 2019-02-05 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting of the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) 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/9443/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Please review: Disable perl by default
https://pagure.io/389-ds-base/pull-request/50200 — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[Bug 1668818] perl-File-BOM-0.15-9.fc30 FTBFS: t/01..bom.t with Encode 2.99
https://bugzilla.redhat.com/show_bug.cgi?id=1668818 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-File-BOM-0.15-8.fc28 Resolution|--- |ERRATA Last Closed||2019-02-05 01:54:27 --- Comment #5 from Fedora Update System --- perl-File-BOM-0.15-8.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1669415] perl-Pod-Markdown-Github-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1669415 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Pod-Markdown-Github-0. |perl-Pod-Markdown-Github-0. |04-1.fc30 |04-1.fc30 ||perl-Pod-Markdown-Github-0. ||04-1.fc28 Resolution|--- |ERRATA Last Closed||2019-02-05 01:54:26 --- Comment #6 from Fedora Update System --- perl-Pod-Markdown-Github-0.04-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fixing Wireguard spec file
On 2/4/19 6:38 PM, Dominique Martinet wrote: It's the second time I read wireguard would be coming in the 5.0 kernel here - what makes you folk say that? I certainly haven't seen anything to that extent lately and 5.0 is petty well under way, something as big a zinc likely won't make the cut this late. The people that are working on WireGuard think things should be stable by this summer (June) so it most likely won't make 5.0 but something a bit after. My point is, I rather spend my efforts stabilizing the DKMS packages that have worked for years now, rather than change things totally over to using an akmod based approach. Especially with the possibility of having WireGuard upstream sometime this year. (as for akmods, it's packaged as such as well in rpmfusion, and that just works afaict) Indeed. If those fit peoples needs, I urge them to use them. Joe -- Joe Doss j...@solidadmin.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1672082] perl-Inline-0.81 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672082 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-Inline-0.81-1.fc28 has been pushed to the Fedora 28 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-2019-cbd5cb5206 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Unannounced soname bumps: proj and geos
Hi, The recent bump of proj in Rawhide from 4.9.3 to 5.2.0 also bumped the soname from libproj.so.12 to libproj.so.13. The bump of geos in Rawhide from 3.6.1 to 3.7.1 also bumped the soname from libgeos-3.6.1.so to libgeos-3.7.1.so. These bumps should be announced *before* the build has been made. Fortunately, as I was already investigating the possibility of updating proj, I have the list of proj-dependent packages already. I was not looking at geos, but hopefully the list below includes everyone. I have CC'd maintainers on the list to notify them that they will need to rebuild their packages (or I can do it myself at some point if they're busy.) Maintainers by package: R-rgdal qulogic R-rgeos qulogic dans-gdal-scriptsvolter fawkes rmattes thofmann timn gazebo rmattes gdal alexlan devrim jmlich mmahut oliver orion pali praiskup volter grassdaveisfera devrim neteler oliver volter libgeotiff devrim orion volter libosmiumtomh librasterlite2 volter libspatialitevolter mapnik alexlan tomh mapserverdevrim jujens oliver pali merkaartor slankes till ncl orion nodejs-mapnikjamielinux tomh ogdi sharkcz osgearth smani osm2pgsqlfab perl-PDL alexl caillon caolanm johnp jplesnik lkundrak mbarnes mmaslano ppisar rhughes rnorwood rstrode ssp pgRoutingpkubat volter player kwizart rmattes timn ttorling postgis devrim jmlich maxamillion pkajaba pkubat praiskup pyproj jdekloe python-basemap jspaleta limb python-cartopy qulogic python-mapniktomh qgis bruno daveisfera volter qlandkartegt sharkcz qmapshacksharkcz qt-mobility company heliocastro rdieter than saga volter shapelib lucilanga smani spatialite-gui volter spatialite-tools jdornak jstanek pkubat volter vfrnav sailer xastir lucilanga Packages by maintainer: alexl perl-PDL alexlangdal mapnik bruno qgis caillonperl-PDL caolanmperl-PDL companyqt-mobility daveisfera grass qgis devrim gdal grass libgeotiff mapserver postgis fabosm2pgsql heliocastro qt-mobility jamielinux nodejs-mapnik jdekloepyproj jdornakspatialite-tools jmlich gdal postgis johnp perl-PDL jplesnik perl-PDL jspaleta python-basemap jstanekspatialite-tools jujens mapserver kwizartplayer limb python-basemap lkundrak perl-PDL lucilanga shapelib xastir maxamillion postgis mbarnesperl-PDL mmahut gdal mmaslano perl-PDL netelergrass oliver gdal grass mapserver orion gdal libgeotiff ncl pali gdal mapserver pkajabapostgis pkubat pgRouting postgis spatialite-tools ppisar perl-PDL praiskup gdal postgis qulogicR-rgdal R-rgeos python-cartopy rdieterqt-mobility rhughesperl-PDL rmattesfawkes gazebo player rnorwood perl-PDL rstrodeperl-PDL sailer vfrnav sharkczogdi qlandkartegt qmapshack slankesmerkaartor smani osgearth shapelib sspperl-PDL than qt-mobility thofmann fawkes till merkaartor timn fawkes player tomh libosmium mapnik nodejs-mapnik python-mapnik ttorling player volter dans-gdal-scripts gdal grass libgeotiff librasterlite2 libspatialite pgRouting qgis saga spatialite-gui spatialite-tools -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python packages with extras dependencies
On 05. 02. 19 0:44, Eli Young wrote: Python packages can specify extras dependencies, which are sets of dependencies not required for core functionality, and which generally correspond to some feature. These can then be specified by downstream consumers of the package. For example, requests has an entry in extras called security[1], which currently adds requirements of python packages pyOpenSSL >= 0.14, cryptography >= 1.3.4, and idna >= 2.0.0. A downstream consumer that wants to use this would add a dependency on requests[security]. From what I can tell, the current practice in Fedora packaging is to ignore these. This simplifies packaging Python modules that have extras specified, but ultimately pushes the specification of those dependencies down into every consumer of the package, whether users or other packages. As an example of this, I currently maintain the python-dns-lexicon package, which provides a common CLI and API for various different DNS providers. Some of the providers have additional dependencies that are necessary to function, and which are specified as extras. The Plesk provider, for example, also requires python-xmltodict[2]. In line with what appears to standard practice, extra dependencies are not currently installed with the broader python-dns-lexicon package. If, however, a user or dependent package wants to utilize the Plesk functionality of python-dns-lexicon, they now need to know that python-xmltodict needs to be installed, and will need to check whenever the package updates as to whether or not that has changed. How should we be handling this? Right now, it seems that most packages follow this behavior of punting on the responsibility to package consumers. Should this continue? If not, how should we handle things? Should we just include all extras dependencies in the parent package? Alternatively, should we have dummy/meta subpackages for extras that require the parent package as well as any extras dependencies (e.g. python-dns-lexicon-plesk would require python-dns-lexicon and python-xmltodict)? This (metapackages) is what I've done in python-trimesh: https://src.fedoraproject.org/rpms/python-trimesh/blob/master/f/python-trimesh.spec#_62 https://src.fedoraproject.org/rpms/python-trimesh/blob/master/f/python-trimesh.spec#_86 I'd still consider this on case by case basis instead of developing a general solution, sometimes a simple Recommends works. Sometimes, it's more complicated. I'm CCing packaging and python to get more attention to this, but please keep the discussion on devel, so it's not shattered. [1]: https://github.com/requests/requests/blob/v2.21.0/setup.py#L105 [2]: https://github.com/AnalogJ/lexicon/blob/v3.0.6/setup.py#L101 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Fixing Wireguard spec file
Joe Doss wrote on Mon, Feb 04, 2019 at 03:43:59PM +: > I know what akmods are and I don't have the bandwidth on my end to > switch to them with WireGuard coming in the 5.0 kernel. It's the second time I read wireguard would be coming in the 5.0 kernel here - what makes you folk say that? I certainly haven't seen anything to that extent lately and 5.0 is petty well under way, something as big a zinc likely won't make the cut this late. (as for akmods, it's packaged as such as well in rpmfusion, and that just works afaict) -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: MBI (Playground 2.0)
On Mon, Feb 4, 2019 at 5:14 AM Kevin Fenzi wrote: > > On 1/31/19 4:52 PM, Neal Gompa wrote: > > ...snip... > > > COPR was supposed to be that outlet, but no one gives a damn about it. > > Everyone complains that the service is "bad" and that the design is > > "bad" but no one wants to actually constructively improve it. The > > quality of service on COPR has fallen due to lack of care and > > unwillingness to invest, so what are we supposed to do? The horrible > > I've heard you and some others say this, but can you perhaps expand on > it? How has quality of service of copr fallen? > > There are times when a bunch of builds are dumped on it that it takes a > bit to catch up, but it's usually like an hour not days or anything. > Is it the build time you refer to? Or something(s) else? > Aside from the times when it falls over for various reasons, I've had entire days where I wait for a build to even start, because people who use it for doing things like building KDE, chromium, or the Linux kernel occupy literally all the available builder slots for a long time. There aren't that many slots and it's easy to fill that up. There's usually a large queue of packages to build, but not enough builders to allow them to get done. That indicates two things: 1. The builders are weak and so builds take a long time (which means slots are held up longer) 2. The demand and popularity of the service isn't being handled appropriately (i.e. it should get more builders provisioned). I don't do things like build kernels often, but when I do, it usually doesn't take all day. But stuff like Chromium is hard to build locally, so I appreciate that we have somewhere to build and publish. But, as of right now, there are 16 tasks running, with 85 tasks waiting for a builder. I wish we had visualizations like the ones OBS has[1][2], so that we have an idea of how stuff is occupied and know at a glance that we're over capacity. All I know right now is that it's easy to see that COPR gets into a state where I just wind up waiting for builds to even start. [1]: https://build.opensuse.org/monitor [2]: https://build.opensuse.org/monitor/old -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python packages with extras dependencies
On 05. 02. 19 0:44, Eli Young wrote: Python packages can specify extras dependencies, which are sets of dependencies not required for core functionality, and which generally correspond to some feature. These can then be specified by downstream consumers of the package. For example, requests has an entry in extras called security[1], which currently adds requirements of python packages pyOpenSSL >= 0.14, cryptography >= 1.3.4, and idna >= 2.0.0. A downstream consumer that wants to use this would add a dependency on requests[security]. From what I can tell, the current practice in Fedora packaging is to ignore these. This simplifies packaging Python modules that have extras specified, but ultimately pushes the specification of those dependencies down into every consumer of the package, whether users or other packages. As an example of this, I currently maintain the python-dns-lexicon package, which provides a common CLI and API for various different DNS providers. Some of the providers have additional dependencies that are necessary to function, and which are specified as extras. The Plesk provider, for example, also requires python-xmltodict[2]. In line with what appears to standard practice, extra dependencies are not currently installed with the broader python-dns-lexicon package. If, however, a user or dependent package wants to utilize the Plesk functionality of python-dns-lexicon, they now need to know that python-xmltodict needs to be installed, and will need to check whenever the package updates as to whether or not that has changed. How should we be handling this? Right now, it seems that most packages follow this behavior of punting on the responsibility to package consumers. Should this continue? If not, how should we handle things? Should we just include all extras dependencies in the parent package? Alternatively, should we have dummy/meta subpackages for extras that require the parent package as well as any extras dependencies (e.g. python-dns-lexicon-plesk would require python-dns-lexicon and python-xmltodict)? This (metapackages) is what I've done in python-trimesh: https://src.fedoraproject.org/rpms/python-trimesh/blob/master/f/python-trimesh.spec#_62 https://src.fedoraproject.org/rpms/python-trimesh/blob/master/f/python-trimesh.spec#_86 I'd still consider this on case by case basis instead of developing a general solution, sometimes a simple Recommends works. Sometimes, it's more complicated. I'm CCing packaging and python to get more attention to this, but please keep the discussion on devel, so it's not shattered. [1]: https://github.com/requests/requests/blob/v2.21.0/setup.py#L105 [2]: https://github.com/AnalogJ/lexicon/blob/v3.0.6/setup.py#L101 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Python packages with extras dependencies
Python packages can specify extras dependencies, which are sets of dependencies not required for core functionality, and which generally correspond to some feature. These can then be specified by downstream consumers of the package. For example, requests has an entry in extras called security[1], which currently adds requirements of python packages pyOpenSSL >= 0.14, cryptography >= 1.3.4, and idna >= 2.0.0. A downstream consumer that wants to use this would add a dependency on requests[security]. From what I can tell, the current practice in Fedora packaging is to ignore these. This simplifies packaging Python modules that have extras specified, but ultimately pushes the specification of those dependencies down into every consumer of the package, whether users or other packages. As an example of this, I currently maintain the python-dns-lexicon package, which provides a common CLI and API for various different DNS providers. Some of the providers have additional dependencies that are necessary to function, and which are specified as extras. The Plesk provider, for example, also requires python-xmltodict[2]. In line with what appears to standard practice, extra dependencies are not currently installed with the broader python-dns-lexicon package. If, however, a user or dependent package wants to utilize the Plesk functionality of python-dns-lexicon, they now need to know that python-xmltodict needs to be installed, and will need to check whenever the package updates as to whether or not that has changed. How should we be handling this? Right now, it seems that most packages follow this behavior of punting on the responsibility to package consumers. Should this continue? If not, how should we handle things? Should we just include all extras dependencies in the parent package? Alternatively, should we have dummy/meta subpackages for extras that require the parent package as well as any extras dependencies (e.g. python-dns-lexicon-plesk would require python-dns-lexicon and python-xmltodict)? [1]: https://github.com/requests/requests/blob/v2.21.0/setup.py#L105 [2]: https://github.com/AnalogJ/lexicon/blob/v3.0.6/setup.py#L101 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Boost 1.69 update with soname bumps in rawhide/F30
On 02/02/19 23:17 -0500, Rich Mattes wrote: On 1/30/19 7:31 AM, Jonathan Wakely wrote: The following packages use Boost.Signals which is been REMOVED from Boost. The packages must be updated to use Boost.Signals2 (or bundle an old Boost). Maintainers by package: ekiga mcrha pbrobinson freecad hobbes1069 jkastner zultron gazebo rmattes Gazebo apparently doesn't use boost::signals anymore, its build system trying to be detect the library is an oversight[1]. Once the mass rebuild dies down I'll incorporate the upstream patch and rebuild. Oh, nice! That's a lot easier than having to change the code :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Boost 1.69 update with soname bumps in rawhide/F30
On 31/01/19 12:55 -0600, Patrick Diehl wrote: Hi, I maintain the hpx package, which links against boost. I would prefer to build my package by myself, since we will need to update it to compile/link with boost 1.69. I tested it yesterday and we need to patch our last stable release to work with boost 1.69. The patch should be available next week. Thanks. I think the problem for hpx was that boost::system_error's constructor from boost::error_code is now explicit, but previously allowed implicit conversions. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] CMake Error: No source or binary directory provided
On 04/02/19 12:49 +0100, Vít Ondruch wrote: Hi, It seems that since CMake 3.13, it is required to invoke the cmake command explicitly with path to source, which was not required previously. IOW in F29 was enough to call: ~~~ $ cmake ~~~ while F30+ requires: ~~~ $ cmake . ~~~ Unfortunately, neither upstream nor Fedora packagers perceives this issue worth noting [1], although just during Ruby mass rebuild, I met already quite some failing packages due to this issue. Ah, I wondered what that message meant! I saw it for at least: LuxRender condor leatherman libapogee librime stp sumwars ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dxflib ABI changed yet nothing changed
On Mon, Feb 4, 2019 at 9:27 PM Samuel Rakitničan wrote: > > Hi, > > Got via e-mail that libdxflib's ABI changed in comparison to previous > release, yet nothing changed in the package except version bump for the mass > rebuild. Why is that? Got that for a package too, and the major thing that changed between the two build is GCC so that could be an optimization bug or undefined behavior leading to a different interpretation now? Hard to say, I didn't look at the ABI differences. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages to be retired
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 I plan to retire packages that were already announced 3 times next Monday. Unorphan/unretire packages at https://pagure.io/releng/issues (I still cannot unorphan packages, but rest assured that I monitor the tracker and I'm not retiring packages that have open request for unorphaning.) 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. Remarks: Some packages are falsely reported as orphaned for 60+ weeks. The issue was reported and I won't retire them sooner than after real 6 weeks. Sorry about that. Package (co)maintainers Status Change OSGi-bundle-ant-task orphan 0 weeks ago RunSnakeRun orphan 3 weeks ago autotrash frafra, orphan, robyduck 5 weeks ago blobbyorphan 0 weeks ago catkinorphan, rmattes, robotics-sig, 2 weeks ago thofmann clang5.0 orphan, tstellar 0 weeks ago clang6.0 orphan, tstellar 0 weeks ago dcm4che-test orphan 0 weeks ago dnsyo codeblock, orphan3 weeks ago fasd orphan 5 weeks ago glacier-cli orphan 0 weeks ago gnumedorphan 0 weeks ago hamster-time-tracker orphan 0 weeks ago hoard orphan 30 weeks ago jigdo jsteffan, orphan 0 weeks ago kapow orphan 0 weeks ago labyrinth orphan 1 weeks ago llvm5.0 jistone, orphan, tstellar0 weeks ago llvm6.0 orphan, tstellar 0 weeks ago memaker orphan 1 weeks ago nautilus-pastebin orphan 0 weeks ago nut-nutrition orphan 0 weeks ago python-ceilometermiddleware orphan 69 weeks ago python-cookiesadamwill, orphan 5 weeks ago python-django-post_office orphan 0 weeks ago python-django-stopforumspam orphan 0 weeks ago python-gencpp orphan, rmattes, robotics-sig, 2 weeks ago thofmann python-genlisporphan, rmattes, robotics-sig, 2 weeks ago thofmann python-genmsg orphan, rmattes, robotics-sig, 2 weeks ago thofmann python-genpy orphan, rmattes, robotics-sig, 2 weeks ago thofmann python-kafka orphan 78 weeks ago python-pankoclientorphan 78 weeks ago python-ripe-atlas-cousteauorphan 5 weeks ago python-ripe-atlas-sagan orphan 5 weeks ago python-socketIO-clientorphan 5 weeks ago ripe-atlas-tools orphan 5 weeks ago ros-release orphan, rmattes, robotics-sig, 2 weeks ago thofmann rospack orphan, rmattes, robotics-sig, 2 weeks ago thofmann rssdler orphan 0 weeks ago scout orphan 1 weeks ago toothchartorphan 1 weeks ago unp mstuchli, orphan, python-sig 3 weeks ago xsel mizdebsk, msrb, orphan 1 weeks ago xword orphan 1 weeks ago The following packages require
Re: Is system-config-users maintained or not?
On Mon, 2019-02-04 at 13:35 +0100, Nils Philippsen wrote: > On Sat, 2019-02-02 at 09:30 +0100, Miro Hrončok wrote: > > Hi, > > > > it seems system-config-users is broken [1], > > and appears to have no upstream [2]. > > > > Do we maintain it at this point at all? Should it be retired "for > > safety"? > > IIRC, Moez picked up maintenance from me long ago when I wanted to > retire it. As far as I'm concerned, it can go. Moez? A big BTW I know Moez , he co-maintain some packages with me ... But his activity seems zero since we have pagure as src.fedoraproject.org ... I think he pick these packages to maintain package alive (like I did for other packages) but now that we want it retired, what we need to do ? if user is more or less unresponsive ? start an non-responsive maintainer ? or could we be more direct and ask an admin to retire the package ? I have two other cases [1] [1] https://bugzilla.redhat.com/show_bug.cgi?id=1307681 https://bugzilla.redhat.com/show_bug.cgi?id=1565895 > Nils > -- > Nils Philippsen"Those who would give up Essential Liberty to > Software Engineer purchase a little Temporary Safety, deserve > neither > Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 > PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 > 3011 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1672325] perl-XML-Feed-0.57 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672325 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-XML-Feed-0.56 is |perl-XML-Feed-0.57 is |available |available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 0.57 Current version/release in rawhide: 0.55-1.fc30 URL: http://search.cpan.org/dist/XML-Feed 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/8396/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On 2/4/19 11:27 AM, Stephen John Smoogen wrote: > On Mon, 4 Feb 2019 at 12:14, Mátyás Selmeci wrote: >> >> On 1/31/19 1:05 PM, Kevin Fenzi wrote: >>> On 1/30/19 1:39 PM, Adam Williamson wrote: >>> Question: how plausibly can we sort of "test retire" yum? i.e. just somehow run a single compose process without it included, and see what breaks? >>> >>> Well, we could block yum in koji and remove it from all builders and see >>> what happens, but I think it will break all epel builds (unless we >>> switch epel to use dnf for buildroot population too) at least. >>> >>> kevin >> >> Can we put DNF in EPEL so people still targeting EL 7 can adapt their >> scripts? >> > > Dnf was added to RHEL-7 in the latest release as a tech preview and is > in CentOS extras. As such later versions can not be put in EPEL > without major packaging work. > Sounds good, I'll check it out from there. >> As a side note, this is a problem with Python 3, too; I can't get any >> Python 3 bindings for the yum/rpm libs on EL 7, which makes it hard to >> port software that uses them. >> > > There will be work on making a newer Python36 in EPEL in the next > couple of months. > I didn't know new packages would be added as part of that, I thought it was a rebuild / update of existing packages. Thanks, that would be useful. -Mat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
dxflib ABI changed yet nothing changed
Hi, Got via e-mail that libdxflib's ABI changed in comparison to previous release, yet nothing changed in the package except version bump for the mass rebuild. Why is that? Digest Summary: 1. dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 2. dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 --- (2019-02-04 05:48:12 UTC) dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 - https://taskotron.fedoraproject.org/artifacts/all/f7d968de-26bc-11e9-a292-525400fc9f92/tests.yml/libdxflib-3.17.0-8.fc30.log dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 --- (2019-02-04 05:48:16 UTC) dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 - https://taskotron.fedoraproject.org/artifacts/all/f7c055d8-26bc-11e9-9451-525400fc9f92/tests.yml/libdxflib-3.17.0-8.fc30.log dist.abicheck FAILED for libdxflib-3.17.0-8.fc30 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On Thu, Jan 31, 2019 at 07:08:14PM +0100, Miro Hrončok wrote: > On 31. 01. 19 16:32, Michal Domonkos wrote: > >On Wed, Jan 30, 2019 at 6:46 PM Miro Hrončok wrote: > >>Based on the entire discussion so far, here's my proposal: > >> > >> - we change this to a system wide change > >> - we move it to Fedora 31 > >> - we retire the packages from rawhide as soon as f30 is branched > >> regardless of > >>the dependent packages > >> - packages with broken deps / FTBFS due to this will be retired if not > >> fixed > >>by beta freeze > >> > >>Contingency mechanism: > >> > >> - if some process (releng or similar) needs the packages in order to ship > >>Fedora 31, the packages are added into a designated copr repo maintained by > >>the > >>person/team responsible for the tool that needs yum (or other packages > >>retired) > >> > >> - if the above is not possible and the packages are indeed needed in the > >>actual f31 repos, packages are unretired but the person/team responsible > >>for the > >>tool that needs yum maintains them as long as they need them and retires > >>them > >>once that is no longer true > > > >+1 > > > >As an alternative solution, based on a discussion with Neal Gompa > >today on IRC, I propose the following: > > > > - we remove python-urlgrabber from the original change proposal > >(i.e. keeping it in F30) > > - we proceed with the retirement of the rest of the YUM stack in F30 > > - we make sure the kojid PR[1] is merged in time for F30 > > > >This is based on the following two facts: > > > > - python-urlgrabber seems to be the last component of the YUM stack > >that turns this proposal into a "system-wide" change, due to a number > >of infra bits that require it (sigul, koji-containerbuild, osc or > >imagefactory). Therefore, if we just postpone the removal of > >python-urlgrabber to F31 and merge that kojid PR, we could perhaps > >agree on re-qualifying the change as "self-contained" (plus, there's > >also the possibility of porting[2] python-urlgrabber to Python 3, but > >that's for a separate discussion) > > - the kojid PR[1] is also in-line with another F30 change[3], so > >there should be enough incentive to have it merged > > > >Before I go ahead and edit the proposal: Does this variant make sense to you? > > It does to me. But well, I've been called a Python 2 deletionist > before, so not sure if I'm not biased :) FWIW, I like this "alternative proposal" better too. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On Mon, 4 Feb 2019 at 12:14, Mátyás Selmeci wrote: > > On 1/31/19 1:05 PM, Kevin Fenzi wrote: > > On 1/30/19 1:39 PM, Adam Williamson wrote: > > > >> Question: how plausibly can we sort of "test retire" yum? i.e. just > >> somehow run a single compose process without it included, and see what > >> breaks? > > > > Well, we could block yum in koji and remove it from all builders and see > > what happens, but I think it will break all epel builds (unless we > > switch epel to use dnf for buildroot population too) at least. > > > > kevin > > Can we put DNF in EPEL so people still targeting EL 7 can adapt their > scripts? > Dnf was added to RHEL-7 in the latest release as a tech preview and is in CentOS extras. As such later versions can not be put in EPEL without major packaging work. > As a side note, this is a problem with Python 3, too; I can't get any > Python 3 bindings for the yum/rpm libs on EL 7, which makes it hard to > port software that uses them. > There will be work on making a newer Python36 in EPEL in the next couple of months. > -Mat > > -- > Mátyás (Mat) Selmeci > Open Science Grid Software Team / Center for High-Throughput Computing > University of Wisconsin-Madison Department of Computer Sciences > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fixing Wireguard spec file
Was dkms working before you did the upgrade or was it already in a broken state? wireguard-dkms-0.0.20190123-2.fc29.noarch won't fix an already broken install, so you need to remove it and then install the new version. It should hopefully fix it moving forward. I started a thread on the WireGuard mailing list to track this issue https://lists.zx2c4.com/pipermail/wireguard/2019-February/003851.html so please reply there with any feedback once the next snapshot is released. Thanks, Joe ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Summary/Minutes from today's FESCo Meeting (2019-02-04)
= #fedora-meeting-1: FESCO (2019-02-04) = Meeting started by mhroncok at 15:01:40 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2019-02-04/fesco.2019-02-04-15.01.log.html . Meeting summary --- * init process (mhroncok, 15:01:40) * #1970 Action needed: Orphan packages will be retired if they remain orphaned for six weeks (mhroncok, 15:06:12) * LINK: https://pagure.io/fesco/issue/1970 (mhroncok, 15:06:12) * LINK: https://pagure.io/releng/issue/6365 (nirik, 15:23:18) * LINK: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190204.n.0/logs/depcheck (nirik, 15:23:49) * #2060 F30 System-Wide Change: DNF Better Counting (mhroncok, 15:39:02) * LINK: https://pagure.io/fesco/issue/2060 (mhroncok, 15:39:02) * ACTION: tyll will work with change owners to make sure the actual implementation is sane (mhroncok, 16:02:40) * AGREED: APPROVED (+7, 1, 0) (mhroncok, 16:02:57) * LINK: https://fedoraproject.org/wiki/FESCo_meeting_process says afree (mhroncok, 16:05:17) * AGREED: APPROVED (+7, 1, 0) (mhroncok, 16:05:25) * #2065 F30 System-Wide Change: GCC9 (mhroncok, 16:06:13) * LINK: https://pagure.io/fesco/issue/2065 (mhroncok, 16:06:13) * AGREED: APPROVED (+6, 0, 0) (mhroncok, 16:10:09) * Next week's chair (mhroncok, 16:11:49) * ACTION: jforbes chairs next meeting (mhroncok, 16:12:43) * Open Floor (mhroncok, 16:12:55) Meeting ended at 16:22:12 UTC. Action Items * tyll will work with change owners to make sure the actual implementation is sane * jforbes chairs next meeting Action Items, by person --- * jforbes * jforbes chairs next meeting * tyll * tyll will work with change owners to make sure the actual implementation is sane * **UNASSIGNED** * (none) People Present (lines said) --- * mhroncok (166) * bowlofeggs (108) * nirik (38) * tyll (35) * zbyszek (32) * sgallagh (29) * zodbot (16) * jforbes (14) * otaylor (9) * smooge (5) * contyk (2) * tyll_ (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Agenda for Tuesday's Modularity Team Meeting (2019-02-05)
Find below a list of topics which are planned to be discussed in the Fedora Modularity Team meeting on Tuesday at 15:00 UTC in #fedora-meeting-3 on irc.freenode.net. To find out when this is in your local time zone, check the Fedora Calendar (if you've set it and are logged in): https://apps.fedoraproject.org/calendar/modularity/#m5249 Alternatively, to convert UTC to your local time zone, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d 'Tuesday 15:00 UTC' Links to all issues below can be found at: https://pagure.io/modularity/report/meeting_agenda = Discussed and Voted = N/A = Followups = #topic #112 Discussion: Module lifecycles #link https://pagure.io/modularity/issue/112 .modularity 112 #link https://pagure.io/fesco/issue/2027 #topic #115 Discussion: Stream branch ownership for packages & modules #link https://pagure.io/modularity/issue/115 .modularity 115 #link https://pagure.io/fesco/issue/2028 #topic #119 Modularity WG Charter (contd.) #link https://pagure.io/modularity/issue/119 .modularity 119 = New business = N/A = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/modularity/report/meeting_agenda If you would like to add something to this agenda, you can file a new issue at https://pagure.io/modularity/issues, or bring it up at the end of the meeting during the open floor topic. Note that the meeting is one hour long and issues we don't get around to discussing may be deferred until the following meeting. -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On 1/31/19 1:05 PM, Kevin Fenzi wrote: > On 1/30/19 1:39 PM, Adam Williamson wrote: > >> Question: how plausibly can we sort of "test retire" yum? i.e. just >> somehow run a single compose process without it included, and see what >> breaks? > > Well, we could block yum in koji and remove it from all builders and see > what happens, but I think it will break all epel builds (unless we > switch epel to use dnf for buildroot population too) at least. > > kevin Can we put DNF in EPEL so people still targeting EL 7 can adapt their scripts? As a side note, this is a problem with Python 3, too; I can't get any Python 3 bindings for the yum/rpm libs on EL 7, which makes it hard to port software that uses them. -Mat -- Mátyás (Mat) Selmeci Open Science Grid Software Team / Center for High-Throughput Computing University of Wisconsin-Madison Department of Computer Sciences ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1672325] New: perl-XML-Feed-0.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672325 Bug ID: 1672325 Summary: perl-XML-Feed-0.56 is available Product: Fedora Version: rawhide Status: NEW Component: perl-XML-Feed Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.56 Current version/release in rawhide: 0.55-1.fc30 URL: http://search.cpan.org/dist/XML-Feed 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/8396/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Retire YUM 3
On 2/1/19 10:23 AM, Neal Gompa wrote: > On Fri, Feb 1, 2019 at 10:23 AM Sérgio Basto wrote: >> >> koji-builder, mash and repoview are ready to work without yum ? >> > > There's a pending PR for fixing koji-builder: > https://pagure.io/koji/pull-request/1117 > > Mash is dead and not used in infra anymore, so it doesn't matter. > What's the replacement? -- Mátyás (Mat) Selmeci Open Science Grid Software Team / Center for High-Throughput Computing University of Wisconsin-Madison Department of Computer Sciences ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Rawhide-20190204.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 9 of 47 required tests failed, 12 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 23/132 (x86_64), 4/24 (i386), 1/2 (arm) New failures (same test not failed in Rawhide-20190203.n.0): ID: 349307 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/349307 ID: 349322 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/349322 ID: 349324 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/349324 Old failures (same test failed in Rawhide-20190203.n.0): ID: 349285 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/349285 ID: 349289 Test: x86_64 Server-dvd-iso server_role_deploy_database_server **GATING** URL: https://openqa.fedoraproject.org/tests/349289 ID: 349290 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/349290 ID: 349291 Test: x86_64 Server-dvd-iso server_database_client **GATING** URL: https://openqa.fedoraproject.org/tests/349291 ID: 349295 Test: x86_64 Server-dvd-iso server_firewall_default **GATING** URL: https://openqa.fedoraproject.org/tests/349295 ID: 349300 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/349300 ID: 349301 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/349301 ID: 349327 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/349327 ID: 349328 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/349328 ID: 349336 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/349336 ID: 349340 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/349340 ID: 349341 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/349341 ID: 349349 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/349349 ID: 349350 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/349350 ID: 349351 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/349351 ID: 349352 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/349352 ID: 349356 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/349356 ID: 349369 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/349369 ID: 349380 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/349380 ID: 349384 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/349384 ID: 349385 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/349385 ID: 349403 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/349403 ID: 349413 Test: x86_64 universal install_kickstart_firewall_configured **GATING** URL: https://openqa.fedoraproject.org/tests/349413 ID: 349417 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/349417 ID: 349432 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/349432 Soft failed openQA tests: 4/24 (i386), 1/132 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Rawhide-20190203.n.0): ID: 349302 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/349302 ID: 349303 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/349303 ID: 349320 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/349320 ID: 349325 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/349325 ID: 349416 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/349416 Passed openQA tests: 84/132 (x86_64), 16/24 (i386) New passes (same test not passed in Rawhide-20190203.n.0): ID: 349280 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/349280 ID: 349281 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/349281 ID: 349283 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/349283 ID:
Fedora rawhide compose report: 20190204.n.0 changes
OLD: Fedora-Rawhide-20190203.n.0 NEW: Fedora-Rawhide-20190204.n.0 = SUMMARY = Added images:0 Dropped images: 2 Added packages: 2 Dropped packages:0 Upgraded packages: 63 Downgraded packages: 0 Size of added packages: 3.94 MiB Size of dropped packages:0 B Size of upgraded packages: 1.87 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 123.96 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: AtomicHost qcow2 aarch64 Path: AtomicHost/aarch64/images/Fedora-AtomicHost-Rawhide-20190203.n.0.aarch64.qcow2 Image: AtomicHost raw-xz aarch64 Path: AtomicHost/aarch64/images/Fedora-AtomicHost-Rawhide-20190203.n.0.aarch64.raw.xz = ADDED PACKAGES = Package: libgit2-0.28.0~rc1-1.module_f30+2779+95580c6b Summary: C implementation of the Git core methods as a library with a solid API RPMs:libgit2 libgit2-devel Size:3.91 MiB Package: python-flask-cors-3.0.7-1.fc30 Summary: Cross Origin Resource Sharing (CORS) support for Flask RPMs:python3-flask-cors Size:29.62 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Agda-2.5.3-15.fc30 Old package: Agda-2.5.3-14.fc29 Summary: A dependently typed functional programming language and proof assistant RPMs: Agda ghc-Agda ghc-Agda-devel ghc-EdisonAPI ghc-EdisonAPI-devel ghc-EdisonCore ghc-EdisonCore-devel ghc-geniplate-mirror ghc-geniplate-mirror-devel ghc-monadplus ghc-monadplus-devel ghc-murmur-hash ghc-murmur-hash-devel ghc-uri-encode ghc-uri-encode-devel Size: 342.69 MiB Size change: 108.93 MiB Changelog: * Thu Jan 31 2019 Fedora Release Engineering - 2.5.3-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild Package: Lmod-7.8.16-1.fc30 Old package: Lmod-7.8.9-1.fc30 Summary: Environmental Modules System in Lua RPMs: Lmod Size: 1.28 MiB Size change: 656 B Changelog: * Thu Jan 31 2019 Fedora Release Engineering - 7.8.9-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sat Feb 02 2019 Orion Poplawski - 7.8.16-1 - Update to 7.8.16 Package: appstream-generator-0.7.4-1.fc30 Old package: appstream-generator-0.6.8-1.fc29 Summary: Fast AppStream metadata generator RPMs: appstream-generator Size: 1.50 MiB Size change: 119.70 KiB Changelog: * Mon Jul 09 2018 Kalev Lember - 0.6.8-2 - Rebuilt for ldc 1.11 * Thu Jul 12 2018 Fedora Release Engineering - 0.6.8-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Thu Jan 31 2019 Fedora Release Engineering - 0.6.8-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sat Feb 02 2019 Neal Gompa - 0.7.4-1 - Rebase to 0.7.4 (#1563877) Package: cmake-3.13.4-1.fc30 Old package: cmake-3.13.3-1.fc30 Summary: Cross-platform make system RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui cmake-rpm-macros Size: 63.56 MiB Size change: 3.55 MiB Changelog: * Thu Jan 31 2019 Fedora Release Engineering - 3.13.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sat Feb 02 2019 Orion Poplawski - 3.13.4-1 - 3.13.4 Package: colobot-0.1.11.1-9.fc30 Old package: colobot-0.1.11.1-6.fc30 Summary: A video game that teaches programming in a fun way RPMs: colobot colobot-data colobot-music Size: 93.65 MiB Size change: 112.63 KiB Changelog: * Mon Nov 19 2018 Miro Hron??ok - 0.1.11.1-7 - Use python3 during build instead of python2 * Thu Jan 31 2019 Fedora Release Engineering - 0.1.11.1-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sat Feb 02 2019 Artur Iwicki - 0.1.11.1-8 - Add a patch for strncpy() usages Package: copyq-3.7.3-1.fc30 Old package: copyq-3.7.2-1.fc30 Summary: Advanced clipboard manager RPMs: copyq Size: 13.23 MiB Size change: -778.57 KiB Changelog: * Thu Jan 31 2019 Fedora Release Engineering - 3.7.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sun Feb 03 2019 Gerald Cox - 3.7.3-1 - Upstream release rhbz#1672064 Package: dokuwiki-20180422b-1.fc30 Old package: dokuwiki-20180422a-1.fc30 Summary: Standards compliant simple to use wiki RPMs: dokuwiki dokuwiki-selinux Size: 2.36 MiB Size change: 656 B Changelog: * Thu Jan 31 2019 Fedora Release Engineering - 20180422a-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sun Feb 03 2019 Artur Iwicki - 20180422b-1 - Update to new upstream bugfix release Package: dymo-cups-drivers-1.4.0.5-6.fc30 Old package: dymo-cups-drivers-1.4.0.5-4.fc30 Summary: DYMO LabelWriter Drivers for CUPS RPMs: dymo-cups-drivers Size: 1005.67 KiB Size change: 4.68 KiB Changelog: * Thu Jan 31 2019 Fedora Release Engineering - 1.4.0.5-5 - Rebuilt for https
Re: Fixing Wireguard spec file
I know what akmods are and I don't have the bandwidth on my end to switch to them with WireGuard coming in the 5.0 kernel. Joe ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1672013] perl-Module-CPANTS-Analyse-1.00 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672013 Paul Howarth changed: What|Removed |Added Depends On||1672313 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1672313 [Bug 1672313] Review Request: perl-Perl-PrereqScanner-NotQuiteLite - A tool to scan your Perl code for its prerequisites -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Help needed for FTBFS in rawhide because of libraries order
On Mon, Feb 4, 2019 at 5:44 PM Mamoru TASAKA
wrote:
> Guido Aulisi wrote on 2019/02/03 20:31:
> > Hi,
> > I'm trying to debug a FTBFS in rawhide:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
> >
> > Apparently it fails because of library ordering, but it works in f29.
> > g_object_unref is defined in gobject-2.0 and it gets surely added by
> > the 'pkgconf --libs cairo pangocairo pango' command.
> >
> > Did anything about gobject or glib change in rawhide recently?
> >
> > Thank you for any help.
> >
> > Guido
> >
> Apparently this is because rawhide pango.pc does not add -lglib-2.0
> when called with pkgconf --libs:
>
> F-29
> $ rpm -q pango
> pango-1.42.4-2.fc29.x86_64
> $ pkgconf --libs pango
> -lpango-1.0 -lgobject-2.0 -lglib-2.0
>
> F-30
> $ rpm -q pango
> pango-1.43.0-1.fc30.x86_64
> $ pkgconf --libs pango
> -lpango-1.0
>
> pango-1.43.0-1.fc30.x86_64 pango.pc shows:
> --
> Name: Pango
> Description: Internationalized text handling
> Version: 1.43.0
> Requires.private: glib-2.0 >= 2.38.0, gobject-2.0 >= 2.38.0, fribidi >=
> 0.19.7, libthai >= 0.1.9, harfbuzz >= 1.4.2, fontconfig >= 2.11.91,
> freetype2, xrender, xft >= 2.0.0, cairo >= 1.12.10
> Libs: -L${libdir} -lpango-1.0
> Libs.private: -lm
> --
> So -lglib-2.0 is moved to Requires.private.
>
> I guess this is due to this commit:
>
> https://gitlab.gnome.org/GNOME/pango/commit/86855b6a458fd9b82d246f723a7e3c9cdb37a8a0
> It seems to be doing some refactoring (with adding some fallback), and
> "requires: gobject_dep," line is deleted.
>
> Currently I am not sure if it is intentional or accidental.
>
I think this commit
https://gitlab.gnome.org/GNOME/pango/commit/d0cb6be7431d1a3c711bd45bcf05b34601604037
will revert it back but we need to wait for next upstream pango release.
Parag
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help needed for FTBFS in rawhide because of libraries order
Guido Aulisi wrote on 2019/02/04 22:23:
Il giorno lun 4 feb 2019 alle ore 13:14 Mamoru TASAKA
ha scritto:
Guido Aulisi wrote on 2019/02/03 20:31:
Hi,
I'm trying to debug a FTBFS in rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
Apparently it fails because of library ordering, but it works in f29.
g_object_unref is defined in gobject-2.0 and it gets surely added by
the 'pkgconf --libs cairo pangocairo pango' command.
Did anything about gobject or glib change in rawhide recently?
Thank you for any help.
Guido
Apparently this is because rawhide pango.pc does not add -lglib-2.0
when called with pkgconf --libs:
F-29
$ rpm -q pango
pango-1.42.4-2.fc29.x86_64
$ pkgconf --libs pango
-lpango-1.0 -lgobject-2.0 -lglib-2.0
F-30
$ rpm -q pango
pango-1.43.0-1.fc30.x86_64
$ pkgconf --libs pango
-lpango-1.0
pango-1.43.0-1.fc30.x86_64 pango.pc shows:
--
Name: Pango
Description: Internationalized text handling
Version: 1.43.0
Requires.private: glib-2.0 >= 2.38.0, gobject-2.0 >= 2.38.0, fribidi >= 0.19.7, libthai
>= 0.1.9, harfbuzz >= 1.4.2, fontconfig >= 2.11.91, freetype2, xrender, xft >= 2.0.0,
cairo >= 1.12.10
Libs: -L${libdir} -lpango-1.0
Libs.private: -lm
--
So -lglib-2.0 is moved to Requires.private.
I guess this is due to this commit:
https://gitlab.gnome.org/GNOME/pango/commit/86855b6a458fd9b82d246f723a7e3c9cdb37a8a0
It seems to be doing some refactoring (with adding some fallback), and
"requires: gobject_dep," line is deleted.
Currently I am not sure if it is intentional or accidental.
Ok, now I understand why it does not work in rawhide
Regards,
Mamoru
Thank you very much
Ciao
Guido
... And actually the above change was reverted by the following commit:
https://gitlab.gnome.org/GNOME/pango/commit/d0cb6be7431d1a3c711bd45bcf05b34601604037
i.e. gobject-2.0 got added again as Requires (non-private) for pango.pc , which
will
appear in pango-1.43.1 .
Regards,
Mamoru
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Strange rawhide behaviour
On Sun, Feb 03, 2019 at 05:27:45PM -0500, Neal Gompa wrote: > On Sat, Feb 2, 2019 at 3:51 PM Adam Williamson > wrote: > > > > On Wed, 2019-01-30 at 15:37 +0100, Michal Schorm wrote: > > > Right. > > > > > > Yes, I'm trying to test the installation from the mirrors. There will > > > be a delay. > > > > > > Buildroot repo != compose repo. > > > That's where I was mistaken. > > > > > > Case closed, I'll wait :) > > > > Just as a note, what's in the 'rawhide' repo right now differs quite a > > lot from what's in the buildroot as we haven't had a successful compose > > since 2019-01-21. This is for various reasons - most recently > > libreoffice needed rebuilding for the poppler soname bump and did not > > build successfully for nearly a week, and now lorax has a dependency > > issue. > > > > (it occurs to me to wonder whether it should be a matter of policy that > > soname rebuilds that involve libreoffice must be done in a side tag, > > but Rawhide package gating may render that concern obsolete soon). > > I would, as a matter of principle, refuse side tags as an acceptable > solution unless all packagers were given the ability to open and close > side tags freely for this purpose. Any comprehensive solution that > would permit Rawhide gating must also permit people an easy way to > submit and merge a multitude of things at once. Otherwise, we're just > screwed and everything gets harder and moves slower. :( > > As an aside, this is the first time in a while I've heard Rawhide > gating brought up. Is there a discussion somewhere about this? It's been in the air for a while and we had a concrete plan for it for a while as well but it has not been prioritised enough until basically two weeks ago. I am trying to get all the people who will be involved to review the current proposal, once it is something that I feel confident about, I'll send an email for more feedback to this list as well as submit it as a change proposal. So do expect to hear more about this before the end of the month :) If you want more info, I'm happy to provide them but I'd rather not expose this to a broad audience until there is no agreement between the different maintainers of the applications impacted by this change. I hope this makes sense. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help needed for FTBFS in rawhide because of libraries order
Il giorno lun 4 feb 2019 alle ore 13:14 Mamoru TASAKA
ha scritto:
>
> Guido Aulisi wrote on 2019/02/03 20:31:
> > Hi,
> > I'm trying to debug a FTBFS in rawhide:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
> >
> > Apparently it fails because of library ordering, but it works in f29.
> > g_object_unref is defined in gobject-2.0 and it gets surely added by
> > the 'pkgconf --libs cairo pangocairo pango' command.
> >
> > Did anything about gobject or glib change in rawhide recently?
> >
> > Thank you for any help.
> >
> > Guido
> >
> Apparently this is because rawhide pango.pc does not add -lglib-2.0
> when called with pkgconf --libs:
>
> F-29
> $ rpm -q pango
> pango-1.42.4-2.fc29.x86_64
> $ pkgconf --libs pango
> -lpango-1.0 -lgobject-2.0 -lglib-2.0
>
> F-30
> $ rpm -q pango
> pango-1.43.0-1.fc30.x86_64
> $ pkgconf --libs pango
> -lpango-1.0
>
> pango-1.43.0-1.fc30.x86_64 pango.pc shows:
> --
> Name: Pango
> Description: Internationalized text handling
> Version: 1.43.0
> Requires.private: glib-2.0 >= 2.38.0, gobject-2.0 >= 2.38.0, fribidi >=
> 0.19.7, libthai >= 0.1.9, harfbuzz >= 1.4.2, fontconfig >= 2.11.91,
> freetype2, xrender, xft >= 2.0.0, cairo >= 1.12.10
> Libs: -L${libdir} -lpango-1.0
> Libs.private: -lm
> --
> So -lglib-2.0 is moved to Requires.private.
>
> I guess this is due to this commit:
> https://gitlab.gnome.org/GNOME/pango/commit/86855b6a458fd9b82d246f723a7e3c9cdb37a8a0
> It seems to be doing some refactoring (with adding some fallback), and
> "requires: gobject_dep," line is deleted.
>
> Currently I am not sure if it is intentional or accidental.
Ok, now I understand why it does not work in rawhide
> Regards,
> Mamoru
Thank you very much
Ciao
Guido
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unannounced soname bump - libwmf-0.2.so.7 -> libwmf-0.2.so.8
02.02.2019, 15:54, "Rex Dieter" : > Rolling back is still probably the "right thing to do(tm)" Completely agree. Thanks for fixing it, Caolán! Pete ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1671825] perl-DBIx-QueryLog-0.42 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1671825 --- Comment #6 from Fedora Update System --- perl-DBIx-QueryLog-0.42-1.el7 has been pushed to the Fedora EPEL 7 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-9c5328751c -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1612875] perl-DBIx-QueryLog-0.41-8.fc28 FTBFS: Argument list too long
https://bugzilla.redhat.com/show_bug.cgi?id=1612875 --- Comment #8 from Fedora Update System --- perl-DBIx-QueryLog-0.42-1.el7 has been pushed to the Fedora EPEL 7 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-9c5328751c -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2019-02-04 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting today. Apologies for the late notice. I actually meant to run a meeting this week to finish up the topics from last week, but I'm officially on vacation right now and forgot about sending out the announcement! Sorry. I think everything on the list will keep until next week, but if you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. I'm also not expecting to run a blocker review meeting; there are only 3 proposed blockers total, so we can probably leave it another week. Thanks, everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1612875] perl-DBIx-QueryLog-0.41-8.fc28 FTBFS: Argument list too long
https://bugzilla.redhat.com/show_bug.cgi?id=1612875 --- Comment #7 from Fedora Update System --- perl-DBIx-QueryLog-0.42-1.fc29 has been pushed to the Fedora 29 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-2019-f68759670b -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1671825] perl-DBIx-QueryLog-0.42 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1671825 --- Comment #5 from Fedora Update System --- perl-DBIx-QueryLog-0.42-1.fc29 has been pushed to the Fedora 29 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-2019-f68759670b -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Is system-config-users maintained or not?
On Sat, 2019-02-02 at 09:30 +0100, Miro Hrončok wrote: > Hi, > > it seems system-config-users is broken [1], > and appears to have no upstream [2]. > > Do we maintain it at this point at all? Should it be retired "for > safety"? IIRC, Moez picked up maintenance from me long ago when I wanted to retire it. As far as I'm concerned, it can go. Moez? Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint:C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1671965] perl-Prima-1.54 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1671965 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Prima-1.54-1.fc30 Resolution|--- |RAWHIDE Last Closed||2019-02-04 11:39:33 --- Comment #1 from Petr Pisar --- An enhancement release suitable for Fedora ≥ 30. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: [HEADS UP] CMake Error: No source or binary directory provided
Actually, it seems this error was relaxed to warning in 3.13.4, which is in Rawhide since yesterday: https://github.com/Kitware/CMake/commit/2395b1b244743aaf28426a72f37d1aac96e3db9e Vít Dne 04. 02. 19 v 12:49 Vít Ondruch napsal(a): > Hi, > > It seems that since CMake 3.13, it is required to invoke the cmake > command explicitly with path to source, which was not required > previously. IOW in F29 was enough to call: > > > ~~~ > > $ cmake > > ~~~ > > > while F30+ requires: > > > ~~~ > > $ cmake . > > ~~~ > > > Unfortunately, neither upstream nor Fedora packagers perceives this > issue worth noting [1], although just during Ruby mass rebuild, I met > already quite some failing packages due to this issue. > > > Vít > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1667306#c4 > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 190 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7 173 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 47 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6fa6cebc3 game-music-emu-0.6.2-1.el7 45 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b43fdd19c3 vcftools-0.1.16-1.el7 17 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-17b3c81533 cacti-1.2.0-1.el7 cacti-spine-1.2.0-2.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5d3da674fb moodle-3.1.16-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-040983bb83 openvpn-auth-ldap-2.0.3-16.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bd6a1ae962 pdns-recursor-4.1.9-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dd9e038712 pagure-5.2-2.el7 python-amqp-2.4.0-1.el7 python-billiard-3.5.0.5-1.el7 python-celery-4.2.1-3.el7 python-kombu-4.2.2-1.el7 python-redis-2.10.6-1.el7 python-vine-1.2.0-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing perl-DBIx-QueryLog-0.42-1.el7 Details about builds: perl-DBIx-QueryLog-0.42-1.el7 (FEDORA-EPEL-2019-9c5328751c) Logging queries for DBI Update Information: 0.42 2019-02-01T17:43:24Z - Fixed t::Util problem - Fxied typo in README (fadlil++) - Fixed uuv when skip_bind(1) (Hirofumi-Narita++) ChangeLog: * Sat Feb 2 2019 Denis Fateyev - 0.42-1 - Update to 0.42 release * Fri Feb 1 2019 Fedora Release Engineering - 0.41-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Fri Jul 13 2018 Fedora Release Engineering - 0.41-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Sat Jun 30 2018 Jitka Plesnikova - 0.41-9 - Perl 5.28 rebuild * Thu Feb 8 2018 Fedora Release Engineering - 0.41-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Thu Jul 27 2017 Fedora Release Engineering - 0.41-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Tue Jun 6 2017 Jitka Plesnikova - 0.41-6 - Perl 5.26 rebuild * Wed May 24 2017 Jitka Plesnikova - 0.41-5 - Fix building on Perl without '.' in @INC * Sat Feb 11 2017 Fedora Release Engineering - 0.41-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild * Mon May 16 2016 Jitka Plesnikova - 0.41-3 - Perl 5.24 rebuild * Thu Feb 4 2016 Fedora Release Engineering - 0.41-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild References: [ 1 ] Bug #1612875 - perl-DBIx-QueryLog-0.41-8.fc28 FTBFS: Argument list too long https://bugzilla.redhat.com/show_bug.cgi?id=1612875 [ 2 ] Bug #1671825 - perl-DBIx-QueryLog-0.42 is available https://bugzilla.redhat.com/show_bug.cgi?id=1671825 ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[Bug 1612875] perl-DBIx-QueryLog-0.41-8.fc28 FTBFS: Argument list too long
https://bugzilla.redhat.com/show_bug.cgi?id=1612875 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from Fedora Update System --- perl-DBIx-QueryLog-0.42-1.fc28 has been pushed to the Fedora 28 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-2019-57384d3e2b -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1671825] perl-DBIx-QueryLog-0.42 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1671825 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-DBIx-QueryLog-0.42-1.fc28 has been pushed to the Fedora 28 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-2019-57384d3e2b -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: [HEADS UP] CMake Error: No source or binary directory provided
The most naive grep identifies at least 23 packages: ~~~ $ grep -R -e '^%cmake$' | wc -l 23 ~~~ Vít Dne 04. 02. 19 v 12:49 Vít Ondruch napsal(a): > Hi, > > It seems that since CMake 3.13, it is required to invoke the cmake > command explicitly with path to source, which was not required > previously. IOW in F29 was enough to call: > > > ~~~ > > $ cmake > > ~~~ > > > while F30+ requires: > > > ~~~ > > $ cmake . > > ~~~ > > > Unfortunately, neither upstream nor Fedora packagers perceives this > issue worth noting [1], although just during Ruby mass rebuild, I met > already quite some failing packages due to this issue. > > > Vít > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1667306#c4 > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[HEADS UP] CMake Error: No source or binary directory provided
Hi, It seems that since CMake 3.13, it is required to invoke the cmake command explicitly with path to source, which was not required previously. IOW in F29 was enough to call: ~~~ $ cmake ~~~ while F30+ requires: ~~~ $ cmake . ~~~ Unfortunately, neither upstream nor Fedora packagers perceives this issue worth noting [1], although just during Ruby mass rebuild, I met already quite some failing packages due to this issue. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=1667306#c4 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1672082] perl-Inline-0.81 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672082 --- Comment #3 from Fedora Update System --- perl-Inline-0.81-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-cbd5cb5206 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Help needed for FTBFS in rawhide because of libraries order
Guido Aulisi wrote on 2019/02/03 20:31:
Hi,
I'm trying to debug a FTBFS in rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101
Apparently it fails because of library ordering, but it works in f29.
g_object_unref is defined in gobject-2.0 and it gets surely added by
the 'pkgconf --libs cairo pangocairo pango' command.
Did anything about gobject or glib change in rawhide recently?
Thank you for any help.
Guido
Apparently this is because rawhide pango.pc does not add -lglib-2.0
when called with pkgconf --libs:
F-29
$ rpm -q pango
pango-1.42.4-2.fc29.x86_64
$ pkgconf --libs pango
-lpango-1.0 -lgobject-2.0 -lglib-2.0
F-30
$ rpm -q pango
pango-1.43.0-1.fc30.x86_64
$ pkgconf --libs pango
-lpango-1.0
pango-1.43.0-1.fc30.x86_64 pango.pc shows:
--
Name: Pango
Description: Internationalized text handling
Version: 1.43.0
Requires.private: glib-2.0 >= 2.38.0, gobject-2.0 >= 2.38.0, fribidi >= 0.19.7, libthai
>= 0.1.9, harfbuzz >= 1.4.2, fontconfig >= 2.11.91, freetype2, xrender, xft >= 2.0.0,
cairo >= 1.12.10
Libs: -L${libdir} -lpango-1.0
Libs.private: -lm
--
So -lglib-2.0 is moved to Requires.private.
I guess this is due to this commit:
https://gitlab.gnome.org/GNOME/pango/commit/86855b6a458fd9b82d246f723a7e3c9cdb37a8a0
It seems to be doing some refactoring (with adding some fallback), and
"requires: gobject_dep," line is deleted.
Currently I am not sure if it is intentional or accidental.
Regards,
Mamoru
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1672088] perl-Mojolicious version clash with perl-IO-Socket-SSL
https://bugzilla.redhat.com/show_bug.cgi?id=1672088 Petr Pisar changed: What|Removed |Added CC||ppi...@redhat.com --- Comment #1 from Petr Pisar --- The only relevant change in IO::Socket::SSL 2.009 is ALPN support. Indeed Mojo/IOLoop/TLS.pm sets SSL_alpn_protocols attribute, but I cannot see a reason why Mojolicious could not work without ALPN. At the end it's only a hint to clients and Mojolicous has to check what requests clients send to it regardless what it advertised in the ALPN. Moreover a proper way of checking ALPN support is calling IO::Socket::SSL->can_alpn(), not comparing IO::Socket::SSL module version. I believe the IO::Socket::SSL version check should be removed from the Mojolious code. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1672082] perl-Inline-0.81 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672082 --- Comment #2 from Fedora Update System --- perl-Inline-0.81-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a01e1d8e4f -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1672082] perl-Inline-0.81 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1672082 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Inline-0.81-1.fc30 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for all Fedoras. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: MBI (Playground 2.0)
On Sun, 3 Feb 2019 at 16:43, Neal Gompa wrote: > > On Sun, Feb 3, 2019 at 6:19 AM Miroslav Suchý wrote: > > > > Dne 01. 02. 19 v 13:21 Mikolaj Izdebski napsal(a): > > > - builds failing due to failure to download packages from official > > > Fedora mirror dl.fedoraproject.org > > > > This is not first time I hear this. So I will open discussion to (again) > > alter builder's mock config to point to PHX > > location, which is just rack away. > > So problem 1 is that dl.fedoraproject.org is 1 rack away. There is some sort of problem with the setup of the dl servers which is no longer using memory efficiently. I think it needs a local varnish or similar caching server but i haven't had time to analyze. > > Wouldn't it make sense to maintain a local mirror of the distributions > enabled in COPR and just have all the mock configs point to that? That > eliminates all the network pressure and the issues we keep seeing > there when trying to use it. > COPR doesn't have the disk space to mirror all that at speed. [Yes you can cheaply stick them on slow large drives but trying to run the several dozen builders would be worse than going across the rack to the other network server. So you then need a lot of slow large drives and then you are no longer cheap and it seems like you have a lot of empty disk space that isn't being used so you might as well go with smaller expensive SAS/SSD. ] > > Would it be possible to extend COPR to support multiple locations for > builders? For example, in addition to an OpenStack system, builders > could be hosted on an oVirt system, or AWS, or GCP, and so on? That > way it can support on-premise deployments and cloudy deployments too. > I expect it is possible but it is going to come down to a credential/funding problem. Going out to the cloud like GCP/AWS requires funding and setup to make sure that the systems aren't compromised. [We have had several cloud offers from smaller vendors but they then wanted our root password and other credentials.. just to remind you that this isn't your hardware and they can look in it any time you want.] There would also be the speed issue of getting the data from the on-premise to the cloud. That takes time and sometimes seems to take longer than waiting in queue locally. Then there is the mirroring part of the data. [That seems to be slower than molasses at times on the order of a day. I expect it is partially that we are doing something naive and would be better dealt with elsewhere.] > Perhaps supporting even some limited form of auto-scaling for when it > needs to "burst" to support more build traffic using clouds or > hypervisors? For example, you could use AWS spot instances to do it on > the cheap for the time a builder needs to run, and then have it go > away afterward. I've done builds this way with buildbot and you can do > thousands of builds for really cheap (on the order of hundreds of > dollars each year). > That would be useful. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help needed for FTBFS in rawhide because of libraries order
Hello, Guido Aulisi. Mon, 4 Feb 2019 09:48:40 +0100 you wrote: > I don't want to modify or patch upstream's Makefile... Why? Patching of Makefile/cmake manifests is fine. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help needed for FTBFS in rawhide because of libraries order
Il giorno dom 3 feb 2019 alle ore 23:17 Kalev Lember ha scritto: > > > On 2/3/19 12:31, Guido Aulisi wrote: > > Hi, > > I'm trying to debug a FTBFS in rawhide: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32412101 > > > > Apparently it fails because of library ordering, but it works in f29. > > g_object_unref is defined in gobject-2.0 and it gets surely added by > > the 'pkgconf --libs cairo pangocairo pango' command. > > > > Did anything about gobject or glib change in rawhide recently? > > > > Thank you for any help. > > Not sure what changed, but if you are using a symbol from a library, the > right thing to do is to list it in the 'pkgconf --libs' line so that you > can be sure that you are linking against it and not relying on another > library pulling it in. > > Just add gobject-2.0 to the 'pkgconf --libs' line and that should fix > the issue you are seeing, hopefully. Thank you for your suggestion, I added -lgobject-2.0 -lglib-2.0 to LDFLAGS and the build was ok. I don't want to modify or patch upstream's Makefile... > Hope this helps, > Kalev It helped for sure! I will search for root problem ASAP, I think I'll have to install a full rawhide system to do that. Ciao Guido ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] 50198 - fix container integration and testing issues
https://pagure.io/389-ds-base/pull-request/50198 — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
