Fedora-Cloud-30-20200210.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: g++ 10: static declared in extern "C" inline function
Iñaki Ucar writes:
On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik wrote:
>
> Iñaki Ucar writes:
>
> > Thoughts?
> >
> > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
>
> I managed to find the part of the C++ standard that specified the semantics
> of extern "C" linkage, it is [dcl.link]. The term used is "language
linkage".
>
> There is no such thing as an inline function in C. That code compiles C++
> code with C language linkage.
>
> Reading the C++ standard,, all that the standard seems to specify is
> language linkage of declarations. Quoting:
>
> # Every implementation shall provide for linkage to functions written in
the C
> # programming language, "C", and linkage to C ++ functions, "C++".
> #
> # [ Example:
> # complex sqrt(complex);
> # // C++ linkage by default
> # extern "C" {
> # double sqrt(double);
> # // C linkage
> # }
> # — end example ]
>
> The standard does not seem to specify the definitions of functions inside
> a language linkage specification. Either that is unspecified and therefore
> is a compiler extension; or it is clear that the only thing that belongs
> inside extern "C" is C code, and there's no such thing as inline functions
> in C, so declaring C++ code with C linkage would also be considered a
> compiler extension.
>
> This code compiles in gcc 9, but not in gcc 10. That's life, for compiler
> extensions.
So, summing up, nothing wrong with that code according to the
standard. Therefore, since this is a regression that breaks previous
behaviour, I'd say this is a bug in gcc, right?
No, exactly the opposite. As I wrote:
> Reading the C++ standard,, all that the standard seems to specify is
> language linkage of declarations.
The code that fails to compile is not a declaration. It defines an inline
C++ function. I find nothing in C++ standard that specifies function
definitions inside linkage specifications.
This is a declaration:
void foo();
This is a definition:
void bar()
{
}
pgpmQbf8EyTMR.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2020-02-10 - 96% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/10/report-389-ds-base-1.4.3.2-20200210git827c97d.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 544 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 286 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 284 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a1efc409a pure-ftpd-1.0.47-3.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ebd7293594 python-pip-epel-8.1.2-12.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-453d58e60f radare2-4.2.1-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-062fed623d php-horde-Horde-Data-2.1.5-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing spacenavd-0.7.1-1.el7 Details about builds: spacenavd-0.7.1-1.el7 (FEDORA-EPEL-2020-efe7e710f6) A free, compatible alternative for 3Dconnexion's input drivers Update Information: Bugfix release 0.7.1 fixed build on gcc 10 fixed configure script which failed to detect the version number correctly in release 0.7, incorrectly trying to rely on git to do so. Release 0.7 changelog: implemented the ability to log to syslog. ignore joystick devices when searching for USB devices (linux). added code to attempt to wrestle devices from the X server. added the new 3Dconnexion vendor id to the device matching logic. made builds reproducible by linking in alphabetical order. added option led = auto, to turn the LED on only when a client connects (linux). implemented a blacklist of USB device ids that should be ignored. ChangeLog: * Fri Feb 7 2020 Richard Shaw - 0.7.1-1 - Update to 0.7.1. * Thu Jan 30 2020 Fedora Release Engineering - 0.6-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Fri Jul 26 2019 Fedora Release Engineering - 0.6-10 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild * Sun Feb 3 2019 Fedora Release Engineering - 0.6-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild * Sat Jul 14 2018 Fedora Release Engineering - 0.6-8 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild * Fri Feb 9 2018 Fedora Release Engineering - 0.6-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild * Thu Aug 3 2017 Fedora Release Engineering - 0.6-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild * Thu Jul 27 2017 Fedora Release Engineering - 0.6-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild * Sat Feb 11 2017 Fedora Release Engineering - 0.6-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild * Fri Feb 5 2016 Fedora Release Engineering - 0.6-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild * Fri Jun 19 2015 Fedora Release Engineering - 0.6-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[Bug 1797154] perl-Modern-Perl-1.20200201 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1797154 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc32 |-1.fc32 |perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc31 |-1.fc31 ||perl-Modern-Perl-1.20200201 ||-1.fc30 --- Comment #11 from Fedora Update System --- perl-Modern-Perl-1.20200201-1.fc30 has been pushed to the Fedora 30 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2020-02-10 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting for tomorrow. We met the last few weeks and I don't think we have any urgent business this week. There will be a blocker review meeting. 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. Thanks! -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] 2020-02-10 @ 17:00 UTC - Fedora 32 Blocker Review Meeting
# F32 Blocker Review meeting # Date: 2020-02-10 # Time: 17:00 UTC # Location: #fedora-blocker-review on irc.freenode.net Hi folks! We have 1 proposed Beta blocker and 2 proposed Final blockers to review, so let's have a Fedora 32 blocker review meeting tomorrow! If you have time today, you can take a look at the proposed or accepted blockers before the meeting - the full lists can be found here: https://qa.fedoraproject.org/blockerbugs/ . We'll be evaluating these bugs to see if they violate any of the Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F32 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Have a good evening and see you tomorrow! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1797154] perl-Modern-Perl-1.20200201 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1797154 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Modern-Perl-1.20200201 |perl-Modern-Perl-1.20200201 |-1.fc32 |-1.fc32 ||perl-Modern-Perl-1.20200201 ||-1.fc31 Resolution|--- |ERRATA Last Closed||2020-02-10 01:42:18 --- Comment #10 from Fedora Update System --- perl-Modern-Perl-1.20200201-1.fc31 has been pushed to the Fedora 31 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Packaging of Ansible collections
On 2/9/20 2:58 AM, Igor Gnatenko wrote:
Hello,
Did anybody had an experience of packaging Ansible collections into an RPM?
I guess if would be enough to put the files somewhere under
/usr/share/ansible, but not sure. Also I'm not sure what download URL
could be used.
It seems to me that "ansible-galaxy collection install" simply unpacks
the tarball. So, this seems reasonable to me:
Name: ansible-collection-%{namespace}-%{pkgname}
Source0:
https://galaxy.ansible.com/download/%{namespace}-%{pkgname}-%{version}.tar.gz
%install
mkdir -p
%{buildroot}%{_datadir}/ansible/collections/ansible_collections/%{namespace}/%{name}
tar xf %SOURCE0 -C
%{buildroot}%{_datadir}/ansible/collections/ansible_collections/%{namespace}/%{pkgname}
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic Signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Retired] gstreamer & gstreamer-plugins-base
On Sun, Feb 9, 2020 at 5:36 PM John M. Harris Jr wrote: > > On Friday, January 31, 2020 7:58:55 AM MST Peter Robinson wrote: > > Feankly if a proprietary piece of software hasn't migrated in 8+ years I > > would be looking for a replacement. > > Proprietary software works at the speed of eventually. This is why RHEL > maintains compat libraries going back a ridiculous amount of time, and why > RHEL 5, for example, is still used today. > At some point, someone has to push to eject button. Speaking from experience, it's rare that ISVs are willing to be proactive and move forward as the community does. The difference between FOSS ISVs and proprietary software ISVs is that the community cannot do anything to help fix software for the latter. They only move forward when forced to. I'm sorry, but it simply does not make sense to keep gstreamer0.10 in Fedora anymore. I don't say that lightly: the first package I ever contributed to Fedora was a pygtk2 application using gstreamer0.10 called oggconvert. But it is dead this days, and I retired it for Fedora 31. Nobody is caring for these things, and stuff like this is usually a source of major security issues. Even today, those people using RHEL 5 are only *now* moving to RHEL 7 because it was EOLed three years ago. Folks depending on RHEL 6 who are slow to move are starting their plans to move to RHEL 8. It is what it is. But Fedora is not RHEL. Fedora is supposed to be the place where everything happens first. And if we want RHEL releases without old, unmaintained stuff, we have to chuck it in Fedora first. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Retired] gstreamer & gstreamer-plugins-base
On Friday, January 31, 2020 7:58:55 AM MST Peter Robinson wrote: > Feankly if a proprietary piece of software hasn't migrated in 8+ years I > would be looking for a replacement. Proprietary software works at the speed of eventually. This is why RHEL maintains compat libraries going back a ridiculous amount of time, and why RHEL 5, for example, is still used today. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1800988] perl-Data-Report-1.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1800988 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Data-Report-1.001-1.fc30.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=41441847 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1800988] perl-Data-Report-1.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1800988 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1661973 --> https://bugzilla.redhat.com/attachment.cgi?id=1661973=edit [patch] Update to 1.001 (#1800988) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1800988] New: perl-Data-Report-1.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1800988 Bug ID: 1800988 Summary: perl-Data-Report-1.001 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Data-Report Keywords: FutureFeature, Triaged Assignee: jvrom...@squirrel.nl Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jvrom...@squirrel.nl, m...@v3.sk, or...@nwra.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.001 Current version/release in rawhide: 0.10-31.fc32 URL: http://search.cpan.org/dist/Data-Report/ 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/2773/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Packaging of Ansible collections
On Sun, Feb 9, 2020 at 4:59 AM Igor Gnatenko wrote: > > Hello, > > Did anybody had an experience of packaging Ansible collections into an RPM? > > I guess if would be enough to put the files somewhere under > /usr/share/ansible, but not sure. Also I'm not sure what download URL could > be used. It's a problem. Most published ansible layouts rely on local tuning of the upstream, "reference" cookbook. Even the awx build tools rely on an internal, local playbook to set up an ansible server in a docker container for the "docker compose" based setups. It's not really *friendly* to modular, static playbook setups like RPM deployments on the ansible server. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
> netcdf-java[1] uses the Gradle build system, and is required to update hdfview[2] to the latest version. Gradle, however, was retired[3] as "out of date, broken, fails to build, basically unmaintainable". Checking the build.grade file (gradle recipe filei) of netcdf-java, is it possible to build and run it with "javac" and "java" command without "gradle"? https://github.com/Unidata/netcdf-java/blob/master/build.gradle -- Jun | He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 9, 2020 at 2:09 PM Fabio Valentini wrote:
>
> On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha wrote:
> >
> > On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote:
> > > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit :
> > > >
> > > > What does it tell? To me, it says that FOSS platforms don't care
> > > > about
> > > > Java as much as they used to. We're clearly able to do stuff with Go
> > > > and Rust, which are just as "anti-distribution" as Java is (based on
> > > > what other people say).
> > >
> > > While the Go core team definitely cares little about distributions, the
> > > Go module system is enforcing similar sanity rules than us (no locked
> > > versions, semver, etc) which makes it quite a lot friendlier than Java.
> > >
> > > Any language that passed the stone age of 'it builds locally with a
> > > stash of fixed third party code of dubious origin and freshness' will
> > > be easier to distribute than Java.
>
> (snip)
>
> > Thanks for all your comments everyone. What I deduce from here is that
> > packaging and maintaining Gradle is quite a task, and it may not be
> > doable (or worth doing) with our limited resources.
>
> Yeah, I don't think gradle can be maintained as a limited-resource
> community effort ... Mikolaj is the original maintainer, and he wrote
> some documentation for how to bootstrap gradle. However, he since
> dropped all but one of his fedora packages, and the bootstrapping
> process is now outdated and does not work anymore (we tried).
>
> See: https://src.fedoraproject.org/rpms/gradle/tree/f30
>
> Additionally, gradle requires groovy to build, and groovy requires
> gradle to build, and gradle requires gradle to build. And both gradle
> and groovy are retired on f31+. So it's going to require some
> multi-step bootstrap to get anything off the ground again :(
>
> To make things even more interesting, new versions of gradle now also
> include scala and kotlin code :D
>
Do we even have recent versions of scala in Fedora? And as far as I
know, Kotlin is still not in Fedora either...
> > So, to bring the thread back to the original question: what do we do?
> >
> > - Does anyone have experience with converting Gradle based projects to
> > Maven? Can we use something like this in %prep, for example, or
> > locally generate the pom files and ship them in src.rpm?
> >
> > https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml
> > https://docs.gradle.org/current/userguide/maven_plugin.html
> >
> > - If it is possible to convert from Maven poms to Gradle build files,
> > can we do the opposite perhaps?
>
> Yes, that's possible, and in fact, that's what a few packages already
> do. For example, aqute-bnd and testng are built this way (with
> generated or hand-ported pom.xml files included as %{SOURCEX} files,
> and then used as maven input). However, this is also more or less
> preventing us from updating these packages since we didn't do this
> port and have no idea how to adapt these files for new versions.
>
> > What are our other options? (Of course, I assume bundling the Gradle
> > binary for Fedora is out.)
>
> - Option 1: Convert package build systems from gradle to maven.
> Pro: Works with current packaging tools.
> Con: might make package updates harder.
>
As I think we can see here, this option doesn't really scale well and
causes more problems than it solves.
> - Option 2: Bring back gradle, possibly in a multi-step bootstrapping
> process (like Neal outlined), with a "full-bundled" build is done
> first to get things off the ground, and after that, components can be
> de-bundled one after another.
> Pro: no changes necessary for packages built with gradle.
> Con: Lots of work packaging gradle and its ecosystem.
>
At least initially, it shouldn't be bad, and unbundling can be done
iteratively with relatively little pain. This has the benefit of
unlocking most of the JVM ecosystem for Fedora again, as Gradle has
become the most popular option for building stuff on the JVM.
> - Option 3: Retire packages requiring gradle, and ship them as flatpaks >:-D
>
I hope you're not being serious. The Java ecosystem is a lot more than
just the Eclipse IDE. There's a lot of server side software, developer
tools, web code, and desktop apps that use Java ecosystem software in
some way.
The problem is that we need to start getting people who are interested
in the JVM/Java ecosystem to come together and help reboot the Java
SIG, ideally as a cross-distro SIG like the Rust SIG is. How we get
there? I don't know.
--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
Re: Policy for non-responsive reviewers
On Sun., Feb. 9, 2020, 11:15 a.m. Jerry James, wrote: > On Sun, Feb 9, 2020 at 4:21 AM Elliott Sales de Andrade > wrote: > > Looking at policies, I see one for non-responsive maintainerw [1], but > > I don't think this really applies. There's a page about the package > > review process [2] which mentions several items about non-responsive > > *submitters*, but nothing about reviewers. There's also some mention > > of legal blockers, but not how to ping for clarification there. > > Neither the Join page [3] nor the review guidelines [4] mention > > anything about timelines. > > https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews > > I don't know why that page is so hard to find. I have to hunt around > for awhile every time I want it. Perhaps there should be a link to it > from https://fedoraproject.org/wiki/Package_Review_Process ? > Ah, thank you. Yes it would definitely be best to link it from somewhere else. Should it also be moved to policy documents at https://docs.fedoraproject.org/en-US/fesco/ (Is it a FESCo policy?) -- > Jerry James > http://www.jamezone.org/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 9, 2020 at 2:49 PM Ankur Sinha wrote:
>
> On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote:
> > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit :
> > >
> > > What does it tell? To me, it says that FOSS platforms don't care
> > > about
> > > Java as much as they used to. We're clearly able to do stuff with Go
> > > and Rust, which are just as "anti-distribution" as Java is (based on
> > > what other people say).
> >
> > While the Go core team definitely cares little about distributions, the
> > Go module system is enforcing similar sanity rules than us (no locked
> > versions, semver, etc) which makes it quite a lot friendlier than Java.
> >
> > Any language that passed the stone age of 'it builds locally with a
> > stash of fixed third party code of dubious origin and freshness' will
> > be easier to distribute than Java.
(snip)
> Thanks for all your comments everyone. What I deduce from here is that
> packaging and maintaining Gradle is quite a task, and it may not be
> doable (or worth doing) with our limited resources.
Yeah, I don't think gradle can be maintained as a limited-resource
community effort ... Mikolaj is the original maintainer, and he wrote
some documentation for how to bootstrap gradle. However, he since
dropped all but one of his fedora packages, and the bootstrapping
process is now outdated and does not work anymore (we tried).
See: https://src.fedoraproject.org/rpms/gradle/tree/f30
Additionally, gradle requires groovy to build, and groovy requires
gradle to build, and gradle requires gradle to build. And both gradle
and groovy are retired on f31+. So it's going to require some
multi-step bootstrap to get anything off the ground again :(
To make things even more interesting, new versions of gradle now also
include scala and kotlin code :D
> So, to bring the thread back to the original question: what do we do?
>
> - Does anyone have experience with converting Gradle based projects to
> Maven? Can we use something like this in %prep, for example, or
> locally generate the pom files and ship them in src.rpm?
>
> https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml
> https://docs.gradle.org/current/userguide/maven_plugin.html
>
> - If it is possible to convert from Maven poms to Gradle build files,
> can we do the opposite perhaps?
Yes, that's possible, and in fact, that's what a few packages already
do. For example, aqute-bnd and testng are built this way (with
generated or hand-ported pom.xml files included as %{SOURCEX} files,
and then used as maven input). However, this is also more or less
preventing us from updating these packages since we didn't do this
port and have no idea how to adapt these files for new versions.
> What are our other options? (Of course, I assume bundling the Gradle
> binary for Fedora is out.)
- Option 1: Convert package build systems from gradle to maven.
Pro: Works with current packaging tools.
Con: might make package updates harder.
- Option 2: Bring back gradle, possibly in a multi-step bootstrapping
process (like Neal outlined), with a "full-bundled" build is done
first to get things off the ground, and after that, components can be
de-bundled one after another.
Pro: no changes necessary for packages built with gradle.
Con: Lots of work packaging gradle and its ecosystem.
- Option 3: Retire packages requiring gradle, and ship them as flatpaks >:-D
Fabio
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: ClamAV - was Re: Question
Thanks for the info, and I'm cool with that. I only ask because freshclam issues a warning that it's out of date. Pete On 2/9/20 12:08 PM, Todd Zullinger wrote: Andrew C Aitchison wrote: On Sun, 9 Feb 2020, Pete Geenhuizen wrote: Is this the right list to ask about the status of ClamAV 0.102.1 and when it will be released? If this is not the right list please tell which list I to which I should direct this question. I don't have answers for that, but I would imagine this is the right place. FWIW, a similar question came up on the Fedora devel a few days ago, in relation to the release on 0.102.2 which fixes a DoS bug in clamd. That thread is here: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/I5MP26TOBE433G22JG5CWHKNGM74CF5U/ It was noted that the security issues fixed in 0.102.2 only affects 0.102.x and that Fedora and EPEL remain on the 0.101.x series at the moment. That may be tangential to your question about an update to the 0.102.x series in general. But if you were worried particularly because of some security vulnerabilities, it might help you rest a little easier. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Question
On Sun, 2020-02-09 at 06:19 -0500, Pete Geenhuizen wrote: > Is this the right list to ask about the status of ClamAV 0.102.1 and > when it will be released? > If this is not the right list please tell which list I to which I > should direct this question. > Thanks I'm trying to update it, but my two mates don't agree with the move from freshclam to systemd [1] will I try start shipping clamav 0.102.1 , today . [1] https://bugzilla.redhat.com/show_bug.cgi?id=1800226 > Pete > -- > Unencumbered by the thought process. > -- Click and Clack the Tappet brothers > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > ___ > epel-devel mailing list -- > epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to > epel-devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > -- Sérgio M. B. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: g++ 10: static declared in extern "C" inline function
On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik wrote:
>
> Iñaki Ucar writes:
>
> > Thoughts?
> >
> > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
>
> I managed to find the part of the C++ standard that specified the semantics
> of extern "C" linkage, it is [dcl.link]. The term used is "language linkage".
>
> There is no such thing as an inline function in C. That code compiles C++
> code with C language linkage.
>
> Reading the C++ standard,, all that the standard seems to specify is
> language linkage of declarations. Quoting:
>
> # Every implementation shall provide for linkage to functions written in the C
> # programming language, "C", and linkage to C ++ functions, "C++".
> #
> # [ Example:
> # complex sqrt(complex);
> # // C++ linkage by default
> # extern "C" {
> # double sqrt(double);
> # // C linkage
> # }
> # — end example ]
>
> The standard does not seem to specify the definitions of functions inside
> a language linkage specification. Either that is unspecified and therefore
> is a compiler extension; or it is clear that the only thing that belongs
> inside extern "C" is C code, and there's no such thing as inline functions
> in C, so declaring C++ code with C linkage would also be considered a
> compiler extension.
>
> This code compiles in gcc 9, but not in gcc 10. That's life, for compiler
> extensions.
So, summing up, nothing wrong with that code according to the
standard. Therefore, since this is a regression that breaks previous
behaviour, I'd say this is a bug in gcc, right?
Iñaki
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: ClamAV - was Re: Question
Andrew C Aitchison wrote: > On Sun, 9 Feb 2020, Pete Geenhuizen wrote: > >> Is this the right list to ask about the status of ClamAV 0.102.1 and >> when it will be released? >> If this is not the right list please tell which list I to which I >> should direct this question. > > I don't have answers for that, but I would imagine this is the right place. FWIW, a similar question came up on the Fedora devel a few days ago, in relation to the release on 0.102.2 which fixes a DoS bug in clamd. That thread is here: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/I5MP26TOBE433G22JG5CWHKNGM74CF5U/ It was noted that the security issues fixed in 0.102.2 only affects 0.102.x and that Fedora and EPEL remain on the 0.101.x series at the moment. That may be tangential to your question about an update to the 0.102.x series in general. But if you were worried particularly because of some security vulnerabilities, it might help you rest a little easier. -- Todd signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 9, 2020 at 8:49 AM Ankur Sinha wrote: > > On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote: > > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > > > > > What does it tell? To me, it says that FOSS platforms don't care > > > about > > > Java as much as they used to. We're clearly able to do stuff with Go > > > and Rust, which are just as "anti-distribution" as Java is (based on > > > what other people say). > > > > While the Go core team definitely cares little about distributions, the > > Go module system is enforcing similar sanity rules than us (no locked > > versions, semver, etc) which makes it quite a lot friendlier than Java. > > > > Any language that passed the stone age of 'it builds locally with a > > stash of fixed third party code of dubious origin and freshness' will > > be easier to distribute than Java. > > Thanks for all your comments everyone. What I deduce from here is that > packaging and maintaining Gradle is quite a task, and it may not be > doable (or worth doing) with our limited resources. > > So, to bring the thread back to the original question: what do we do? > > - Does anyone have experience with converting Gradle based projects to > Maven? Can we use something like this in %prep, for example, or > locally generate the pom files and ship them in src.rpm? > > https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml > https://docs.gradle.org/current/userguide/maven_plugin.html > > - If it is possible to convert from Maven poms to Gradle build files, > can we do the opposite perhaps? > > What are our other options? (Of course, I assume bundling the Gradle > binary for Fedora is out.) > One way to bootstrap getting Gradle back in Fedora is to have it packaged with a vendored set of source dependencies, and build everything from source that way. That'll make each gradle package build quite slow, but at least packaging the dependencies can be done iteratively rather than all at once. This is essentially the approach that was done for Go and some "special" Python applications. As the Fedora guidelines allow bundling provided the spec has versioned bundled() Provides, this is the fastest, most-compliant approach. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for non-responsive reviewers
On Sun, Feb 9, 2020 at 5:15 PM Jerry James wrote: > > On Sun, Feb 9, 2020 at 4:21 AM Elliott Sales de Andrade > wrote: > > Looking at policies, I see one for non-responsive maintainerw [1], but > > I don't think this really applies. There's a page about the package > > review process [2] which mentions several items about non-responsive > > *submitters*, but nothing about reviewers. There's also some mention > > of legal blockers, but not how to ping for clarification there. > > Neither the Join page [3] nor the review guidelines [4] mention > > anything about timelines. > > https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews > > I don't know why that page is so hard to find. I have to hunt around > for awhile every time I want it. Perhaps there should be a link to it > from https://fedoraproject.org/wiki/Package_Review_Process ? Yes please, around "You should fix any blockers that the reviewer identifies.". Can you add the link? François > -- > Jerry James > http://www.jamezone.org/ > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for non-responsive reviewers
On Sun, Feb 9, 2020 at 4:21 AM Elliott Sales de Andrade wrote: > Looking at policies, I see one for non-responsive maintainerw [1], but > I don't think this really applies. There's a page about the package > review process [2] which mentions several items about non-responsive > *submitters*, but nothing about reviewers. There's also some mention > of legal blockers, but not how to ping for clarification there. > Neither the Join page [3] nor the review guidelines [4] mention > anything about timelines. https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews I don't know why that page is so hard to find. I have to hunt around for awhile every time I want it. Perhaps there should be a link to it from https://fedoraproject.org/wiki/Package_Review_Process ? -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1800973] New: perl-Test-Smoke-1.74 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1800973 Bug ID: 1800973 Summary: perl-Test-Smoke-1.74 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Smoke Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.74 Current version/release in rawhide: 1.73-2.fc32 URL: http://search.cpan.org/dist/Test-Smoke/ 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/3418/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora rawhide compose report: 20200209.n.0 changes
OLD: Fedora-Rawhide-20200207.n.2 NEW: Fedora-Rawhide-20200209.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 8 Dropped packages:7 Upgraded packages: 62 Downgraded packages: 0 Size of added packages: 9.91 MiB Size of dropped packages:5.15 MiB Size of upgraded packages: 2.90 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 122.02 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: antlr4-project-4.8-1.fc32 Summary: Parser generator (ANother Tool for Language Recognition) RPMs:antlr4 antlr4-cpp-runtime antlr4-cpp-runtime-devel antlr4-doc antlr4-javadoc antlr4-maven-plugin antlr4-runtime antlr4-runtime-test-annotation-processors antlr4-runtime-test-annotations golang-antlr4-runtime-devel mono-antlr4-runtime python3-antlr4-runtime swift-antlr4-runtime Size:9.74 MiB Package: python-textparser-0.23.0-2.fc32 Summary: Python text parser RPMs:python3-textparser Size:22.29 KiB Package: rust-dissimilar-1.0.1-1.fc32 Summary: Diff library with semantic cleanup, based on Google's diff-match-patch RPMs:rust-dissimilar+default-devel rust-dissimilar-devel Size:40.02 KiB Package: rust-retry-1.0.0-1.fc32 Summary: Utilities for retrying operations that can fail RPMs:rust-retry+default-devel rust-retry-devel Size:22.47 KiB Package: rust-rustyline-derive-0.3.0-1.fc32 Summary: Rustyline derive macros (Completer, Helper, Hinter, Highlighter) RPMs:rust-rustyline-derive+default-devel rust-rustyline-derive-devel Size:15.94 KiB Package: rust-serde_repr-0.1.5-1.fc32 Summary: Derive Serialize and Deserialize for C-like enums RPMs:rust-serde_repr+default-devel rust-serde_repr-devel Size:25.95 KiB Package: rust-serde_url_params-0.2.0-1.fc32 Summary: URL parameters serialization RPMs:rust-serde_url_params+default-devel rust-serde_url_params-devel Size:25.75 KiB Package: rust-tower-service-0.3.0-1.fc32 Summary: Asynchronous, request / response based, client or server trait RPMs:rust-tower-service+default-devel rust-tower-service-devel Size:20.34 KiB = DROPPED PACKAGES = Package: antlr4-4.5.2-8.fc31 Summary: Java parser generator RPMs:antlr4 antlr4-javadoc antlr4-maven-plugin antlr4-runtime Size:1.78 MiB Package: ndoutils-2.1.2-10.fc32 Summary: Stores all configuration and event data from Nagios in a database RPMs:ndoutils Size:1.97 MiB Package: planner2html-1.0.1-17.fc31 Summary: Convert planner files to html RPMs:planner2html Size:97.58 KiB Package: quassel-irssi-0-11.20171203git079be66.fc31 Summary: An irssi plugin to connect to quassel core RPMs:quassel-irssi Size:206.82 KiB Package: quasselc-0-10.20170111gita0a1e6b.fc32 Summary: API to access a Quassel Core in pure C RPMs:quasselc quasselc-devel Size:217.37 KiB Package: sound-theme-acoustic-1.0-15.fc32 Summary: Sound theme made on an acoustic guitar RPMs:sound-theme-acoustic Size:202.00 KiB Package: tudu-0.9.1-15.fc32 Summary: A simple, command line interface to do list application RPMs:tudu Size:709.32 KiB = UPGRADED PACKAGES = Package: asdcplib-2.10.34-1.fc32 Old package: asdcplib-2.10.32-6.fc32 Summary: AS-DCP file access libraries RPMs: asdcplib asdcplib-devel asdcplib-tools Size: 3.09 MiB Size change: 1.13 KiB Changelog: * Sat Feb 08 2020 Simone Caronni - 2.10.34-1 - Update to 2.10.34. Package: bes-3.20.6-1.fc32 Old package: bes-3.20.5-3.fc32 Summary: Back-end server software framework for OPeNDAP RPMs: bes bes-devel bes-doc Size: 316.70 MiB Size change: 5.53 MiB Changelog: * Sat Feb 08 2020 Orion Poplawski - 3.20.6-1 - Update to 3.20.6 Package: buildah-1.14.0-0.31.dev.git82ff48a.fc32 Old package: buildah-1.14.0-0.30.dev.git0a063c4.fc32 Summary: A command line tool used for creating OCI Images RPMs: buildah buildah-tests Size: 86.70 MiB Size change: 47.84 KiB Changelog: * Wed Jan 29 2020 RH Container Bot - 1.14.0-0.31.dev.git82ff48a - autobuilt 82ff48a Package: cataclysm-dda-0.D.10304-1.20200207gite7271b0.fc32 Old package: cataclysm-dda-0.D.10280-1.20200131gitbab7781.fc32 Summary: Turn-based survival game set in a post-apocalyptic world RPMs: cataclysm-dda cataclysm-dda-data cataclysm-dda-tiles cataclysm-dda-tiles-data Size: 66.70 MiB Size change: 1.69 MiB Changelog: * Fri Feb 07 2020 Artem Polishchuk - 0.D.10304-1.20200207gite7271b0 - Update to 10304 Package: ccdciel-0.9.68-2.fc32 Old package: ccdciel-0.9.65-1.fc32 Summary: CCD capture software RPMs: ccdciel Size: 25.69 MiB Size change: 8.94 MiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 0.9.65-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sat Feb 01 2020 Mattia Verga - 0.9.68-1 - Update
Fedora-Rawhide-20200209.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 25 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 99/169 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200207.n.2): ID: 518918 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/518918 ID: 518955 Test: x86_64 universal install_pxeboot URL: https://openqa.fedoraproject.org/tests/518955 Old failures (same test failed in Fedora-Rawhide-20200207.n.2): ID: 518797 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/518797 ID: 518798 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518798 ID: 518800 Test: x86_64 Server-dvd-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/518800 ID: 518805 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518805 ID: 518810 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/518810 ID: 518811 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/518811 ID: 518812 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/518812 ID: 518813 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/518813 ID: 518814 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/518814 ID: 518822 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/518822 ID: 518827 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/518827 ID: 518830 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/518830 ID: 518837 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518837 ID: 518838 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/518838 ID: 518839 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518839 ID: 518840 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/518840 ID: 518841 Test: x86_64 Workstation-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/518841 ID: 518856 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/518856 ID: 518861 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/518861 ID: 518865 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/518865 ID: 518867 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/518867 ID: 518874 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/518874 ID: 518876 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/518876 ID: 518877 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/518877 ID: 51 Test: x86_64 universal install_multi **GATING** URL: https://openqa.fedoraproject.org/tests/51 ID: 518889 Test: x86_64 universal install_repository_http_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/518889 ID: 518890 Test: x86_64 universal install_blivet_xfs URL: https://openqa.fedoraproject.org/tests/518890 ID: 518891 Test: x86_64 universal install_kickstart_firewall_configured **GATING** URL: https://openqa.fedoraproject.org/tests/518891 ID: 518892 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/518892 ID: 518893 Test: x86_64 universal install_repository_http_variation **GATING** URL: https://openqa.fedoraproject.org/tests/518893 ID: 518894 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/518894 ID: 518895 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/518895 ID: 518896 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/518896 ID: 518898 Test: x86_64 universal install_anaconda_text **GATING** URL: https://openqa.fedoraproject.org/tests/518898 ID: 518899 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/518899 ID: 518900 Test: x86_64
Re: Package uses Gradle (retired) to build: what to do?
On Sun, Feb 09, 2020 10:30:41 +0100, Nicolas Mailhot via devel wrote: > Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > > > What does it tell? To me, it says that FOSS platforms don't care > > about > > Java as much as they used to. We're clearly able to do stuff with Go > > and Rust, which are just as "anti-distribution" as Java is (based on > > what other people say). > > While the Go core team definitely cares little about distributions, the > Go module system is enforcing similar sanity rules than us (no locked > versions, semver, etc) which makes it quite a lot friendlier than Java. > > Any language that passed the stone age of 'it builds locally with a > stash of fixed third party code of dubious origin and freshness' will > be easier to distribute than Java. Thanks for all your comments everyone. What I deduce from here is that packaging and maintaining Gradle is quite a task, and it may not be doable (or worth doing) with our limited resources. So, to bring the thread back to the original question: what do we do? - Does anyone have experience with converting Gradle based projects to Maven? Can we use something like this in %prep, for example, or locally generate the pom files and ship them in src.rpm? https://stackoverflow.com/questions/12888490/gradle-build-gradle-to-maven-pom-xml https://docs.gradle.org/current/userguide/maven_plugin.html - If it is possible to convert from Maven poms to Gradle build files, can we do the opposite perhaps? What are our other options? (Of course, I assume bundling the Gradle binary for Fedora is out.) -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: g++ 10: static declared in extern "C" inline function
Iñaki Ucar writes:
Thoughts?
[1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
I managed to find the part of the C++ standard that specified the semantics
of extern "C" linkage, it is [dcl.link]. The term used is "language linkage".
There is no such thing as an inline function in C. That code compiles C++
code with C language linkage.
Reading the C++ standard,, all that the standard seems to specify is
language linkage of declarations. Quoting:
# Every implementation shall provide for linkage to functions written in the C
# programming language, "C", and linkage to C ++ functions, "C++".
#
# [ Example:
# complex sqrt(complex);
# // C++ linkage by default
# extern "C" {
# double sqrt(double);
# // C linkage
# }
# — end example ]
The standard does not seem to specify the definitions of functions inside
a language linkage specification. Either that is unspecified and therefore
is a compiler extension; or it is clear that the only thing that belongs
inside extern "C" is C code, and there's no such thing as inline functions
in C, so declaring C++ code with C linkage would also be considered a
compiler extension.
This code compiles in gcc 9, but not in gcc 10. That's life, for compiler
extensions.
pgpzys8IBYkpI.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] ClamAV - was Re: Question
On Sun, 9 Feb 2020, Pete Geenhuizen wrote: Is this the right list to ask about the status of ClamAV 0.102.1 and when it will be released? If this is not the right list please tell which list I to which I should direct this question. I don't have answers for that, but I would imagine this is the right place. I note that ClamAV 0.102.2 was released on Tuesday 4 Feb. I've been trying to roll-my own for SL6, without success so far - SL7 and Centos8/EPEL8 should be easier. The on-access scanning in v0.102 works a little differently from v0.101 and needs libcurl >= 7.45 (and still needs a newer kernel than stock SL6). -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Policy for non-responsive reviewers
On Sun, Feb 9, 2020 at 6:21 AM Elliott Sales de Andrade wrote: > > Hello, > > I've been waiting almost 2 months for my reviewer to respond on my > package request. I pinged and set needinfo some time ago, but still > nothing. My package is FTBFS and FTI in F31, and I've been stuck > because of this. > > Looking at policies, I see one for non-responsive maintainerw [1], but > I don't think this really applies. There's a page about the package > review process [2] which mentions several items about non-responsive > *submitters*, but nothing about reviewers. There's also some mention > of legal blockers, but not how to ping for clarification there. > Neither the Join page [3] nor the review guidelines [4] mention > anything about timelines. > > Now I know there's no _technical_ reason why I can't un-assign a bug, > but I'd rather discuss policy here. > * Who should be pinged, needinfo'd, or otherwise contacted, and after how > long? > * If there's a legal question, who should be pinged and when? > * At what point does a packager give up and ask for another reviewer > (by setting back to NEW)? > > [1] > https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ > [2] https://fedoraproject.org/wiki/Package_Review_Process > [3] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > [4] > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ > What is the review you're waiting on? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[rpms/perl-Net-SSLeay] PR #1: Spec file cleanups: Use make_build and make_install macros
pghmcfc commented on the pull-request: `Spec file cleanups: Use make_build and make_install macros` that you are following: `` "r" missing from end of link to ExtUtils::MakeMaker tip... `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Net-SSLeay/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1800912] perl-MCE-1.866 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1800912 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-MCE-1.866-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-02-09 11:32:10 --- Comment #1 from Paul Howarth --- Rawhide build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=41439230 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
g++ 10: static declared in extern "C" inline function
Hi, I've stumbled upon a regression, and I'm not sure this is a gcc 10 bug or not. Consider the sample program in [1], a simplification of a real case out there [2]. It fails to compile in Fedora Rawhide with the following message: /tmp/cccbVeNV.s: Assembler messages: /tmp/cccbVeNV.s:59: Error: symbol `f' is already defined The example defines two static local pointers to a callback under the same name in two different inline functions that are not static. I'm not sure whether this is entirely correct, given that the C version (removing the extern "C" declaration) throws a warning, but still, previous versions of g++ produce prefixed static symbols that don't collide, and the compilation succeeds. Thoughts? [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c [2] https://github.com/RcppCore/RcppEigen/blob/master/inst/include/RcppEigenStubs.h -- Iñaki Úcar ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Question
Is this the right list to ask about the status of ClamAV 0.102.1 and when it will be released? If this is not the right list please tell which list I to which I should direct this question. Thanks Pete -- Unencumbered by the thought process. -- Click and Clack the Tappet brothers -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Policy for non-responsive reviewers
Hello, I've been waiting almost 2 months for my reviewer to respond on my package request. I pinged and set needinfo some time ago, but still nothing. My package is FTBFS and FTI in F31, and I've been stuck because of this. Looking at policies, I see one for non-responsive maintainerw [1], but I don't think this really applies. There's a page about the package review process [2] which mentions several items about non-responsive *submitters*, but nothing about reviewers. There's also some mention of legal blockers, but not how to ping for clarification there. Neither the Join page [3] nor the review guidelines [4] mention anything about timelines. Now I know there's no _technical_ reason why I can't un-assign a bug, but I'd rather discuss policy here. * Who should be pinged, needinfo'd, or otherwise contacted, and after how long? * If there's a legal question, who should be pinged and when? * At what point does a packager give up and ask for another reviewer (by setting back to NEW)? [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [2] https://fedoraproject.org/wiki/Package_Review_Process [3] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers [4] https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Packaging of Ansible collections
On Sun, Feb 9, 2020 at 4:59 AM Igor Gnatenko wrote: > > Hello, > > Did anybody had an experience of packaging Ansible collections into an RPM? > > I guess if would be enough to put the files somewhere under > /usr/share/ansible, but not sure. Also I'm not sure what download URL could > be used. The most recent example of this I know of is the openshift-ansible playbook package: https://github.com/openshift/openshift-ansible/blob/release-3.11/openshift-ansible.spec But we don't have any specific guidelines for packaging playbooks and roles... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Packaging of Ansible collections
Hello, Did anybody had an experience of packaging Ansible collections into an RPM? I guess if would be enough to put the files somewhere under /usr/share/ansible, but not sure. Also I'm not sure what download URL could be used. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Package uses Gradle (retired) to build: what to do?
Le samedi 08 février 2020 à 19:16 -0500, Neal Gompa a écrit : > > What does it tell? To me, it says that FOSS platforms don't care > about > Java as much as they used to. We're clearly able to do stuff with Go > and Rust, which are just as "anti-distribution" as Java is (based on > what other people say). While the Go core team definitely cares little about distributions, the Go module system is enforcing similar sanity rules than us (no locked versions, semver, etc) which makes it quite a lot friendlier than Java. Any language that passed the stone age of 'it builds locally with a stash of fixed third party code of dubious origin and freshness' will be easier to distribute than Java. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-31-20200209.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1800525] perl-SVG-TT-Graph-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1800525 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-SVG-TT-Graph-1.04-1.fc ||32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-02-09 08:52:13 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1458209 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora-Cloud-30-20200209.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
