Re: Need assistance to build luxcorerender due to boost
On 2019-03-28 12:47 p.m., Robert-André Mauchin wrote: > > > Pass the correct Python version to cmake: > > %cmake \ > -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \ > -DBOOST_ROOT=%{_prefix} \ > -DLUXRAYS_DISABLE_OPENCL=0 \ > -DPYTHON_V=%{python3_version_nodots} \ > .. Done > > > You'll need to apply the patch "use-non_native-fp_classify-for-boost-106900.patch" or the build will fail with Boost 1.69. > Unfortunately the build failed locating the boot path although it detected boost. See https://koji.fedoraproject.org/koji/taskinfo?taskID=33822386 I vainly attempted to set the boost path. Luya ___ 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: Orphaned some Java packages
On Fri, Mar 29, 2019 at 5:24 AM Mikolaj Izdebski wrote: > > On Thu, Mar 28, 2019 at 7:46 PM Christopher > wrote: > > > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski > > wrote: > > > - javapackages-tools, stream 201801 (buildroot-only module, not > > > intended to be delivered to users) > > > > How do I enable/install this module locally? It would be very helpful > > for local builds/testing, but is not available in: > > sudo dnf --releasever=30 module list > > The official, recommended way of building modules locally is "fedpkg > module-build-local". This command should take care of fetching and > installing all required dependencies specified in modulemd being > built. Therefore in this case it is enough to add dependency on > javapackages-tools and it should "just work", for both local and > remote builds. Hmm. I don't know how to do modules yet. I don't know how to create a modulemd, or where it lives, or which packages I need to put in which module, or how to name modules, or anything. I just want to install all the tools from javapackages-tools, so I can do a plain old `fedpkg local` build of my regular RPMs. I know this isn't going to work in Koji for Fedora... but it would help me, as a user of those tools, have access to them for my own RPM building purposes. > > The module is not included in any compose, therefore dnf won't be able > to find it in default repos. If you really want to install the module > on your system for some reason then you can use ODCS [1] to generate a > compose containing the module. Install ODCS client with "dnf install > odcs-client" and then request compose with "odcs create module > javapackages-tools:201801". ODCS will (usually) quickly create repo > with the module and output repo URL, which you can put in a config > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath > option. Note that contents of javapackages-tools module are not signed > and therefore you need to skip GPG verification in order to be able to > install it. It seems a bit crazy to me that we have packages built for Fedora that aren't available for users to install. Why wouldn't we make everything maximally available? I used to love Fedora, because I just play with all the bits. But now, a lot of those bits are going away... I have less to play with... and the focus seems more targeted towards Fedora's internal needs, and not Fedora's users needs. Contributing to Fedora is so much harder now. Do we have to make it harder by making certain packages unavailable to regular users (and casual packager-contributors like me)? > [1] https://pagure.io/odcs > > -- > Mikolaj Izdebski > ___ > 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
Stewardship SIG: Initial report and plans for the future
Hi everybody, It looks like the first round of orphans has been taken in by our SIG - this seemed to be a good time to do inventory and think about how to proceed. Status Report - First of all, I've written a small script [0] that produces a simple HTML page of the current status of the stewardship-SIG packager group. Pull Requests to improve the report are welcome. The current status is available at [1]. I will try to update that page regularly. Dependency Checks - Also, I've tried to run some repoqueries to determine which of our packages are leaf packages that could be retired eventually. However, running repoqueries on f29 against the rawhide repos crashed dnf for some reason ... so I can't automate that easily, yet. I've tried coming up with a repoquery call that lists all packages that (Build)Require some given argument package, which we could then use to prune the list of packages maintained by this SIG. Can somebody please sanity-check what I did here [2] and here [3]? It would be good if we had a "correct" version of those dependency checks. PRs to fix/improve those scripts are very welcome. Pagure Project -- Since I'm already talking about Pull Requests, I've created a pagure project [4] for our group, where we can have a ticketing system (for example, where change of ownership for packages or retirement of leaf packages can be tracked), and a collection of shared scripts and tools which can automate some of our recurring tasks. The three scripts I mentioned will be moved there, as well. That's all for now. Fabio [0]: https://github.com/decathorpe/miscripts/blob/master/stewardship-sig-report.py [1]: https://decathorpe.fedorapeople.org/stewardship-sig.html [2]: https://github.com/decathorpe/miscripts/blob/master/whatrequires.sh [3]: https://github.com/decathorpe/miscripts/blob/master/whatbuildrequires.sh [4]: https://www.pagure.io/stewardship-sig ___ 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: Policy regarding redundant dependencies
On Wed, Mar 27, 2019 at 05:03:23PM +0100, Georg Sauthoff wrote: > On Wed, Mar 27, 2019 at 03:04:53PM +, Richard W.M. Jones wrote: > > On Tue, Mar 26, 2019 at 06:07:05PM +0100, Georg Sauthoff wrote: > > > because rpm automatically adds something like: > > > > > > libfoo.so.1()(64bit) > > > > > > Of course, I could still add a superfluous > > > > > > Requires: libfoo > > > This could pull in the 32 bit version of the package so it's wrong as > > well as redundant. (You'd want to use %{_isa} I think) > > > Is there a reason why you want to add extra Requires lines? > > I don't want to add extra Requires lines. > > On the contrary, I want to remove an extra Requires line but was > challenged by the maintainer to keep it (without providing a convincing > reason, I would say): > > https://src.fedoraproject.org/rpms/maildrop/pull-request/1 > > Thus, to finally resolve this issue I googled for the Fedora policy, > without finding the relevant section - thus I asked on this list. Oh I see, in that case you are right and the maintainer is wrong (doubly wrong in fact because the Requires line is satisfied by any architecture). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ 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: latest rubygem-puppet-lint for F29 is from F23???
On 3/29/19 2:58 PM, Vít Ondruch wrote: > Dne 29. 03. 19 v 19:47 John Florian napsal(a): >> I know it's not unusual to carry builds over from prior releases. My >> understanding is that happens because there was no mass rebuild. >> However, when I look at the F29 repo I see >> rubygem-puppet-lint-1.1.0-2.fc23.noarch.rpm. Was there really no mass >> rebuild between F23 and F29? This package is severely outdated -- >> upstream has v2.3.6 and v1.1.0 dates back to 2014. It looks like a >> build hasn't succeeded in Koji since F23. I don't know why because I >> don't see any build logs for any of these failures. I also was under >> the impression that FTBS packages like this get culled. >> >> Is my understanding buggy or did this leak through somehow? >> > You can see that all mass rebuilds failed: > > https://koji.fedoraproject.org/koji/packageinfo?packageID=14781 > > And there are several FTBFS bugs reported (including closed due to EOL): > > https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=CLOSED&component=rubygem-puppet-lint&list_id=10071090&product=Fedora&product=Fedora%20EPEL&query_format=advanced > > Looking at the logs from the oldest bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1308068 > > I guess the origin of the issues is that it does not yet use > %gem_install macro and the rubygems `--rdoc` option was deprecated > around F24 time. And it looks like the maintainer is MIA in all that time ... not a single response: https://bugzilla.redhat.com/show_bug.cgi?id=1349208 -- John Florian ___ 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: latest rubygem-puppet-lint for F29 is from F23???
Dne 29. 03. 19 v 19:47 John Florian napsal(a): > I know it's not unusual to carry builds over from prior releases. My > understanding is that happens because there was no mass rebuild. > However, when I look at the F29 repo I see > rubygem-puppet-lint-1.1.0-2.fc23.noarch.rpm. Was there really no mass > rebuild between F23 and F29? This package is severely outdated -- > upstream has v2.3.6 and v1.1.0 dates back to 2014. It looks like a > build hasn't succeeded in Koji since F23. I don't know why because I > don't see any build logs for any of these failures. I also was under > the impression that FTBS packages like this get culled. > > Is my understanding buggy or did this leak through somehow? > You can see that all mass rebuilds failed: https://koji.fedoraproject.org/koji/packageinfo?packageID=14781 And there are several FTBFS bugs reported (including closed due to EOL): https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=CLOSED&component=rubygem-puppet-lint&list_id=10071090&product=Fedora&product=Fedora%20EPEL&query_format=advanced Looking at the logs from the oldest bug: https://bugzilla.redhat.com/show_bug.cgi?id=1308068 I guess the origin of the issues is that it does not yet use %gem_install macro and the rubygems `--rdoc` option was deprecated around F24 time. Vít ___ 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
latest rubygem-puppet-lint for F29 is from F23???
I know it's not unusual to carry builds over from prior releases. My understanding is that happens because there was no mass rebuild. However, when I look at the F29 repo I see rubygem-puppet-lint-1.1.0-2.fc23.noarch.rpm. Was there really no mass rebuild between F23 and F29? This package is severely outdated -- upstream has v2.3.6 and v1.1.0 dates back to 2014. It looks like a build hasn't succeeded in Koji since F23. I don't know why because I don't see any build logs for any of these failures. I also was under the impression that FTBS packages like this get culled. Is my understanding buggy or did this leak through somehow? -- John Florian ___ 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: RPM strip scripts and executables as shared objects
On 3/29/19 1:44 PM, Josh Stone wrote: On 3/29/19 9:17 AM, Robert Marcano wrote: I have been working on a private RPM for a Rust based program Side note on this -- if you do package Rust shared libraries, not just executables, and you want them to be available for further linking, then rustc needs to have the metadata in the .rustc section. In rust.spec, I had to explicitly preserve this: %global _find_debuginfo_opts --keep-section .rustc (This is assuming you also side-step the Rust ABI question by keeping a consistent rustc version for all your shared library use.) Only using static linking (for Rust code), but this is good to know, Thanks. ___ 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: RPM strip scripts and executables as shared objects
On 3/29/19 9:17 AM, Robert Marcano wrote: > I have been working on a private RPM for a Rust based program Side note on this -- if you do package Rust shared libraries, not just executables, and you want them to be available for further linking, then rustc needs to have the metadata in the .rustc section. In rust.spec, I had to explicitly preserve this: %global _find_debuginfo_opts --keep-section .rustc (This is assuming you also side-step the Rust ABI question by keeping a consistent rustc version for all your shared library use.) ___ 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 30-20190329.n.0 compose check report
Missing expected images: Atomichost raw-xz x86_64 Atomichost qcow2 x86_64 Failed openQA tests: 7/144 (x86_64), 1/2 (arm) ID: 374065 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/374065 ID: 374077 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/374077 ID: 374098 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/374098 ID: 374100 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/374100 ID: 374111 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/374111 ID: 374128 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/374128 ID: 374142 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/374142 ID: 374159 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/374159 Soft failed openQA tests: 17/144 (x86_64), 5/23 (i386) (Tests completed, but using a workaround for a known bug) ID: 374030 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/374030 ID: 374031 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/374031 ID: 374032 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/374032 ID: 374034 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/374034 ID: 374056 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/374056 ID: 374059 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/374059 ID: 374060 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/374060 ID: 374067 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/374067 ID: 374073 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/374073 ID: 374078 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/374078 ID: 374079 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/374079 ID: 374083 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/374083 ID: 374116 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/374116 ID: 374117 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/374117 ID: 374120 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/374120 ID: 374123 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/374123 ID: 374126 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/374126 ID: 374127 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/374127 ID: 374145 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/374145 ID: 374146 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/374146 ID: 374196 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/374196 ID: 374197 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/374197 Passed openQA tests: 114/144 (x86_64), 18/23 (i386) Skipped non-gating openQA tests: 7 of 169 -- 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://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: RPM strip scripts and executables as shared objects
On 3/29/19 12:23 PM, Tom Hughes wrote: On 29/03/2019 16:17, Robert Marcano wrote: I have been working on a private RPM for a Rust based program and noticed that the RPM strip scripts are not reducing the binaries files like when I execute strip directly on those binaries. The first thing I checked is the brp-strip script. This one is filtering executables where "file" reports it is a "shared object", Rust binaries are marked as "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB executable". My understating of this after a few web searches is that this is for security features like PIE and ASLR. brp-strip-shared runs "strip --strip-unneeded" but brp-strip run "strip" (no arguments). Is there a reason why binaries marked as "ELF 64-bit LSB shared object" should not be fully stripped? Yes - read the manual page definition of --strip-unneeded and you will see: "Remove all symbols that are not needed for relocation processing." So the extra bits it leaves (which --strip removes) are the symbols needed to be able to relocate it, and shared libraries and position independent executables need to be relocated when they are loaded. In short if you use --strip you will find that you are no longer able to actually load the program or shared library. Thanks for the answer, but I don't see ls failing to load if I run --strip-all. ls is reported to be a PIE executable. From my original email, ls is still reduced when --strip-unneeded is used: 161896 ls (from Fedora RPM) 150008 ls-full (after strip) 150008 ls-unneeded (after strip --strip-unneeded) brp-strip is removing only debugging symbols for non "ELF 64-bit LSB shared object", shouldn't it be doing --strip-unneeded for those? or for all executables? "strip -g ls" removes debugging symbols for ls, that is what brp-strip does but it doesn't apply to ls because it is filtered with the "grep -v ' shared object,'" inside the script. Tom ___ 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 30 compose report: 20190329.n.0 changes
OLD: Fedora-30-20190326.n.0 NEW: Fedora-30-20190329.n.0 = SUMMARY = Added images:7 Dropped images: 2 Added packages: 0 Dropped packages:36 Upgraded packages: 4 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:1.25 GiB Size of upgraded packages: 804.48 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 237.45 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Cloud_Base vmdk s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-30-20190329.n.0.s390x.vmdk Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-30-20190329.n.0.s390x.qcow2 Image: LXQt live i386 Path: Spins/i386/iso/Fedora-LXQt-Live-i386-30-20190329.n.0.iso Image: Python_Classroom live i386 Path: Labs/i386/iso/Fedora-Python-Classroom-Live-i386-30-20190329.n.0.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-30-20190329.n.0.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-30-20190329.n.0.s390x.raw.xz Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-30-20190329.n.0.s390x.tar.xz = DROPPED IMAGES = Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-30-20190326.n.0.iso Image: KDE live i386 Path: Spins/i386/iso/Fedora-KDE-Live-i386-30-20190326.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = Package: ReviewBoard-2.5.17-17.module_1631+4353a891 Summary: Web-based code review tool RPMs:ReviewBoard Size:5.32 MiB Package: atomic-1.22.1-2.module_1816+29c6bc78 Summary: Tool for managing ProjectAtomic systems and containers RPMs:atomic atomic-registries Size:6.39 MiB Package: buildah-1.0-1.git1ab80bc.module_1816+29c6bc78 Summary: A command line tool used for creating OCI Images RPMs:buildah Size:17.14 MiB Package: container-selinux-2:2.61-1.git9b55129.module_1816+29c6bc78 Summary: SELinux policies for container runtimes RPMs:container-selinux Size:41.36 KiB Package: container-storage-setup-0.10.0-1.gitdf0dcd5.module_1816+29c6bc78 Summary: A simple service to setup container storage devices RPMs:container-storage-setup Size:37.59 KiB Package: cri-o-2:1.10.1-1.git728df92.module_1818+7c6ae394 Summary: Kubernetes Container Runtime Interface for OCI-based containers RPMs:conmon cri-o cri-o-integration-tests Size:71.73 MiB Package: cri-tools-1.0.0-5.gitf6ed14e.module_1818+7c6ae394 Summary: CLI and validation tools for Container Runtime Interface RPMs:cri-tools Size:22.13 MiB Package: docker-2:1.13.1-60.git9cb56fd.module_1641+c8c74e09 Summary: Automates deployment of containerized applications RPMs:docker docker-common docker-devel docker-fish-completion docker-logrotate docker-lvm-plugin docker-novolume-plugin docker-rhel-push-plugin docker-unit-test docker-vim docker-zsh-completion Size:349.50 MiB Package: docker-distribution-2.6.2-7.git48294d9.module_1641+02d06da9 Summary: Docker toolset to pack, ship, store, and deliver content RPMs:docker-distribution Size:21.68 MiB Package: dogtag-pki-10.6.3-1.module_1909+cebfdf1a Summary: Dogtag PKI Package RPMs:dogtag-pki dogtag-pki-console-theme dogtag-pki-server-theme Size:406.56 KiB Package: go-compilers-1-30.module_1941+86fd1e0a Summary: Go language compilers for various architectures RPMs:go-compilers-golang-compiler Size:7.85 MiB Package: go-srpm-macros-2-17.module_1941+86fd1e0a Summary: RPM macros for building Golang packages for various architectures RPMs:go-srpm-macros Size:10.54 KiB Package: golang-github-cpuguy83-go-md2man-1.0.7-6.20180307git1d903dc.module_1941+86fd1e0a Summary: Process markdown into manpages RPMs:golang-github-cpuguy83-go-md2man golang-github-cpuguy83-go-md2man-devel Size:3.71 MiB Package: golang-github-russross-blackfriday-2.0.0-2.20180628git55d61fa.module_1941+86fd1e0a Summary: Markdown processor implemented in Go RPMs:golang-github-russross-blackfriday-devel Size:58.91 KiB Package: jss-4.5.0-0.4.module_1913+819762cf Summary: Java Security Services (JSS) RPMs:jss jss-javadoc Size:9.74 MiB Package: mariadb-3:10.1.30-2.module_1690+8f54252c Summary: A community developed branch of MySQL RPMs:mariadb mariadb-common mariadb-config mariadb-connect-engine mariadb-devel mariadb-embedded mariadb-embedded-devel mariadb-errmsg mariadb-libs mariadb-oqgraph-engine mariadb-server mariadb-server-utils mariadb-test Size:363.88 MiB Package: mongo-java-driver-3.6.3-1.module_1822+9f9b01c0 Summary: A Java driver for MongoDB RPMs:mongo-java-driver mongo-java-driver-bson mongo-java-driver-driver mongo-java-driver-driver-async mongo-java-driver-driver-core mongo-java-driver-javadoc Size:6.02 MiB Package: mongo-tools-3.6.4-0.2.20180528gite657a1d.module_1806+7fc7744f Summary: MongoDB Tools RPMs:mongo-tools Size:106.93 MiB Package: mongodb-3.6.4-2.module_1831+e8c1cdcd Summary: High
Re: RPM strip scripts and executables as shared objects
On 29/03/2019 16:17, Robert Marcano wrote: I have been working on a private RPM for a Rust based program and noticed that the RPM strip scripts are not reducing the binaries files like when I execute strip directly on those binaries. The first thing I checked is the brp-strip script. This one is filtering executables where "file" reports it is a "shared object", Rust binaries are marked as "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB executable". My understating of this after a few web searches is that this is for security features like PIE and ASLR. brp-strip-shared runs "strip --strip-unneeded" but brp-strip run "strip" (no arguments). Is there a reason why binaries marked as "ELF 64-bit LSB shared object" should not be fully stripped? Yes - read the manual page definition of --strip-unneeded and you will see: "Remove all symbols that are not needed for relocation processing." So the extra bits it leaves (which --strip removes) are the symbols needed to be able to relocate it, and shared libraries and position independent executables need to be relocated when they are loaded. In short if you use --strip you will find that you are no longer able to actually load the program or shared library. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
RPM strip scripts and executables as shared objects
I have been working on a private RPM for a Rust based program and noticed that the RPM strip scripts are not reducing the binaries files like when I execute strip directly on those binaries. The first thing I checked is the brp-strip script. This one is filtering executables where "file" reports it is a "shared object", Rust binaries are marked as "ELF 64-bit LSB shared object" instead of "ELF 64-bit LSB executable". My understating of this after a few web searches is that this is for security features like PIE and ASLR. brp-strip-shared runs "strip --strip-unneeded" but brp-strip run "strip" (no arguments). Is there a reason why binaries marked as "ELF 64-bit LSB shared object" should not be fully stripped? For example "ls" can be smaller that it currently is 161896 ls (from Fedora RPM) 150008 ls-full (after strip) 150008 ls-unneeded (after strip --strip-unneeded) ___ 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
Introduction for GSoC: Koundinya
Hi everyone, My name is Venkata Rama Koundinya Lanka. I am currently pursuing my final year of engineering at Vasireddy Venkatadri Institute of Technology, Andhra Pradesh. My skills include python, Java, Android, and Machine Learning. I would like to contribute to* Fedora Gooey Karma* project for GSoC 2019. Yours Sincerely, Venkata Rama Koundinya Lanka ___ 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: Anitya not working again?
On Friday, 29 March 2019 10:33:36 CET Miro Hrončok wrote: > On 29. 03. 19 10:31, Robert-André Mauchin wrote: > > > On Friday, 29 March 2019 09:30:31 CET Michal Konecny wrote: > > > >>> > >>> > >>> > >>> Could you send me the list of projects you added? I will manually > >>> refresh them. > >> > >> > >> > >> > >> I was right, there is missing message call in API code for adding new > >> package mapping. I created issue for it here > >> https://github.com/release-monitoring/anitya/issues/760 > >> > >> > >> > >> I will fix this in future release, but for the existing projects I can > >> only refresh them manually. So if you provide me a list of projects you > >> added, I will do it. > >> > >> > >> > > > > I didn't keep a list of which one I added, or which one were already > > there. I can only give you a list of all packages which went to the > > script: > > Could you please run the script for Python packages, or share the script? > Thanks. I can't run it for Python, it is quite specific to Golang, as 99.9% of the packages use the GitHub backend. Python packages might have a more varied backend situation, some with Pypi, other Github and maybe more. I'm no Python expert, but it should be easy for you to adapt it to your situation: https://gist.github.com/eclipseo/1ee6519e6d1a9dc0ff684e333b23cd9a The script takes a folder containing Git repos as input. Ideally from a Grokmirror setup. ___ 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: Orphaned some Java packages
Hi, Mikolaj, On Fri, Mar 29, 2019 at 10:24 AM Mikolaj Izdebski wrote: > On Thu, Mar 28, 2019 at 7:46 PM Christopher > wrote: > > > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski > wrote: > > > - javapackages-tools, stream 201801 (buildroot-only module, not > > > intended to be delivered to users) > > > > How do I enable/install this module locally? It would be very helpful > > for local builds/testing, but is not available in: > > sudo dnf --releasever=30 module list > > The official, recommended way of building modules locally is "fedpkg > module-build-local". This command should take care of fetching and > installing all required dependencies specified in modulemd being > built. Therefore in this case it is enough to add dependency on > javapackages-tools and it should "just work", for both local and > remote builds. > > The module is not included in any compose, therefore dnf won't be able > to find it in default repos. if I understand correctly, you say that javapackages-tools module is not included in any Fedora Modular repositories. But you want it to be included in Fedora buildroot through Ursa Major. Can you explain why you don't make it available through a Modular repo? > If you really want to install the module > on your system for some reason then you can use ODCS [1] to generate a > compose containing the module. Install ODCS client with "dnf install > odcs-client" and then request compose with "odcs create module > javapackages-tools:201801". ODCS will (usually) quickly create repo > with the module and output repo URL, which you can put in a config > file under /etc/yum.repos.d/, or pass to dnf using --repofrompath > option. Note that contents of javapackages-tools module are not signed > and therefore you need to skip GPG verification in order to be able to > install it. > > [1] https://pagure.io/odcs > > -- > Mikolaj Izdebski > ___ > 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
Re: Orphaned some Java packages
Dne 28. 03. 19 v 14:53 Mikolaj Izdebski napsal(a): > On Thu, Mar 28, 2019 at 8:44 AM Vít Ondruch wrote: >> Trying to take look from the other side, the java.yaml might need some >> love [1], because the GH links are broken [2, 3] > java module doesn't have any complete builds. It is not actively maintained. Good to know that we have unmaintained modules in Fedora, nobody notice, nobody cares, there is no procedure how to get rid of them, etc ... Vít ___ 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: Anitya not working again?
On 29/03/19 10:31, Robert-André Mauchin wrote: On Friday, 29 March 2019 09:30:31 CET Michal Konecny wrote: Could you send me the list of projects you added? I will manually refresh them. I was right, there is missing message call in API code for adding new package mapping. I created issue for it here https://github.com/release-monitoring/anitya/issues/760 I will fix this in future release, but for the existing projects I can only refresh them manually. So if you provide me a list of projects you added, I will do it. I didn't keep a list of which one I added, or which one were already there. I can only give you a list of all packages which went to the script: golang-apache-thrift golang-bazil-fuse golang-bitbucket-kardianos-osext golang-bitbucket-ww-goautoneg golang-cloud-google golang-contrib-opencensus-exporter golang-contrib-opencensus-exporter-ocagent golang-deepin-dbus-factory golang-deepin-go-lib golang-dmitri-shuralyov-html-belt golang-dmitri-shuralyov-route-github golang-dmitri-shuralyov-state golang-etcd-bbolt golang-github-10gen-escaper golang-github-10gen-openssl golang-github-3rf-mongo-lint golang-github-a8m-tree golang-github-abbot-go-http-auth golang-github-aclements-gg golang-github-aclements-moremath golang-github-AdRoll-goamz golang-github-aead-chacha20 golang-github-aead-poly1305 golang-github-agl-ed25519 golang-github-ajstarks-svgo golang-github-akrennmair-gopcap golang-github-alcortesm-tgz golang-github-alecthomas-assert golang-github-alecthomas-chroma golang-github-alecthomas-colour golang-github-alecthomas-kingpin golang-github-alecthomas-kong golang-github-alecthomas-repr golang-github-alecthomas-template golang-github-alecthomas-units golang-github-alexcesaro-quotedprintable-v3 golang-github-anacrolix-envpprof golang-github-anacrolix-missinggo golang-github-anacrolix-tagflag golang-github-andybalholm-cascadia golang-github-anmitsu-shlex golang-github-appc-spec golang-github-armon-circbuf golang-github-armon-gomdb golang-github-armon-go-metrics golang-github-armon-go-proxyproto golang-github-armon-go-radix golang-github-asaskevich-govalidator golang-github-AudriusButkevicius-cli golang-github-AudriusButkevicius-go-nat-pmp golang-github-AudriusButkevicius-kcp-go golang-github-AudriusButkevicius-pfilter golang-github-auth0-go-jwt-middleware golang-github-aws-aws-sdk-go golang-github-axgle-mahonia golang-github-azure-autorest golang-github-Azure-azure-sdk-for-go golang-github-azure-pipeline golang-github-azure-storage-blob golang-github-beevik-ntp golang-github-benbjohnson-clock golang-github-beorn7-perks golang-github-bep-debounce golang-github-bep-gitmap golang-github-bep-inflect golang-github-bep-tocss golang-github-bgentry-go-netrc golang-github-bgentry-speakeasy golang-github-billziss-gh-cgofuse golang-github-bitly-go-simplejson golang-github-bitly-simplejson golang-github-bkaradzic-go-lz4 golang-github-blang-semver golang-github-bmizerany-assert golang-github-bmizerany-pat golang-github-bmizerany-perks golang-github-boltdb-bolt golang-github-boombuler-barcode golang-github-bradfitz-gomemcache golang-github-bradfitz-http2 golang-github-bradfitz-iter golang-github-bradfitz-smtpd golang-github-briandowns-spinner golang-github-bruth-assert golang-github-bufio-v1 golang-github-buger-jsonparser golang-github-bugsnag-bugsnag-go golang-github-bugsnag-panicwrap golang-github-BurntSushi-freetype-go golang-github-BurntSushi-graphics-go golang-github-burntsushi-locker golang-github-BurntSushi-toml golang-github-BurntSushi-toml-test golang-github-BurntSushi-xgb golang-github-BurntSushi-xgbutil golang-github-calmh-du golang-github-calmh-luhn golang-github-calmh-xdr golang-github-ccding-go-stun golang-github-cenkalti-backoff golang-github-census-instrumentation-opencensus-proto golang-github-cespare-xxhash golang-github-chaseadamsio-goorgeous golang-github-cheekybits-is golang-github-cheggaaa-pb golang-github-chmduquesne-rollinghash golang-github-chrismalek-oktasdk-go golang-github-chzyer-logex golang-github-chzyer-test golang-github-circonus-labs-circonus-gometrics golang-github-circonus-labs-circonusllhist golang-github-client9-gospell golang-github-cloudflare golang-github-cloudfoundry-incubator-candiedyaml golang-github-cockroachdb-cmux golang-github-cockroachdb-cockroach-go golang-github-codahale-aesnicheck golang-github-codahale-hdrhistogram golang-github-codegangsta-cli golang-github-codegangsta-negroni golang-github-collectd-go-collectd golang-github-coreos-bbolt golang-github-coreos-gexpect golang-github-coreos-go-etcd golang-github-coreos-go-iptables golang-github-coreos-go-log golang-github-coreos-go-oidc golang-github-coreos-go-semver golang-github-coreos-go-systemd golang-github-coreos-pkg golang-github-cosiner-argv golang-github-cosmos72-gomacro golang-github-cpu-goacmedns golang-github-cpuguy83-go-md2man golang-github-cryptix-wav golang-github-cznic-b golang-github-cznic-fileutil golang-github-cznic-golex golang-github-cznic-internal golang-github-cznic-lex golang-githu
Re: Anitya not working again?
On 29. 03. 19 10:31, Robert-André Mauchin wrote: On Friday, 29 March 2019 09:30:31 CET Michal Konecny wrote: Could you send me the list of projects you added? I will manually refresh them. I was right, there is missing message call in API code for adding new package mapping. I created issue for it here https://github.com/release-monitoring/anitya/issues/760 I will fix this in future release, but for the existing projects I can only refresh them manually. So if you provide me a list of projects you added, I will do it. I didn't keep a list of which one I added, or which one were already there. I can only give you a list of all packages which went to the script: Could you please run the script for Python packages, or share the script? Thanks. -- 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
Re: Anitya not working again?
On Friday, 29 March 2019 09:30:31 CET Michal Konecny wrote: > > > > > > Could you send me the list of projects you added? I will manually > > refresh them. > > > I was right, there is missing message call in API code for adding new > package mapping. I created issue for it here > https://github.com/release-monitoring/anitya/issues/760 > > I will fix this in future release, but for the existing projects I can > only refresh them manually. So if you provide me a list of projects you > added, I will do it. > I didn't keep a list of which one I added, or which one were already there. I can only give you a list of all packages which went to the script: golang-apache-thrift golang-bazil-fuse golang-bitbucket-kardianos-osext golang-bitbucket-ww-goautoneg golang-cloud-google golang-contrib-opencensus-exporter golang-contrib-opencensus-exporter-ocagent golang-deepin-dbus-factory golang-deepin-go-lib golang-dmitri-shuralyov-html-belt golang-dmitri-shuralyov-route-github golang-dmitri-shuralyov-state golang-etcd-bbolt golang-github-10gen-escaper golang-github-10gen-openssl golang-github-3rf-mongo-lint golang-github-a8m-tree golang-github-abbot-go-http-auth golang-github-aclements-gg golang-github-aclements-moremath golang-github-AdRoll-goamz golang-github-aead-chacha20 golang-github-aead-poly1305 golang-github-agl-ed25519 golang-github-ajstarks-svgo golang-github-akrennmair-gopcap golang-github-alcortesm-tgz golang-github-alecthomas-assert golang-github-alecthomas-chroma golang-github-alecthomas-colour golang-github-alecthomas-kingpin golang-github-alecthomas-kong golang-github-alecthomas-repr golang-github-alecthomas-template golang-github-alecthomas-units golang-github-alexcesaro-quotedprintable-v3 golang-github-anacrolix-envpprof golang-github-anacrolix-missinggo golang-github-anacrolix-tagflag golang-github-andybalholm-cascadia golang-github-anmitsu-shlex golang-github-appc-spec golang-github-armon-circbuf golang-github-armon-gomdb golang-github-armon-go-metrics golang-github-armon-go-proxyproto golang-github-armon-go-radix golang-github-asaskevich-govalidator golang-github-AudriusButkevicius-cli golang-github-AudriusButkevicius-go-nat-pmp golang-github-AudriusButkevicius-kcp-go golang-github-AudriusButkevicius-pfilter golang-github-auth0-go-jwt-middleware golang-github-aws-aws-sdk-go golang-github-axgle-mahonia golang-github-azure-autorest golang-github-Azure-azure-sdk-for-go golang-github-azure-pipeline golang-github-azure-storage-blob golang-github-beevik-ntp golang-github-benbjohnson-clock golang-github-beorn7-perks golang-github-bep-debounce golang-github-bep-gitmap golang-github-bep-inflect golang-github-bep-tocss golang-github-bgentry-go-netrc golang-github-bgentry-speakeasy golang-github-billziss-gh-cgofuse golang-github-bitly-go-simplejson golang-github-bitly-simplejson golang-github-bkaradzic-go-lz4 golang-github-blang-semver golang-github-bmizerany-assert golang-github-bmizerany-pat golang-github-bmizerany-perks golang-github-boltdb-bolt golang-github-boombuler-barcode golang-github-bradfitz-gomemcache golang-github-bradfitz-http2 golang-github-bradfitz-iter golang-github-bradfitz-smtpd golang-github-briandowns-spinner golang-github-bruth-assert golang-github-bufio-v1 golang-github-buger-jsonparser golang-github-bugsnag-bugsnag-go golang-github-bugsnag-panicwrap golang-github-BurntSushi-freetype-go golang-github-BurntSushi-graphics-go golang-github-burntsushi-locker golang-github-BurntSushi-toml golang-github-BurntSushi-toml-test golang-github-BurntSushi-xgb golang-github-BurntSushi-xgbutil golang-github-calmh-du golang-github-calmh-luhn golang-github-calmh-xdr golang-github-ccding-go-stun golang-github-cenkalti-backoff golang-github-census-instrumentation-opencensus-proto golang-github-cespare-xxhash golang-github-chaseadamsio-goorgeous golang-github-cheekybits-is golang-github-cheggaaa-pb golang-github-chmduquesne-rollinghash golang-github-chrismalek-oktasdk-go golang-github-chzyer-logex golang-github-chzyer-test golang-github-circonus-labs-circonus-gometrics golang-github-circonus-labs-circonusllhist golang-github-client9-gospell golang-github-cloudflare golang-github-cloudfoundry-incubator-candiedyaml golang-github-cockroachdb-cmux golang-github-cockroachdb-cockroach-go golang-github-codahale-aesnicheck golang-github-codahale-hdrhistogram golang-github-codegangsta-cli golang-github-codegangsta-negroni golang-github-collectd-go-collectd golang-github-coreos-bbolt golang-github-coreos-gexpect golang-github-coreos-go-etcd golang-github-coreos-go-iptables golang-github-coreos-go-log golang-github-coreos-go-oidc golang-github-coreos-go-semver golang-github-coreos-go-systemd golang-github-coreos-pkg golang-github-cosiner-argv golang-github-cosmos72-gomacro golang-github-cpu-goacmedns golang-github-cpuguy83-go-md2man golang-github-cryptix-wav golang-github-cznic-b golang-github-cznic-fileutil golang-github-cznic-golex golang-github-cznic-internal golang-github-cznic-lex golang-github-cznic-lexe
Re: Orphaned some Java packages
On Thu, Mar 28, 2019 at 7:46 PM Christopher wrote: > > On Thu, Mar 28, 2019 at 9:50 AM Mikolaj Izdebski wrote: > > - javapackages-tools, stream 201801 (buildroot-only module, not > > intended to be delivered to users) > > How do I enable/install this module locally? It would be very helpful > for local builds/testing, but is not available in: > sudo dnf --releasever=30 module list The official, recommended way of building modules locally is "fedpkg module-build-local". This command should take care of fetching and installing all required dependencies specified in modulemd being built. Therefore in this case it is enough to add dependency on javapackages-tools and it should "just work", for both local and remote builds. The module is not included in any compose, therefore dnf won't be able to find it in default repos. If you really want to install the module on your system for some reason then you can use ODCS [1] to generate a compose containing the module. Install ODCS client with "dnf install odcs-client" and then request compose with "odcs create module javapackages-tools:201801". ODCS will (usually) quickly create repo with the module and output repo URL, which you can put in a config file under /etc/yum.repos.d/, or pass to dnf using --repofrompath option. Note that contents of javapackages-tools module are not signed and therefore you need to skip GPG verification in order to be able to install it. [1] https://pagure.io/odcs -- Mikolaj Izdebski ___ 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: [stewardship-sig] Re: Announcing the Stewardship SIG: Maintenance for High-Priority orphans
On Fri, 2019-03-29 at 00:32 +0100, Miro Hrončok wrote: > On 20. 03. 19 9:57, Fabio Valentini wrote: > > I've gone ahead with my proposal and created the Stewardship SIG. > > > > This includes the SIGs/Stewardship wiki page [0], the @stewardship- > > sig > > FAS group [1], to which high-priority orphaned packages can be > > assigned, and the stewardship-sig mailing list [2]. > > ... > > [0]: https://fedoraproject.org/wiki/SIGs/Stewardship > > [1]: https://src.fedoraproject.org/group/stewardship-sig > > [2]: > > https://lists.fedoraproject.org/admin/lists/stewardship-sig.lists.fedoraproject.org > > We currently need to take: > > jansi-native, apache-commons-compress, maven-plugins-pom, bsf, joda- > convert, > apiguardian, univocity-parsers, zinc, apache-commons-collections4, > jakarta-commons-httpclient, plexus-components-pom, jetty-build- > support, > maven-compiler-plugin, jansi, javacc-maven-plugin, plexus-languages, > plexus-component-factories-pom, httpcomponents-project, batik, sisu- > mojos, > jflex, apache-commons-collections, kxml, jetty-toolchain, > apache-resource-bundles, jetty-test-helper, maven-artifact-resolver, > jdependency, objectweb-pom, jsoup, xstream, maven-mapping, geronimo- > jpa, > maven-shared-incremental, apache-commons-jexl, apache-commons- > beanutils, javacc, > xalan-j2, maven-plugin-build-helper, maven-verifier, checkstyle, > maven-script-interpreter, jetty-alpn, jaxen, maven-assembly-plugin, > maven-shared-jarsigner, dain-snappy, felix-bundlerepository, nodejs- > array-union, > apache-parent, jsch-agent-proxy, maven-shared-io, maven-shade-plugin, > bcel, > avalon-logkit, hawtjni, xbean, jna, junit5, nodejs-arrify, > apache-commons-discovery, jetty-artifact-remote-resources, > sonatype-plugins-parent, jetty-assembly-descriptors, maven- > dependency-analyzer, > avalon-framework, multiverse, maven-jarsigner-plugin, maven-invoker, > exec-maven-plugin, beust-jcommander, maven-dependency-plugin, > geronimo-jaspic-spec, xz-java, groovy, snakeyaml, gpars, jetty, > apache-commons-jxpath, jetty-schemas, felix-osgi-obr, > apache-commons-configuration, plexus-interactivity, regexp, sonatype- > oss-parent, > plexus-compiler, jetty-test-policy, glassfish-jsp-api, cal10n, > jetty-distribution-remote-resources, plexus-cli, jetty-alpn-api, > plexus-io, > maven-source-plugin, base64coder, opentest4j, munge-maven-plugin > > Later we can chop off some optional deps. > > Any takers from the SIG? I already took plenty and this just seems > like a lot. > > Thanks for help. > > https://src.fedoraproject.org/group/stewardship-sig I asked for my build dependencies that I will hopefully be able to take care of before we will find a better solution: https://pagure.io/releng/issue/8248 Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ 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: Anitya not working again?
On 29/03/19 08:40, Michal Konecny wrote: On 28/03/19 20:14, Robert-André Mauchin wrote: On Thursday, 28 March 2019 19:38:30 CET Michal Konecny wrote: I found out what is wrong, you created the project without Fedora mapping, so the first version was retrieved without knowing how this is packaged in Fedora. But I see, that the mapping was added later, but the message about the mapping wasn't send by Anitya. Did you added the mapping using API, maybe the message is not published when the mapping is changed using API? Yes I first created the project without Fedora mapping. Then added the mapping in a second time, all using the API. I can still see few golang updates coming through recently: golang-github-hashicorp-mdns - [0] golang-github-pierrec-lz4 - [1] Could you check what exactly is missing from the projects you added. You could check the latest messages from the-new-hotness in [2] [0] - https://apps.fedoraproject.org/datagrepper/id?id=2019-79474d61-c5f9-4b07-866 3-7ea15f434774&is_raw=true&size=extra-large [1] - https://apps.fedoraproject.org/datagrepper/id?id=2019-e171f618-4c2e-4a27-825 0-ebe8deec6b26&is_raw=true&size=extra-large [2] - https://apps.fedoraproject.org/datagrepper/raw?category=hotness&delta=259200 0 For my example, the message says: hotness.update.drop the-new-hotness saw an update for stats, but release- monitoring.org doesn't know what that project is called in Fedora land https://apps.fedoraproject.org/datagrepper/id?id=2019-40749965-2805-4e33-a037-cbbd4a6283bb&is_raw=true&size=extra-large Doesn't it send the notification if the mapping is added afterward? It should, but it looks like it doesn't send any if the mapping is added using API. Probably missing call to publish message in API. I will check this. Could you send me the list of projects you added? I will manually refresh them. I was right, there is missing message call in API code for adding new package mapping. I created issue for it here https://github.com/release-monitoring/anitya/issues/760 I will fix this in future release, but for the existing projects I can only refresh them manually. So if you provide me a list of projects you added, I will do it. mkonecny ___ 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 ___ 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: Anitya not working again?
On 28/03/19 20:14, Robert-André Mauchin wrote: On Thursday, 28 March 2019 19:38:30 CET Michal Konecny wrote: I found out what is wrong, you created the project without Fedora mapping, so the first version was retrieved without knowing how this is packaged in Fedora. But I see, that the mapping was added later, but the message about the mapping wasn't send by Anitya. Did you added the mapping using API, maybe the message is not published when the mapping is changed using API? Yes I first created the project without Fedora mapping. Then added the mapping in a second time, all using the API. I can still see few golang updates coming through recently: golang-github-hashicorp-mdns - [0] golang-github-pierrec-lz4 - [1] Could you check what exactly is missing from the projects you added. You could check the latest messages from the-new-hotness in [2] [0] - https://apps.fedoraproject.org/datagrepper/id?id=2019-79474d61-c5f9-4b07-866 3-7ea15f434774&is_raw=true&size=extra-large [1] - https://apps.fedoraproject.org/datagrepper/id?id=2019-e171f618-4c2e-4a27-825 0-ebe8deec6b26&is_raw=true&size=extra-large [2] - https://apps.fedoraproject.org/datagrepper/raw?category=hotness&delta=259200 0 For my example, the message says: hotness.update.drop the-new-hotness saw an update for stats, but release- monitoring.org doesn't know what that project is called in Fedora land https://apps.fedoraproject.org/datagrepper/id?id=2019-40749965-2805-4e33-a037-cbbd4a6283bb&is_raw=true&size=extra-large Doesn't it send the notification if the mapping is added afterward? It should, but it looks like it doesn't send any if the mapping is added using API. Probably missing call to publish message in API. I will check this. Could you send me the list of projects you added? I will manually refresh them. mkonecny ___ 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