Re: libvirt and systemd-resolved integration?
On Tue, Oct 06, 2020 at 10:04:19PM +0200, Juan Orti Alcaine wrote: > Hello, > > In the network bridges that libvirt creates there's a dnsmasq daemon to > resolve the VM's IPs. Is there any way to signal systemd-resolved from > libvirt to say that in the bridge interface there is a DNS server and a > domain? Related, there is nss-mymachines: https://www.freedesktop.org/software/systemd/man/nss-mymachines.html It resolves IPs of instances registered with machined. Libvirt already registers virtual machines with machined. But as I see, libvirt does not provide IP addresses during registration. Maybe this could be fixed? -- Tomasz Torcz There exists no separation between gods and men: to...@pipebreaker.pl one blends softly casual into the other. — Frank Herbert ___ 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: libvirt and systemd-resolved integration?
I don't think it's a good idea. dnsmasq is not dns resolver but acts as DHCP and DNS server. It provides VMs with IP address/lease and create corresponding dns record for it. In case of resolved ip addresses and dns records must be managed either manually or... with dnsmasq. On 2020-10-06 at 22:04 CEST, Juan Orti Alcaine wrote... Hello, In the network bridges that libvirt creates there's a dnsmasq daemon to resolve the VM's IPs. Is there any way to signal systemd-resolved from libvirt to say that in the bridge interface there is a DNS server and a domain? Thank you. ___ 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 -- Pavel ___ 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] Please Review: Template --advanced flag
https://github.com/389ds/389-ds-base/pull/4362 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia ___ 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
Re: libvirt and systemd-resolved integration?
Hm, I'm not quite sure how this is intended to work. This is for resolving VM hostnames into IP addresses? How exactly does it work prior to systemd-resolved? E.g. lets say I have a libvirt VM named "f33", should it be possible to resolve that name somehow from the host system? Can you do what you want using https://www.freedesktop.org/wiki/Software/systemd/resolved/ ? Maybe SetLinkDNS for the bridge interface? But you would also need to call SetLinkDomains to ensure queries for a particular domain go to the bridge interface (otherwise, nothing will). You could theoretically, for instance, claim a .libvirt domain, then resolve "f33.libvirt" to the VM's IP? ___ 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: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On 9/30/20 3:50 AM, Jan Kratochvil wrote: > On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote: >> But the GCC community >> doesn't really test that option and it's known to be broken with LTO. > I haven't seen any GCC PR for -fdebug-types-section being broken with LTO. I'm not aware of one either. But as Jakub has previously pointed out debug-types-section is disabled when LTO is enabled. I don't know the details of why that is done. > > During one abigail diff I did not see any difference. I plan to run a full > distribution abigail massrebuild+check as stated in the Change to exclude any > possible incompatibilities. That would discover unfiled GCC problems with > -fdebug-types-section. > > Also I do not see why fixing -fdebug-types-section should be anyhow difficult > if the compiler can produce -fno-debug-types-section. I can also write > postprocessor to get -fdebug-types-section if GCC is unable to do that. > That would sure lose the -fdebug-types-section compilation time performance > benefits. > > >> And, not surprisingly, our team has had significant input on the options >> we're using *and* the GCC implementation of those options. We make >> recommendations based on our experiences. That same experience would lead us >> to recommending against -fdebug-types-section at this time. > I think I have also some DWARF experience. Could you suggest what is wrong on > -fdebug-types-section? Your best bet is to discuss with Jakub and perhaps Jason. They're far more familiar with the debuginfo generation than I am. > > >> It would certainly be good to improve the on-disk distro size. > OK, going to file a Change to enable gcc -gz option (zlib section compression) > as that will reduce on-disk *.debug size by 52.84%! Then we can disable both > DWZ and -fdebug-types-section as those become pointless then. Note Mark's reply in the other thread. Section compression has significant tradeoffs. > > >> So the only paths forward I see are to either fix -fdebug-types-section or >> improve dwz. > And obviously much easier is to fix -fdebug-types-section than DWZ (if there > are really any bugs in -fdebug-types-section, there are known bugs nobody > wants to fix in DWZ). I think you're making an unsubstantiated leap here. Neither of us know what's wrong with GCC LTO and debug-types-section and others are working on dwz. > > >> Putting my Red Hat hat on, I get pushback from PM on *any* size increases in >> the RHEL space. > When we start talking about RHEL (and CentOS) DWZ is completely pointless then > as DWZ there saves only 0.28% of *-debuginfo.rpm (20MB of 7.2GB). > Therefore approx. 0.14% of the distribution size. Umm, we're fighting with PM these days over things in the 10M range. So, no it's not pointless. > > >> As much as we'd like to be in a world were a 1% increase in distro >> size doesn't matter, that's not the actual world we live in. > Unfortunately DWZ cannot decrease RHEL size by that 1%. I'm not asking it to. I'm saying that sizes matter, even in cases where you think they shouldn't. > > >> And our RHEL customers absolutey do care about the size of debuginfo >> becuause it affects link times. > System debuginfo format does not affect link times. Using DWZ during linking > customer's applications definitely only increases linking time as it is an > extra step. Not sure what do you talk about. Most customers don't use dwz. But they consume its output for the RPMs that we provide. Jeff ___ 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
Non-responsive maintainer check: macermak
Hi all, In accordance with [1] this is a non-responsive maintainer check for Marek Cermak / macermak. Non-responsive bug: https://bugzilla.redhat.com/show_bug.cgi?id=1885788 Unactioned bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1618559 2018-08 Does anyone know how to contact Marek? Regards, Mikel [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ ___ 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: ELF section/file compression
On 10/6/20 3:59 PM, Mark Wielaard wrote: > Hi, > > Changing subject because this has nothing to do with that Change > Proposal anymore. > > On Tue, Oct 06, 2020 at 01:49:13PM -0600, Jeff Law wrote: >> However, I think it's perfectly valid to discuss zstd if folks wanted to >> change the compression scheme for debug sections. In fact, I'd claim >> sticking with zlib, gzip, bzip2, xz, 7z, etc is unwise. The world has >> moved and zstd seems like the place we should be. In fact, we use it >> for various things within GCC already. > Personally I must admit that I am not really a fan of using ELF > section/file compression. It makes it impossible to simply mmap the > data in or to quickly read just a tiny bit because you first have to > decompress (and allocate new memory) for it. IMHO .debug files are no > different from other ELF files for which we would also not do this. We > can just use rpm package compression to reduce the distro distribution > size, but we should not (re)compress the install/on-disk files. That > will just mean programs will create an extra cache of uncompressed > files they need to consult frequently. I'm not taking a position on whether or not we compress sections. My position is that if we're compressing them, then zstd seems like a better solution than the others mentioned. I certainly understand the desire to just mmap in the stuff and move on. [ ... ] Secondly you can use ELF section compression. The ELF spec leaves room > for adding new compression algorithms. The Chdr struct(s) contain a > ch_type which describes the algorithm. Currently only one is > specified, but there is a lot of room for expansion: > > /* Legal values for ch_type (compression algorithm). */ > #define ELFCOMPRESS_ZLIB1 /* ZLIB/DEFLATE algorithm. */ > #define ELFCOMPRESS_LOOS0x6000 /* Start of OS-specific. */ > #define ELFCOMPRESS_HIOS0x6fff /* End of OS-specific. */ > #define ELFCOMPRESS_LOPROC 0x7000 /* Start of processor-specific. */ > #define ELFCOMPRESS_HIPROC 0x7fff /* End of processor-specific. */ > > So you could propose something on gnu-g...@sourceware.org for a GNU > extension or at generic-...@googlegroups.com for a generic ELF one. > And then get the ELF processing tools to adopt the new compression > type. ohhh, I didn't know it was baked in at this level. Yea, if we're going to do section compression with zstd, then it's clearly best to get it officially supported at the ABI level. jeff ___ 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-33-20201006.n.1 compose check report
Missing expected images: Xfce raw-xz armhfp Failed openQA tests: 4/170 (x86_64) New failures (same test not failed in Fedora-33-20201005.n.0): ID: 686308 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/686308 ID: 686405 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/686405 Old failures (same test failed in Fedora-33-20201005.n.0): ID: 686298 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/686298 ID: 686309 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/686309 Soft failed openQA tests: 9/170 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-33-20201005.n.0): ID: 686234 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/686234 ID: 686253 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/686253 ID: 686280 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/686280 ID: 686293 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/686293 ID: 686319 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/686319 ID: 686331 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/686331 ID: 686332 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/686332 ID: 686353 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/686353 ID: 686356 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/686356 Passed openQA tests: 157/170 (x86_64) New passes (same test not passed in Fedora-33-20201005.n.0): ID: 686258 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/686258 ID: 686291 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/686291 ID: 686364 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/686364 Installed system changes in test x86_64 Server-boot-iso install_default: 1 packages(s) added since previous compose: systemd-networkd Previous test data: https://openqa.fedoraproject.org/tests/685210#downloads Current test data: https://openqa.fedoraproject.org/tests/686232#downloads Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 1 packages(s) added since previous compose: systemd-networkd Previous test data: https://openqa.fedoraproject.org/tests/685211#downloads Current test data: https://openqa.fedoraproject.org/tests/686233#downloads Installed system changes in test x86_64 Everything-boot-iso install_default: 1 packages(s) added since previous compose: systemd-networkd System load changed from 0.18 to 0.06 Previous test data: https://openqa.fedoraproject.org/tests/685252#downloads Current test data: https://openqa.fedoraproject.org/tests/686274#downloads Installed system changes in test x86_64 Everything-boot-iso install_default@uefi: 1 packages(s) added since previous compose: systemd-networkd Previous test data: https://openqa.fedoraproject.org/tests/685253#downloads Current test data: https://openqa.fedoraproject.org/tests/686275#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 34 MiB to 52 MiB 1 packages(s) added since previous compose: lv2 1 packages(s) removed since previous compose: libblockdev-vdo System load changed from 1.07 to 1.20 Previous test data: https://openqa.fedoraproject.org/tests/685255#downloads Current test data: https://openqa.fedoraproject.org/tests/686277#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Used swap changed from 29 MiB to 41 MiB 1 packages(s) added since previous compose: lv2 1 packages(s) removed since previous compose: libblockdev-vdo Previous test data: https://openqa.fedoraproject.org/tests/685257#downloads Current test data: https://openqa.fedoraproject.org/tests/686279#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: 3 packages(s) added since previous compose: lv2, python3-gettext, python3-manatools 1 packages(s) removed since previous compose: libblockdev-vdo System load changed from 1.46 to 2.04 Previous test data: https://openqa.fedoraproject.org/tests/685274#downloads Current test data: https://openqa.fedoraproject.org/tests/686296#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Used swap changed from 14 MiB to 17 MiB 3 packages(s) added since
ELF section/file compression
Hi, Changing subject because this has nothing to do with that Change Proposal anymore. On Tue, Oct 06, 2020 at 01:49:13PM -0600, Jeff Law wrote: > However, I think it's perfectly valid to discuss zstd if folks wanted to > change the compression scheme for debug sections. In fact, I'd claim > sticking with zlib, gzip, bzip2, xz, 7z, etc is unwise. The world has > moved and zstd seems like the place we should be. In fact, we use it > for various things within GCC already. Personally I must admit that I am not really a fan of using ELF section/file compression. It makes it impossible to simply mmap the data in or to quickly read just a tiny bit because you first have to decompress (and allocate new memory) for it. IMHO .debug files are no different from other ELF files for which we would also not do this. We can just use rpm package compression to reduce the distro distribution size, but we should not (re)compress the install/on-disk files. That will just mean programs will create an extra cache of uncompressed files they need to consult frequently. But if you are going to do it, then it does make sense to use the most efficient algorithm there is. If you are going to experiment with this there are two ways to go about it. First you can use full file compression. That is actually already (almost transparently) supported for tools based on elfutils libdw when using the dwfl functions. For example eu-readelf (and some other eu- tools) can be run on any compressed file directly (the version in rawhide also supports zstd because the vmlinuz file now uses that). You would have to convince other DWARF consumers to do the same. And decide for those that use .gnu_debuglink instead of build-id lookups (or when build-id lookup fails) whether the filenames should include the compression extension like .zst or if a consumer is responsible for trying all (?) known compression extensions when resolving the .debug file. Secondly you can use ELF section compression. The ELF spec leaves room for adding new compression algorithms. The Chdr struct(s) contain a ch_type which describes the algorithm. Currently only one is specified, but there is a lot of room for expansion: /* Legal values for ch_type (compression algorithm). */ #define ELFCOMPRESS_ZLIB1 /* ZLIB/DEFLATE algorithm. */ #define ELFCOMPRESS_LOOS0x6000 /* Start of OS-specific. */ #define ELFCOMPRESS_HIOS0x6fff /* End of OS-specific. */ #define ELFCOMPRESS_LOPROC 0x7000 /* Start of processor-specific. */ #define ELFCOMPRESS_HIPROC 0x7fff /* End of processor-specific. */ So you could propose something on gnu-g...@sourceware.org for a GNU extension or at generic-...@googlegroups.com for a generic ELF one. And then get the ELF processing tools to adopt the new compression type. Cheers, Mark ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved
Am 06.10.20 um 23:21 schrieb Solomon Peachy: >> It's one thing to contact your repo or distro servers, and another if >> it's a known dataminer, that gets all domainnames you visit. > So.. given that both Google and Cloudfare have actual European business > offices, aren't they bound by the GPDR too? > > I get that it's fashionable these days to dump all over $Big_Tech, but > we're better off basing our arguments on actual facts and logic? If you have a contract with them, which you don't have, and the data stays in europe, it would be another thing. As a matter of fact, I have mailed our federal dp office and my statewise dp office for a dp statement. As soon as a statement, no matter which opinion they have, arrives, i will post the result here on the list, so we all have a better understanding of the matter. Due to the complexity of this matter, I dont expect an answere soon ;) Most likely i will receive a consultative call first and than it will takes months before something happens. Had it already for article 32 1a GDPR and the enforcement of TLS1_2 with SMTP in 2018. (btw.. i was right ;) ) best regards, Marius ___ 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: mock, febootstrap, building chroots a.k.a. debootstrap
On Tue, Oct 6, 2020, at 5:42 PM, Daniel Pocock wrote: > > > Hi all, > > I came across febootstrap[1] but it doesn't look like it has been > updated[2] for some time. What is the currently recommended method for > creating a chroot, is it mock or are there alternatives? > yum/dnf handles this natively: yum install --releasever=/ --installroot=/mnt/sysimage bash mypackage > Here is the problem I'm trying to solve: on the Talos II (ppc64) host, > most things run well enough using packages from Fedora 32 or Debian > stable. Sometimes it is necessary to run something from rawhide or > Debian sid in a chroot. > > As an example, I was able to run the latest version of Thunderbird in a > chroot. I'm sure other people will have things like this too. > > In the ideal case, I would like to mix-and-match across distributions > too, for example: > > - create a Debian sid chroot with debootstrap and use it from Fedora 32 > > - create a Fedora 33 or rawhide chroot (with mock?) and use it from Debian > > I create the chroots as Btrfs subvolumes, this gives the opportunity to > create snapshots too. > > After testing this a bit, I'd like to document it some more for other > people on the platform too. I noticed some people losing time trying to > compile things when they could potentially use upcoming versions of the > packages. Any feedback would be very welcome. > The "fastest to get started" way to solve getting these chroots is to pull a container image and extract that. V/r, James Cassell > Regards, > > Daniel > > 1. > https://rwmj.wordpress.com/2009/03/19/febootstrap-fedora-equivalent-of-debootstrap/ > 2. https://src.fedoraproject.org/rpms/febootstrap ___ 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
mock, febootstrap, building chroots a.k.a. debootstrap
Hi all, I came across febootstrap[1] but it doesn't look like it has been updated[2] for some time. What is the currently recommended method for creating a chroot, is it mock or are there alternatives? Here is the problem I'm trying to solve: on the Talos II (ppc64) host, most things run well enough using packages from Fedora 32 or Debian stable. Sometimes it is necessary to run something from rawhide or Debian sid in a chroot. As an example, I was able to run the latest version of Thunderbird in a chroot. I'm sure other people will have things like this too. In the ideal case, I would like to mix-and-match across distributions too, for example: - create a Debian sid chroot with debootstrap and use it from Fedora 32 - create a Fedora 33 or rawhide chroot (with mock?) and use it from Debian I create the chroots as Btrfs subvolumes, this gives the opportunity to create snapshots too. After testing this a bit, I'd like to document it some more for other people on the platform too. I noticed some people losing time trying to compile things when they could potentially use upcoming versions of the packages. Any feedback would be very welcome. Regards, Daniel 1. https://rwmj.wordpress.com/2009/03/19/febootstrap-fedora-equivalent-of-debootstrap/ 2. https://src.fedoraproject.org/rpms/febootstrap ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved
On Tue, Oct 06, 2020 at 11:00:23PM +0200, Marius Schwarz wrote: > It's one thing to contact your repo or distro servers, and another if > it's a known dataminer, that gets all domainnames you visit. So.. given that both Google and Cloudfare have actual European business offices, aren't they bound by the GPDR too? I get that it's fashionable these days to dump all over $Big_Tech, but we're better off basing our arguments on actual facts and logic? Indeed, is there even a legal "Fedora" entity in Europe? Shouldn't we all be getting up in arms about Red Hat, especially now that it's wholly owned by, which is itself another massive data miner? This seems to be a strange hill to fight over, especially for a last-ditch fallback that will only get used under an intentional [mis-]configuration of the network and/or Fedora system. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) 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: readelf seems broken in F33
On 10/6/20 3:05 PM, Florian Weimer wrote: > * Steve Grubb: > >> I was doing some binary analysis of files in F33 and have run across >> something odd. >> >> readelf -s /usr/sbin/auditd | grep GLIBC >> >> produces a lot of output like: >> >>182: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 >> (3) >>184: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 >> (3) >>185: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 >> (3) >>186: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 >> (3) >>187: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.3.2 >> (2) >>191: 0 FUNCGLOBAL DEFAULT UND alarm@GLIBC_2.2.5 >> (3) >>194: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 >> (3) >>195: 0 FUNCGLOBAL DEFAULT UND close@GLIBC_2.2.5 >> (3) >>197: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 >> (3) >> >> It's missing a lot of symbols. Is this something with readelf or an odd >> effect of the LTO changes? > This question looks familiar. > > It's a deliberate change to indicate truncation. Use readelf -sW if you > want to avoid it. Truncation has been silent before, so it's necessary > to educate users about readelf -W. I think I may have used --wide in my test because I wanted to see more info... jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning openbabel
Hi Zbigniew,
On Mon, Oct 5, 2020 at 7:53 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Mon, Oct 05, 2020 at 01:53:03AM +0200, Alexander Ploumistos wrote:
> […]
> I think it makes sense to add a new 'openbabel3' package. Like Kevin wrote
> in the other mail, it seems likely that some packages will depend on
> the old version for the foreseeable future. Python recently switched
> to a theme where it the "main" package has a number in the version [1].
> This works nicely when there are multiple incompatible versions...
That might be worth discussing with upstream. In the meantime, could
the executables in /usr/bin get a "3" appended to their names or would
that just break anything that might need them?
> > How do we deal with the complications of having both
> > of them around, especially since most of the binaries have the same
> > name?
>
> Explicit Conflicts? Unless there's a strong need to install packages
> in parallel, that seems like the easiest option.
Whatever's inside openbabel-libs and openbabel-devel can co-exist with
the files from the other version, so we're left with incompatibilities
between the binaries, the gui, docs (trivial) and python or any other
language binding I haven't discovered.
(Btw, when I run "repoquery --repo=fedora{,-source} --whatrequires
{ruby,perl,python3}-openbabel", I get no hits. Am I doing it wrong, or
could we stop caring for perl and ruby, that I'm not sure if they're
still there?)
At least packages that buildrequire openbabel or that require the
libraries are safe from breakage for now. However, our collection of
chemistry-related software is rather limited; slimming it down further
by splitting packages into mutually exclusive subgroups won't make
people's lives any easier (in our ecosystem at least).
> > - I suppose I could take over from Dominik (with the hope that not
> > many things will break down in the following year) the packages in
> > Fedora, but not EPEL and friends. Who wants to do that?
Dominik, if you want, you can add me (alexpl) to the repo. Is anyone
interested in maintaining the EPEL branches?
> > - Has any of the maintainers of dependent packages that are dead-ish
> > upstream looked at porting them to OB 3?
Anyone?
___
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 33 compose report: 20201006.n.1 changes
OLD: Fedora-33-20201005.n.0 NEW: Fedora-33-20201006.n.1 = SUMMARY = Added images:0 Dropped images: 62 Added packages: 11 Dropped packages:3 Upgraded packages: 186 Downgraded packages: 0 Size of added packages: 20.37 MiB Size of dropped packages:15.70 MiB Size of upgraded packages: 3.80 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -10.00 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-33-20201005.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-33-20201005.n.0.iso Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-33-20201005.n.0.iso Image: Cloud_Base qcow2 aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-33-20201005.n.0.aarch64.qcow2 Image: Cloud_Base raw-xz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-33-20201005.n.0.x86_64.raw.xz Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-33-20201005.n.0.iso Image: Everything boot aarch64 Path: Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-33-20201005.n.0.iso Image: Cloud_Base tar-gz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-33-20201005.n.0.x86_64.tar.gz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20201005.n.0.ppc64le.qcow2 Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-33-20201005.n.0.iso Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-33-20201005.n.0.aarch64.raw.xz Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-33-20201005.n.0.x86_64.vagrant-libvirt.box Image: Server boot armhfp Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-33-20201005.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-33-20201005.n.0.iso Image: Everything boot ppc64le Path: Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-33-20201005.n.0.iso Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-33-20201005.n.0.x86_64.vagrant-virtualbox.box Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-33-20201005.n.0.aarch64.raw.xz Image: Container_Minimal_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Minimal-Base-33-20201005.n.0.x86_64.tar.xz Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-33-20201005.n.0.x86_64.tar.xz Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-33-20201005.n.0.iso Image: Server boot x86_64 Path: Server/x86_64/iso/Fedora-Server-netinst-x86_64-33-20201005.n.0.iso Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-armhfp-33-20201005.n.0-sda.raw.xz Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-33-20201005.n.0.iso Image: Scientific vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Scientific-Vagrant-33-20201005.n.0.x86_64.vagrant-libvirt.box Image: Cloud_Base raw-xz aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-33-20201005.n.0.aarch64.raw.xz Image: Minimal raw-xz armhfp Path: Spins/armhfp/images/Fedora-Minimal-armhfp-33-20201005.n.0-sda.raw.xz Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-33-20201005.n.0.iso Image: Server dvd armhfp Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-33-20201005.n.0.iso Image: Workstation live x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-33-20201005.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-33-20201005.n.0.iso Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-33-20201005.n.0-sda.raw.xz Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-33-20201005.n.0.iso Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20201005.n.0.ppc64le.raw.xz Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-33-20201005.n.0.iso Image: Server dvd x86_64 Path: Server/x86_64/iso/Fedora-Server-dvd-x86_64-33-20201005.n.0.iso Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-33-20201005.n.0.aarch64.tar.xz Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-33-20201005.n.0.x86_64.vagrant-libvirt.box Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-33-20201005.n.0.iso Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-33-20201005.n.0-sda.raw.xz Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-33-20201005.n.0.iso Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-33-20201005.n.0.aarch64.tar.xz Image: Design_suite live
Re: readelf seems broken in F33
* Steve Grubb: > I was doing some binary analysis of files in F33 and have run across > something odd. > > readelf -s /usr/sbin/auditd | grep GLIBC > > produces a lot of output like: > >182: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >184: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >185: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >186: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >187: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.3.2 > (2) >191: 0 FUNCGLOBAL DEFAULT UND alarm@GLIBC_2.2.5 > (3) >194: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >195: 0 FUNCGLOBAL DEFAULT UND close@GLIBC_2.2.5 > (3) >197: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) > > It's missing a lot of symbols. Is this something with readelf or an odd > effect of the LTO changes? This question looks familiar. It's a deliberate change to indicate truncation. Use readelf -sW if you want to avoid it. Truncation has been silent before, so it's necessary to educate users about readelf -W. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved
Am 05.10.20 um 11:12 schrieb Petr Menšík: >> * Immediately after you connect to the network, Fedora connects to >> http://fedoraproject.org/static/hotspot.txt to see if you're behind a >> captive portal > Fedora is contacting fedora server, seems predictable. It's one thing to contact your repo or distro servers, and another if it's a known dataminer, that gets all domainnames you visit. Best regards, Marius ___ 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: readelf seems broken in F33
On 9/16/20 3:44 PM, Steve Grubb wrote: > Hello, > > I was doing some binary analysis of files in F33 and have run across > something odd. > > readelf -s /usr/sbin/auditd | grep GLIBC > > produces a lot of output like: > >182: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >184: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >185: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >186: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >187: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.3.2 > (2) >191: 0 FUNCGLOBAL DEFAULT UND alarm@GLIBC_2.2.5 > (3) >194: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) >195: 0 FUNCGLOBAL DEFAULT UND close@GLIBC_2.2.5 > (3) >197: 0 FUNCGLOBAL DEFAULT UND [...]@GLIBC_2.2.5 > (3) > > It's missing a lot of symbols. Is this something with readelf or an odd > effect of the LTO changes? Odd, I'm running F33 bits here and I get 159 symbols from running that (out of 206 total symbols). jeff pEpkey.asc Description: application/pgp-keys ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 3:14 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 22:11, Brandon Nielsen wrote: That link shows security fixes for 68.x from only a week ago. August 25, 2020 (68.12) vs. September 22, 2020 (78.3). But still, the last 68. release was 5 days ago[0], hardly seems unsupported. Sorry for all the spam. [0] - https://www.thunderbird.net/en-US/thunderbird/68.12.1/releasenotes/ ___ 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: Thunderbird - Unpleasant Surprise
On 06.10.2020 22:11, Brandon Nielsen wrote: That link shows security fixes for 68.x from only a week ago. August 25, 2020 (68.12) vs. September 22, 2020 (78.3). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Thunderbird - Unpleasant Surprise
On 10/6/20 3:11 PM, Brandon Nielsen wrote: On 10/6/20 3:03 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:48, Brandon Nielsen wrote: Yes, but they clearly don't expect updates to work given the changes mentioned later in this thread and the release notes, and Fedora has users that will be updating that need to be considered. 78.3.1 includes security fixes[1]. 68.x has reached its EOL and will no longer receive updates and fixes. [1]: https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/ That link shows security fixes for 68.x from only a week ago. I lied, no it doesn't. Their advisory numbers don't work how I thought. So really, this is a no win no matter what the ultimate decision is. ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 3:03 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:48, Brandon Nielsen wrote: Yes, but they clearly don't expect updates to work given the changes mentioned later in this thread and the release notes, and Fedora has users that will be updating that need to be considered. 78.3.1 includes security fixes[1]. 68.x has reached its EOL and will no longer receive updates and fixes. [1]: https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/ That link shows security fixes for 68.x from only a week ago. ___ 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
libvirt and systemd-resolved integration?
Hello, In the network bridges that libvirt creates there's a dnsmasq daemon to resolve the VM's IPs. Is there any way to signal systemd-resolved from libvirt to say that in the bridge interface there is a DNS server and a domain? Thank you. ___ 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: Thunderbird - Unpleasant Surprise
On 06.10.2020 21:48, Brandon Nielsen wrote: Yes, but they clearly don't expect updates to work given the changes mentioned later in this thread and the release notes, and Fedora has users that will be updating that need to be considered. 78.3.1 includes security fixes[1]. 68.x has reached its EOL and will no longer receive updates and fixes. [1]: https://www.mozilla.org/en-US/security/known-vulnerabilities/thunderbird/ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Thunderbird - Unpleasant Surprise
On 06.10.2020 21:38, Gordon Messmer wrote: Thunderbird > 68 has significant API changes. XUL has been completely removed for extensions, as well as numerous other breaking API changes, including to preferences and address books. Version 68.x is now EOL. It will no longer receive even security updates. All users must switch to 78.3.x branch as soon as possible. Only two add-ons stopped working on my system: Enigmail (now replaced by build-in OpenPGP support) and DKIM Verifier (replaced with 4.0-beta from GitHub releases). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)
On 10/4/20 2:48 PM, Jan Kratochvil wrote: > On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote: >> I was just discussing that recently with the Hotspot Perf GUI >> maintainer. And we concluded that if .debug files would be compressed >> then we would need an uncompressed cache somewhere. The issue with >> having the on-disk debuginfo files compressed is that for >> debugger/tracing/profiling tools it incurs an significant >> decompression time delay and extra memory usage. Especially for a >> profiling tool that only needs to quickly get a little information it >> is much more convenient to be able to simply mmap the .debug file, >> check the aranges and directly jump to the correct DIE offset. See >> e.g. https://github.com/KDAB/hotspot/issues/115 > First is is a marginal use case. For the GDB popular here I tested zlib on > some IIRC 500MB+ .debug file and the startup time was 11.00s->12.45s > = +13.20%. Given GDB takes minutes to print something on such .debug files the > <2s larger startup does not matter. I'm not sure it's that marginal. It may not matter for GDB since I don't think the bottleneck is likely the decompression. It would certainly matter for profiling and the like -- I'd probably argue that dwarf is a terrible choice for those tools, but I don't see CTF as a viable alternative though, so they're stuck in the dwarf world. > > And then all this is about zlib compression. Facebook has developed zstd which > is much faster. Google says faster than reading the .debug files, on my > machine both zstd and NVMe disk read are both 2GB/s. I expect btrfs has even > in-memory cache for decompressed files but I have not checked it now as all > the numbers I have collected have no effect here anyway. Please, let's stop talking about btrfs here. It's not useful. However, I think it's perfectly valid to discuss zstd if folks wanted to change the compression scheme for debug sections. In fact, I'd claim sticking with zlib, gzip, bzip2, xz, 7z, etc is unwise. The world has moved and zstd seems like the place we should be. In fact, we use it for various things within GCC already. Jeff pEpkey.asc Description: application/pgp-keys ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 2:45 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:24, Brandon Nielsen wrote: Sounds to me they don't expect 78.2.1 to be entirely compatible with profiles from the previous version. $ rpm -qa thunderbird thunderbird-78.3.1-1.fc32.x86_64 Version 78.3.1 is production ready. Mozilla has made it available to all Thunderbird users on all supported platforms. $ rpm -qa thunderbird thunderbird-68.11.0-1.fc32.x86_64 Yes, but they clearly don't expect updates to work given the changes mentioned later in this thread and the release notes, and Fedora has users that will be updating that need to be considered. ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 12:08 PM, Gordon Messmer wrote: I'll put in a BZ as soon as I'm not tied up in meetings. https://bugzilla.redhat.com/show_bug.cgi?id=1885722 ___ 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: Thunderbird - Unpleasant Surprise
On 06.10.2020 21:24, Brandon Nielsen wrote: Sounds to me they don't expect 78.2.1 to be entirely compatible with profiles from the previous version. $ rpm -qa thunderbird thunderbird-78.3.1-1.fc32.x86_64 Version 78.3.1 is production ready. Mozilla has made it available to all Thunderbird users on all supported platforms. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F32 to F33
Dne 03. 10. 20 v 23:28 Tom Seewald napsal(a): > Error: Transaction test error: > file /usr/lib/.build-id/0e/fd9f1f23d7cefd37989b7d1b401b4994fee742 conflicts > between attempted installs of openjfx-11.0.3-1.fc33.x86_64 and > openjfx8-8.0.202-24.b07.fc33.x86_64 > file /usr/lib/.build-id/2d/747b771939ec456dadf18bfbec6a5db9d3a4cc conflicts > between attempted installs of openjfx-11.0.3-1.fc33.x86_64 and > openjfx8-8.0.202-24.b07.fc33.x86_64 > > If this needs to be formally filed as a bug, should it be opened against > openjfx or fedora-upgrade or something else? Against openjfx please. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ 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: Thunderbird - Unpleasant Surprise
On 10/6/20 12:22 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:08, Gordon Messmer wrote: I definitely think this should be rolled back. We're past the beta freeze, and IMO, this violates the updates policy which states "Package maintainers MUST: Avoid Major version updates, ABI breakage, or API changes if at all possible." Thunderbird's update is not broken, it has no API/ABI breakages. Everything works just fine. https://developer.thunderbird.net/add-ons/updating/tb78/changes Thunderbird > 68 has significant API changes. XUL has been completely removed for extensions, as well as numerous other breaking API changes, including to preferences and address books. ___ 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: Follow-up - Please BuildRequire python3-setuptools explicitly
Dne 05. 10. 20 v 12:55 Tomas Hrnciar napsal(a): > copr-messaging schlupov Fixed in upstream. https://pagure.io/copr/copr/pull-request/1534 Will propagate to Fedora soon. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20201006.n.1 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 8/181 (x86_64) New failures (same test not failed in Fedora-Rawhide-20201004.n.1): ID: 685840 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/685840 Old failures (same test failed in Fedora-Rawhide-20201004.n.1): ID: 685843 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/685843 ID: 685846 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/685846 ID: 685866 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/685866 ID: 685927 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/685927 ID: 685961 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/685961 ID: 685962 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/685962 ID: 685963 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/685963 Soft failed openQA tests: 8/181 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20201004.n.1): ID: 685783 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/685783 ID: 685802 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/685802 ID: 685829 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/685829 ID: 685842 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/685842 ID: 685862 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/685862 ID: 685865 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/685865 ID: 685879 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/685879 ID: 685892 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/685892 Passed openQA tests: 150/181 (x86_64) New passes (same test not passed in Fedora-Rawhide-20201004.n.1): ID: 685807 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/685807 ID: 685831 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/685831 ID: 685835 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/685835 Skipped gating openQA tests: 4/181 (x86_64) Old skipped gating tests (same test skipped in Fedora-Rawhide-20201004.n.1): ID: 685966 Test: x86_64 KDE-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/685966 ID: 685967 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/685967 ID: 685976 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/685976 ID: 685978 Test: x86_64 KDE-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/685978 Skipped non-gating openQA tests: 11 of 181 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.26 to 0.12 Previous test data: https://openqa.fedoraproject.org/tests/684964#downloads Current test data: https://openqa.fedoraproject.org/tests/685781#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: Used mem changed from 202 MiB to 180 MiB 5 packages(s) removed since previous compose: jitterentropy, libsysfs, openssl-pkcs11, rng-tools, rtl-sdr 1 services(s) removed since previous compose: rngd.service System load changed from 0.26 to 0.11 Previous test data: https://openqa.fedoraproject.org/tests/684974#downloads Current test data: https://openqa.fedoraproject.org/tests/685791#downloads Installed system changes in test x86_64 Server-dvd-iso install_default_upload: Used mem changed from 201 MiB to 178 MiB 5 packages(s) removed since previous compose: jitterentropy, libsysfs, openssl-pkcs11, rng-tools, rtl-sdr 1 services(s) removed since previous compose: rngd.service Previous test data: https://openqa.fedoraproject.org/tests/684976#downloads Current test data: https://openqa.fedoraproject.org/tests/685793#downloads Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.31 to 0.14 Previous test data:
[Bug 1885000] perl-ExtUtils-MakeMaker-7.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885000 --- Comment #6 from Fedora Update System --- FEDORA-2020-8be581dc39 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8be581dc39` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8be581dc39 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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: Thunderbird - Unpleasant Surprise
On 10/6/20 2:22 PM, Vitaly Zaitsev via devel wrote: On 06.10.2020 21:08, Gordon Messmer wrote: I definitely think this should be rolled back. We're past the beta freeze, and IMO, this violates the updates policy which states "Package maintainers MUST: Avoid Major version updates, ABI breakage, or API changes if at all possible." Thunderbird's update is not broken, it has no API/ABI breakages. Everything works just fine. Personally, I think this change warrants its own self-contained change proposal in the next release of Fedora, even though Thunderbird 68 will not receive updates after Sep 2020 OpenPGP is now build-in into Thunderbird core. No third party addons required. One way or another, I need to roll back until SOGo has time to finish porting their extension to the new API. After rolled back, the Lightning extension isn't enabled or even visible in Add-ons, so I have to figure out how to fix that. Fedora is a bleeding edge distribution. If you need a legacy version of any package, you can always build it in COPR. I want to use the most recent version. While I agree with wanting the latest version, and it doesn't break anything I use, from the release notes linked above: "Thunderbird version 78.2.1 is only offered as direct download from thunderbird.net and not as an upgrade from Thunderbird version 68 or earlier. A future release will provide updates from earlier versions. Automatic updates are available for users already running version 78.0 or higher." Sounds to me they don't expect 78.2.1 to be entirely compatible with profiles from the previous version. ___ 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: Thunderbird - Unpleasant Surprise
On 06.10.2020 21:08, Gordon Messmer wrote: I definitely think this should be rolled back. We're past the beta freeze, and IMO, this violates the updates policy which states "Package maintainers MUST: Avoid Major version updates, ABI breakage, or API changes if at all possible." Thunderbird's update is not broken, it has no API/ABI breakages. Everything works just fine. Personally, I think this change warrants its own self-contained change proposal in the next release of Fedora, even though Thunderbird 68 will not receive updates after Sep 2020 OpenPGP is now build-in into Thunderbird core. No third party addons required. One way or another, I need to roll back until SOGo has time to finish porting their extension to the new API. After rolled back, the Lightning extension isn't enabled or even visible in Add-ons, so I have to figure out how to fix that. Fedora is a bleeding edge distribution. If you need a legacy version of any package, you can always build it in COPR. I want to use the most recent version. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Thunderbird - Unpleasant Surprise
On 10/6/20 4:29 AM, Ankur Sinha wrote: Thunderbird 78 seems to be a major "breaking" upgrade: https://www.thunderbird.net/en-US/thunderbird/78.2.1/releasenotes/#changes I definitely think this should be rolled back. We're past the beta freeze, and IMO, this violates the updates policy which states "Package maintainers MUST: Avoid Major version updates, ABI breakage, or API changes if at all possible." Personally, I think this change warrants its own self-contained change proposal in the next release of Fedora, even though Thunderbird 68 will not receive updates after Sep 2020: https://blog.thunderbird.net/2020/09/openpgp-in-thunderbird-78/ One way or another, I need to roll back until SOGo has time to finish porting their extension to the new API. After rolled back, the Lightning extension isn't enabled or even visible in Add-ons, so I have to figure out how to fix that. Given that downgrading is not trivial, can this update be backed out ASAP? I'll put in a BZ as soon as I'm not tied up in meetings. ___ 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: Self Introduction: Ben Beasley
On Tue, Oct 06, 2020 at 02:47:36PM -0400, Ben Beasley wrote: > Hello, everyone—my name is Ben Beasley. I’m an electrical engineer > in the USA with training and experience in communications systems > and digital signal processing. I’ve been writing domain-specific and > general-purpose software in many languages (Python, C, C++, > JavaScript/ECMAScript, bash/sh, awk, MATLAB/Octave, and others) for > about fifteen years, and doing RPM packaging on CentOS/RHEL and > Fedora for about ten years. Very little of this work has been > published or contributed to the FOSS community. > > Now I want to contribute more to Fedora than I have in the past. > I’ve made a few PR’s to Fedora and to upstreams recently, and I just > submitted my first package review request, > https://bugzilla.redhat.com/show_bug.cgi?id=1885684, “rocm-smi - AMD > ROCm System Management Interface.” My thanks in advance to anyone > who is willing to review this submission, and especially to anyone > who might be willing to subsequently sponsor me into the packager > group. Hi, welcome to Fedora. I replied in the review ticket. Zbyszek ___ 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-IoT-33-20201006.0 compose check report
No missing expected images. Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 685979 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/685979 Passed openQA tests: 15/16 (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
Fedora rawhide compose report: 20201006.n.1 changes
OLD: Fedora-Rawhide-20201004.n.1 NEW: Fedora-Rawhide-20201006.n.1 = SUMMARY = Added images:0 Dropped images: 58 Added packages: 14 Dropped packages:6 Upgraded packages: 192 Downgraded packages: 0 Size of added packages: 1.14 GiB Size of dropped packages:15.75 MiB Size of upgraded packages: 7.37 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 96.03 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20201004.n.1.iso Image: Container_Minimal_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Minimal-Base-Rawhide-20201004.n.1.x86_64.tar.xz Image: Minimal raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20201004.n.1.aarch64.raw.xz Image: Minimal raw-xz armhfp Path: Spins/armhfp/images/Fedora-Minimal-armhfp-Rawhide-20201004.n.1-sda.raw.xz Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201004.n.1.x86_64.vagrant-libvirt.box Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20201004.n.1.ppc64le.tar.xz Image: Workstation live ppc64le Path: Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20201004.n.1.iso Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20201004.n.1.iso Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201004.n.1.x86_64.vagrant-libvirt.box Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-Rawhide-20201004.n.1.x86_64.tar.xz Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20201004.n.1.iso Image: KDE live x86_64 Path: Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20201004.n.1.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20201004.n.1.iso Image: Cloud_Base qcow2 aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20201004.n.1.aarch64.qcow2 Image: Workstation live x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20201004.n.1.iso Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20201004.n.1-sda.raw.xz Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201004.n.1.x86_64.vagrant-virtualbox.box Image: Server boot aarch64 Path: Server/aarch64/iso/Fedora-Server-netinst-aarch64-Rawhide-20201004.n.1.iso Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20201004.n.1.iso Image: Server boot armhfp Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-Rawhide-20201004.n.1.iso Image: Everything boot aarch64 Path: Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20201004.n.1.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20201004.n.1.iso Image: Everything boot armhfp Path: Everything/armhfp/iso/Fedora-Everything-netinst-armhfp-Rawhide-20201004.n.1.iso Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201004.n.1.x86_64.vagrant-virtualbox.box Image: Workstation raw-xz aarch64 Path: Workstation/aarch64/images/Fedora-Workstation-Rawhide-20201004.n.1.aarch64.raw.xz Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20201004.n.1.iso Image: Workstation raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-armhfp-Rawhide-20201004.n.1-sda.raw.xz Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20201004.n.1.ppc64le.qcow2 Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20201004.n.1.iso Image: Cloud_Base raw-xz aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20201004.n.1.aarch64.raw.xz Image: Cloud_Base qcow2 x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Rawhide-20201004.n.1.x86_64.qcow2 Image: Server boot ppc64le Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20201004.n.1.iso Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20201004.n.1-sda.raw.xz Image: Server dvd aarch64 Path: Server/aarch64/iso/Fedora-Server-dvd-aarch64-Rawhide-20201004.n.1.iso Image: Everything boot ppc64le Path: Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20201004.n.1.iso Image: Server dvd x86_64 Path: Server/x86_64/iso/Fedora-Server-dvd-x86_64-Rawhide-20201004.n.1.iso Image: Server dvd armhfp Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-Rawhide-20201004.n.1.iso Image: Server boot x86_64 Path: Server/x86_64/iso/Fedora-Server-netinst-x86_64-Rawhide-20201004.n.1.iso Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20201004.n.1.aarch64.raw.xz
Re: When will we have access to https://openqa.stg.fedoraproject.org ?
On Mon, 2020-09-14 at 09:22 -0700, Adam Williamson wrote: > On Mon, 2020-09-14 at 08:56 -0700, Kevin Fenzi wrote: > > On Mon, Sep 14, 2020 at 10:31:50AM +0200, Normand wrote: > > > Hello Adam, > > > > > > Since the infra move we do not have anymore access to > > > https://openqa.stg.fedoraproject.org > > > Do you know when it is planned to have access to it ? > > > > > > So unable to have access to openqa tests results for aarch64 and ppc64le. > > > > It's on my list to bring those workers back up and get them configured. > > > > I hope to work on that this week, but I will make no promises... it > > depends on how far I can get with staging and how few/many fires show > > up. ;( > > We also need the host. I believe we've talked about it a few times but > not sure what the latest status was. I think we were also talking about > renaming it because it's not really staging... Update on this: the answer to the question is "now" :) It is back with all three arches running. I'm currently working on teething problems, notably with tap network tests. Hoping to have it FULLY OPERATIONAL soon. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org
Self Introduction: Ben Beasley
Hello, everyone—my name is Ben Beasley. I’m an electrical engineer in the USA with training and experience in communications systems and digital signal processing. I’ve been writing domain-specific and general-purpose software in many languages (Python, C, C++, JavaScript/ECMAScript, bash/sh, awk, MATLAB/Octave, and others) for about fifteen years, and doing RPM packaging on CentOS/RHEL and Fedora for about ten years. Very little of this work has been published or contributed to the FOSS community. Now I want to contribute more to Fedora than I have in the past. I’ve made a few PR’s to Fedora and to upstreams recently, and I just submitted my first package review request, https://bugzilla.redhat.com/show_bug.cgi?id=1885684, “rocm-smi - AMD ROCm System Management Interface.” My thanks in advance to anyone who is willing to review this submission, and especially to anyone who might be willing to subsequently sponsor me into the packager group. Best wishes, Ben Beasley ___ 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: sundials-5.4.0 updating
Hello, Done: https://bodhi.fedoraproject.org/updates/FEDORA-2020-47ad64ac29 -- 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: sundials-5.4.0 updating
On Tue, Oct 06, 2020 11:32:27 -0700, Kevin Fenzi wrote: > > > The web ui will only show that if _you_ created the side tag. > > If you are using provenpackger perms you will need to use the cli > (for now) > > bodhi updates new --from-tag --notes "whatever" > Ah, thanks Kevin! I'll go do that now. I'll also note this on the wiki page when I find the time. -- 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: sundials-5.4.0 updating
On Tue, Oct 06, 2020 at 06:58:25PM +0100, Ankur Sinha wrote: > On Tue, Oct 06, 2020 18:47:10 +0100, Ankur Sinha wrote: > > On Tue, Oct 06, 2020 19:41:50 +0200, Antonio T. sagitter wrote: > > > Follow the guidelines for using Bodhi: > > > https://fedoraproject.org/wiki/Package_update_HOWTO#Bodhi_update_for_builds_in_a_side-tag > > > > > > If you're a proven packager, you shouldn't have any problem of commit > > > access for all packages. > > > > Sure. I'm a proven packager. I can push them all if you wish? > > Hrm, I don't see a "use side tag" drop down on Bodhi here so I don't > quite know how to proceed. The web ui will only show that if _you_ created the side tag. If you are using provenpackger perms you will need to use the cli (for now) bodhi updates new --from-tag --notes "whatever" kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: sundials-5.4.0 updating
On 06/10/20 19:47, Ankur Sinha wrote: > On Tue, Oct 06, 2020 19:41:50 +0200, Antonio T. sagitter wrote: >> Follow the guidelines for using Bodhi: >> https://fedoraproject.org/wiki/Package_update_HOWTO#Bodhi_update_for_builds_in_a_side-tag >> >> If you're a proven packager, you shouldn't have any problem of commit >> access for all packages. > > Sure. I'm a proven packager. I can push them all if you wish? > Yes, push all packages. Thank you. -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: interest in debuginfod as fedora service
On Mon, Oct 05, 2020 at 01:42:21PM -0400, Frank Ch. Eigler wrote: > Adam Williamson writes: > > > This seems like it sort of overlaps a bit with what the abrt retrace > > server does. It's not the same, but in order to do what it does, the > > retrace server *does* need to act as a remote provider of debuginfo. I > > wonder if it's possible to combine these somehow? > > Another possible integration path would be simply to co-site the retrace > and debuginfod services. The former already needs to mirror (or > directly access?) various distro RPMs. debuginfod could use the retrace > server's rpm repo as its source. That sounds like it might be a very nice idea... but I'm not one of the retrace/faf maintainers, so I guess lets see what they say. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: sundials-5.4.0 updating
On Tue, Oct 06, 2020 19:41:50 +0200, Antonio T. sagitter wrote: > Follow the guidelines for using Bodhi: > https://fedoraproject.org/wiki/Package_update_HOWTO#Bodhi_update_for_builds_in_a_side-tag > > If you're a proven packager, you shouldn't have any problem of commit > access for all packages. Sure. I'm a proven packager. I can push them all if you wish? -- 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: sundials-5.4.0 updating
Follow the guidelines for using Bodhi: https://fedoraproject.org/wiki/Package_update_HOWTO#Bodhi_update_for_builds_in_a_side-tag If you're a proven packager, you shouldn't have any problem of commit access for all packages. On 06/10/20 19:34, Ankur Sinha wrote: > On Tue, Oct 06, 2020 19:14:00 +0200, Antonio T. sagitter wrote: >> All rebuilds are done but i haven't commit access for pushing them as >> new updates in Bodhi: >> >> $ koji list-tagged --latest f34-build-side-31299 >> Build Tag Built by >> >> >> dolfin-2019.1.0.post0-11.fc34 f34-build-side-31299 zbyszek >> octave-5.2.0-8.fc34 f34-build-side-31299 orion >> python-steps-3.5.0-6.fc34 f34-build-side-31299 sagitter >> sundials-5.4.0-1.fc34 f34-build-side-31299 sagitter >> > I can push python-steps. Is there anything special I must do on Bodhi please? > > -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: sundials-5.4.0 updating
On Tue, Oct 06, 2020 19:14:00 +0200, Antonio T. sagitter wrote: > All rebuilds are done but i haven't commit access for pushing them as > new updates in Bodhi: > > $ koji list-tagged --latest f34-build-side-31299 > Build Tag Built by > > > dolfin-2019.1.0.post0-11.fc34 f34-build-side-31299 zbyszek > octave-5.2.0-8.fc34 f34-build-side-31299 orion > python-steps-3.5.0-6.fc34 f34-build-side-31299 sagitter > sundials-5.4.0-1.fc34 f34-build-side-31299 sagitter > I can push python-steps. Is there anything special I must do on Bodhi please? -- 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
[Bug 1885677] perl-Net-Amazon-S3-0.95 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885677 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-Net-Amazon-S3-0.95-1.fc32.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=52875763 -- 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: sundials-5.4.0 updating
All rebuilds are done but i haven't commit access for pushing them as new updates in Bodhi: $ koji list-tagged --latest f34-build-side-31299 Build Tag Built by dolfin-2019.1.0.post0-11.fc34 f34-build-side-31299 zbyszek octave-5.2.0-8.fc34 f34-build-side-31299 orion python-steps-3.5.0-6.fc34 f34-build-side-31299 sagitter sundials-5.4.0-1.fc34 f34-build-side-31299 sagitter On 03/10/20 14:17, Antonio T. sagitter wrote: > Hi again. > > You can build packages depending on Sundials by using the side-tag > f34-build-side-31299: > > Use 'fedpkg build --target=f34-build-side-31299' to use it. > Use 'koji wait-repo f34-build-side-31299' to wait for the build repo to > be generated. > > On 25/09/20 21:04, Antonio T. sagitter wrote: >> Hi all. >> >> Sundials will be updated to the release 5.4.0 on Rawhide branch in 7 >> days at least. Probably, i will create a specific side-tag. >> >> Sundials 5.4.0 release notes: >> https://github.com/LLNL/sundials/releases/tag/v5.4.0 >> >> Regards. >> -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1885677] New: perl-Net-Amazon-S3-0.95 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885677 Bug ID: 1885677 Summary: perl-Net-Amazon-S3-0.95 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Net-Amazon-S3 Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: igor.ra...@gmail.com, jakub.jedel...@gmail.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, rr...@redhat.com, tjczep...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.95 Current version/release in rawhide: 0.94-1.fc34 URL: http://search.cpan.org/dist/Net-Amazon-S3/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/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/6573/ -- 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 1885677] perl-Net-Amazon-S3-0.95 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885677 --- Comment #1 from Upstream Release Monitoring --- Created attachment 1719454 --> https://bugzilla.redhat.com/attachment.cgi?id=1719454=edit [patch] Update to 0.95 (#1885677) -- 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: Could Bodhi create some temporary repositories before composes are ready?
On Tue, 6 Oct 2020 at 12:21, Pavel Raiskup wrote: > On Tuesday, October 6, 2020 5:06:59 PM CEST Stephen John Smoogen wrote: > > On Tue, 6 Oct 2020 at 03:16, Pavel Raiskup wrote: > > > > > The KMail app stopped working for me today, and I realized there's > > > update to which I'd like to give a try: > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-15d324f87c > > > > > > In Bodhi, the suggested command to test this update is: > > > > > > sudo dnf upgrade --enablerepo=updates-testing > > > --advisory=FEDORA-2020-15d324f87c > > > > > > But that doesn't work because the mirrored updates-testing is not > > > yet updated. And downloading all the builds manually from Koji > > > is just too much work ATM. > > > > > > Would it be possible to enhance Bodhi so it provides the repositories > > > somewhere in the meantime, before composes are ready? > > > This is not the first time I'd found this feature very convenient. > > > > > > > A couple of things. Bodhi doesn't make composes and doesn't directly > > provide anything, so it would need to be some other tool which built and > > provided the mini-compose. This tool would need extra hardware and disk > > space as we aren't budgeted for this and will not see more disk space to > > our current infrastructure til probably 2022. > > > > Second, the Bodhi team was a temporary group to get a bodhi feature set > > over the line at a certain point in time. Those people are now assigned > to > > other projects to get container builds, flatpaks, replacing our 12 year > old > > account system, and other items into place. When those items are > completed > > those people will be assigned to fixing whatever other new tool is needed > > to get things done. > > > > If people want this, there is going to need to be a project request with > a > > detailed explanation, project scope, budget idea, what it will fix and > > various ways to weigh it against other projects, etc. I am guessing this > > would need to go to the council to work out if it is a higher need than > > some other items they expect CPE to work on. > > Ok, ok.. I fear it is out of scope for me to drive this. Just saying > what I'd found useful (and I probably filled the RFE against a wrong > component. > Sorry). > I'm fine with the 'bodhi' client auto-download and the custom script > for now ... In future I'll try to submit a PR against bodhi client, or dnf > plugins, I don't know ... and move the logic there. > > The issue is that what is needed is a better end to end definition of what the build system needs to be, and how to make it so versus a lot of requests where people come in with different things and we cram one more feral cat into the bag to make it work. I know that Kevin has tried to get a couple initiatives together overtime but not a lot of takers since it is mostly politics of horsetrading. > Pavel > > > > > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Could Bodhi create some temporary repositories before composes are ready?
On Tuesday, October 6, 2020 5:06:59 PM CEST Stephen John Smoogen wrote: > On Tue, 6 Oct 2020 at 03:16, Pavel Raiskup wrote: > > > The KMail app stopped working for me today, and I realized there's > > update to which I'd like to give a try: > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-15d324f87c > > > > In Bodhi, the suggested command to test this update is: > > > > sudo dnf upgrade --enablerepo=updates-testing > > --advisory=FEDORA-2020-15d324f87c > > > > But that doesn't work because the mirrored updates-testing is not > > yet updated. And downloading all the builds manually from Koji > > is just too much work ATM. > > > > Would it be possible to enhance Bodhi so it provides the repositories > > somewhere in the meantime, before composes are ready? > > This is not the first time I'd found this feature very convenient. > > > > A couple of things. Bodhi doesn't make composes and doesn't directly > provide anything, so it would need to be some other tool which built and > provided the mini-compose. This tool would need extra hardware and disk > space as we aren't budgeted for this and will not see more disk space to > our current infrastructure til probably 2022. > > Second, the Bodhi team was a temporary group to get a bodhi feature set > over the line at a certain point in time. Those people are now assigned to > other projects to get container builds, flatpaks, replacing our 12 year old > account system, and other items into place. When those items are completed > those people will be assigned to fixing whatever other new tool is needed > to get things done. > > If people want this, there is going to need to be a project request with a > detailed explanation, project scope, budget idea, what it will fix and > various ways to weigh it against other projects, etc. I am guessing this > would need to go to the council to work out if it is a higher need than > some other items they expect CPE to work on. Ok, ok.. I fear it is out of scope for me to drive this. Just saying what I'd found useful (and I probably filled the RFE against a wrong component. Sorry). I'm fine with the 'bodhi' client auto-download and the custom script for now ... In future I'll try to submit a PR against bodhi client, or dnf plugins, I don't know ... and move the logic there. Pavel ___ 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 1885000] perl-ExtUtils-MakeMaker-7.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885000 --- Comment #5 from Fedora Update System --- FEDORA-2020-3791de1048 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-3791de1048` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3791de1048 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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 1885000] perl-ExtUtils-MakeMaker-7.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885000 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-2020-11513a4a33 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-11513a4a33` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-11513a4a33 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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 1885219] perl-Devel-CheckOS-1.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885219 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2020-fe00b9307e has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-fe00b9307e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe00b9307e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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 1884931] perl-Pod-Checker-1.74 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1884931 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2020-42460aec00 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-42460aec00` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-42460aec00 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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: Could Bodhi create some temporary repositories before composes are ready?
On Tue, 6 Oct 2020 at 03:16, Pavel Raiskup wrote: > The KMail app stopped working for me today, and I realized there's > update to which I'd like to give a try: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-15d324f87c > > In Bodhi, the suggested command to test this update is: > > sudo dnf upgrade --enablerepo=updates-testing > --advisory=FEDORA-2020-15d324f87c > > But that doesn't work because the mirrored updates-testing is not > yet updated. And downloading all the builds manually from Koji > is just too much work ATM. > > Would it be possible to enhance Bodhi so it provides the repositories > somewhere in the meantime, before composes are ready? > This is not the first time I'd found this feature very convenient. > A couple of things. Bodhi doesn't make composes and doesn't directly provide anything, so it would need to be some other tool which built and provided the mini-compose. This tool would need extra hardware and disk space as we aren't budgeted for this and will not see more disk space to our current infrastructure til probably 2022. Second, the Bodhi team was a temporary group to get a bodhi feature set over the line at a certain point in time. Those people are now assigned to other projects to get container builds, flatpaks, replacing our 12 year old account system, and other items into place. When those items are completed those people will be assigned to fixing whatever other new tool is needed to get things done. If people want this, there is going to need to be a project request with a detailed explanation, project scope, budget idea, what it will fix and various ways to weigh it against other projects, etc. I am guessing this would need to go to the council to work out if it is a higher need than some other items they expect CPE to work on. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1885368] perl-Digest-MD5-2.58 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885368 Jitka Plesnikova changed: What|Removed |Added Fixed In Version||perl-Digest-MD5-2.58-1.fc34 -- 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 1885489] perl-Test2-Suite-0.000136 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885489 --- Comment #2 from Fedora Update System --- FEDORA-2020-ddacb31212 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ddacb31212 -- 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 1885368] perl-Digest-MD5-2.58 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885368 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #4 from Fedora Update System --- FEDORA-2020-1c29e70c7b has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1c29e70c7b -- 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 1885489] perl-Test2-Suite-0.000136 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885489 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Test2-Suite-0.000136-1 ||.fc34 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for Fedora ≥ 33. -- 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: Bodhi failed to get a resource from PDC ...
This outage should be over. On Tue, 6 Oct 2020 at 07:50, Ankur Sinha wrote: > Hello, > > On Tue, Oct 06, 2020 13:43:57 +0200, Michael Schwendt wrote: > > Bodhi fails with this error message. Any suggestion on how to continue? > > > > Builds : Unable to create update. > > Bodhi failed to get a resource from PDC at the following URL > > " > https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=true_path=true=global_component=f32_size=100=rpm_component=claws-mail > ". > > The status code was "503". > > The error was "". > > This is reported here: > https://pagure.io/fedora-infrastructure/issue/9376 > > Being looked into. > > This problem has been fixed. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1885489] perl-Test2-Suite-0.000136 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885489 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Could Bodhi create some temporary repositories before composes are ready?
On Tuesday, October 6, 2020 10:35:04 AM CEST Mattia Verga via devel wrote: > Il 06/10/20 09:15, Pavel Raiskup ha scritto: > > The KMail app stopped working for me today, and I realized there's > > update to which I'd like to give a try: > > > >https://bodhi.fedoraproject.org/updates/FEDORA-2020-15d324f87c > > > > In Bodhi, the suggested command to test this update is: > > > >sudo dnf upgrade --enablerepo=updates-testing > > --advisory=FEDORA-2020-15d324f87c > > > > But that doesn't work because the mirrored updates-testing is not > > yet updated. And downloading all the builds manually from Koji > > is just too much work ATM. > > You can let Bodhi client download the builds for you: > > bodhi updates download --updateid FEDORA-2020-15d324f87c > > Then dnf install the downloaded builds. Awesome, I didn't know this! Thank you, it would be awesome if each of the update mentioned that command (at least till it is in updates-testing). I wrapped that + createrepo + dnf update into a simple script, if anyone else finds it useful: https://github.com/praiskup/fedora-early-testing/blob/master/fedora-early-testing > > Would it be possible to enhance Bodhi so it provides the repositories > > somewhere in the meantime, before composes are ready? > > This is not the first time I'd found this feature very convenient. > > Very unlikely. That would mean to provide some (a lot of) extra space > somewhere. Moreover, Bodhi development workforce is way under the > needs... you can try to open a ticket upstream, but that will likely > pile up with many others. The repo doesn't have to be kept forever, only till the update is really available in updates-testing. I assume that it wouldn't be unreasonable amount of storage? Ok, trying here: https://github.com/fedora-infra/bodhi/issues/4136 Pavel ___ 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 1884123] perl-Gnome2-GConf-1.046 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1884123 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Gnome2-GConf-1.046-1.f |perl-Gnome2-GConf-1.046-1.f |c34 |c34 ||perl-Gnome2-GConf-1.046-1.f ||c33 Resolution|--- |ERRATA Last Closed||2020-10-06 14:04:41 --- Comment #9 from Fedora Update System --- FEDORA-2020-a23938adb1 has been pushed to the Fedora 33 stable repository. If problem still persists, 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
[Bug 1884124] perl-Gnome2-Canvas-1.004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1884124 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Gnome2-Canvas-1.004-1. |perl-Gnome2-Canvas-1.004-1. |fc34|fc34 ||perl-Gnome2-Canvas-1.004-1. ||fc33 Resolution|--- |ERRATA Last Closed||2020-10-06 14:04:38 --- Comment #9 from Fedora Update System --- FEDORA-2020-aa9700ac47 has been pushed to the Fedora 33 stable repository. If problem still persists, 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
[Bug 1885219] perl-Devel-CheckOS-1.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885219 --- Comment #1 from Fedora Update System --- FEDORA-2020-fe00b9307e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fe00b9307e -- 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 1885219] perl-Devel-CheckOS-1.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885219 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Devel-CheckOS-1.84-1.f ||c34 -- 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: Orphaned poetry and some of its dependencies
On 06. 10. 20 15:31, Tomas Hrnciar wrote: I will take care of your packages once the "Take" button starts to work again. I've added you manually (together with python-sig). 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://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
GNOME 3.38.1 megaupdate is wrapped up
If you have any late 3.38.1 builds, just submit them separately to Bodhi please. The 3.38.1 megaupdate is already in Bodhi and on its way to stable: https://bodhi.fedoraproject.org/updates/FEDORA-2020-93095cb647 -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned poetry and some of its dependencies
Hello, I will take care of your packages once the "Take" button starts to work again. Tomáš On Mon, Oct 5, 2020 at 4:29 PM Fabio Valentini wrote: > Hi everybody, > > I've decided to orphan poetry and some of its python dependencies. > > I don't actually use those packages myself (I've seen the light and > switched to Rust for my own projects), and maintaining them has become > a major headache with the upstream projects being very "special". > > Some of the packages are up-to-date, and the rest have pending pull > requests to update them to the latest version in preparation for > poetry 1.1.0 (which split off poetry/core directory into a separate > poetry-core / poetry.core python package, which will need to be > packaged separately , while taking care to not introduce conflicts > during packaging ...) > > - poetry > - python-CacheControl > - python-cleo > - python-clikit > - python-crashtest > - python-lockfile > - python-pastel > - python-pkginfo > - python-pylev > > I hope they can find a home with a packager who will give them the > love these packages do (or don't?) deserve. > > Fabio > ___ > 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 downgrades from fedora 32 -> fedora 33 (updated + annotated list inside)
On Tue, Oct 6, 2020 at 1:54 PM Ankur Sinha wrote: > > On Tue, Oct 06, 2020 13:48:34 +0200, Fabio Valentini wrote: > > > > With the impending final freeze for f33, should I open bugs for the > > packages with missing f33 builds and / or updates, so things can at > > least get fixed in time for zero-day updates? > > Yes please. I rely heavily on bugzilla now to poke me XD > > Thanks again for working on this Fabio. :) Sure, no problem :) - abseil-cpp is newer in 32 than in 33: 0:20200225.2-4.fc32 > 0:20200225.2-2.fc33 - abseil-cpp-devel is newer in 32 than in 33: 0:20200225.2-4.fc32 > 0:20200225.2-2.fc33 This one seems to be in a weird state. The newer version was successfully built for f33, but it's only tagged with f33-rebuild in koji. → https://bugzilla.redhat.com/show_bug.cgi?id=1885561 - appstream-data is newer in 32 than in 33: 0:32-8.fc32 > 0:32-7.fc33 This package has not been updated for fedora 33 yet (will this happen before the GA?) → https://bugzilla.redhat.com/show_bug.cgi?id=1882521 - bootupd is newer in 32 than in 33: 0:0.1.2-2.fc32 > 0:0.1.1-1.fc33 Built for f32+, but a bodhi update for f33 seems to be missing. → https://bugzilla.redhat.com/show_bug.cgi?id=1885567 - cdist is newer in 32 than in 33: 0:6.8.0-1.fc32 > 0:6.6.0-2.fc33 - cdist-doc is newer in 32 than in 33: 0:6.8.0-1.fc32 > 0:6.6.0-2.fc33 Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 have 6.8.0, but f33 doesn't. → https://bugzilla.redhat.com/show_bug.cgi?id=1885571 - clamtk is newer in 32 than in 33: 0:6.06-1.fc32 > 0:6.05-1.fc33 Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 have 6.06, but f33 doesn't. → https://bugzilla.redhat.com/show_bug.cgi?id=1885573 - cockpit-composer is newer in 32 than in 33: 0:24-1.fc32 > 0:23-1.fc33 Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 have version 24, but f33 doesn't. → https://bugzilla.redhat.com/show_bug.cgi?id=1885574 - knot is newer in 32 than in 33: 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 - knot-devel is newer in 32 than in 33: 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 - knot-doc is newer in 32 than in 33: 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 - knot-libs is newer in 32 than in 33: 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 - knot-utils is newer in 32 than in 33: 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 knot-3.0.0 was built for f33 and f34, but was unpushed from bodhi after getting negative karma due to it being an API / ABI (?) breaking update. Not sure if this had the desired effect, because the 3.0.0 update is already stable for EPEL7, EPEL8, and fedora 31, 32, and rawhide :) → https://bugzilla.redhat.com/show_bug.cgi?id=1885577 - legendary is newer in 32 than in 33: 0:0.20.1-2.fc32 > 0:0.20.1-1.fc33 This was built for f33, but it's missing a bodhi update. → https://bugzilla.redhat.com/show_bug.cgi?id=1885579 - libecpg is newer in 32 than in 33: 0:12.4-1.fc32 > 0:12.3-2.fc33 - libecpg-devel is newer in 32 than in 33: 0:12.4-1.fc32 > 0:12.3-2.fc33 - libpgtypes is newer in 32 than in 33: 0:12.4-1.fc32 > 0:12.3-2.fc33 Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 have version 12.4, but f33 doesn't. The f33 dist-git branch is also missing the corresponding commit. → https://bugzilla.redhat.com/show_bug.cgi?id=1885581 - libmediainfo is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 - libmediainfo-devel is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 - mediainfo is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 - mediainfo-gui is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 - mediainfo-qt is newer in 32 than in 33: 0:20.08-1.fc32 > 0:20.03-3.fc33 Updated builds for f33 seem to have been missed by the maintainer, all branches except f33 have version 20.08. → https://bugzilla.redhat.com/show_bug.cgi?id=1885583 - ncmpc is newer in 32 than in 33: 0:0.39-1.fc32 > 0:0.38-2.fc33 Updated builds for f33 seem to have been missed by the maintainer, all branches except f33 have version 0.39. → https://bugzilla.redhat.com/show_bug.cgi?id=1885584 - network-scripts-openvswitch is newer in 32 than in 33: 0:2.13.1-1.fc32 > 0:2.13.0-2.fc33 - openvswitch is newer in 32 than in 33: 0:2.13.1-1.fc32 > 0:2.13.0-2.fc33 - openvswitch-devel is newer in 32 than in 33: 0:2.13.1-1.fc32 > 0:2.13.0-2.fc33 - openvswitch-ipsec is newer in 32 than in 33: 0:2.13.1-1.fc32 > 0:2.13.0-2.fc33 - openvswitch-test is newer in 32 than in 33: 0:2.13.1-1.fc32 > 0:2.13.0-2.fc33 - python3-openvswitch is newer in 32 than in 33: 0:2.13.1-1.fc32 > 0:2.13.0-2.fc33 This was built for f33, but it's missing a bodhi update. → https://bugzilla.redhat.com/show_bug.cgi?id=1885587 - python-psycopg2-doc is newer in 32 than in 33: 0:2.8.6-1.fc32 > 0:2.8.5-3.fc33 - python3-psycopg2 is newer in 32 than in 33: 0:2.8.6-1.fc32 > 0:2.8.5-3.fc33 - python3-psycopg2-debug is newer in 32 than in 33: 0:2.8.6-1.fc32 > 0:2.8.5-3.fc33 -
Re: RPM package for gql
On Tue, 6 Oct 2020 02:30:10 -0400 Nico Kadel-Garcia wrote: > Why not look into the "pyprpm" tool to build a source RPM to start > with, to see if it has the dependency stack of doom common to some > other python modules? I think you meant "pyp2rpm". ___ 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: In which order does ELN build packages, what build root is it using?
On Fri, Oct 2, 2020 at 4:56 PM Sérgio Basto wrote: ... > BTW and since Orion also takes care of VTK package, why or how this > happen [1] ? why or how vtk-devel requires things that doesn't exist > (yet) in fedora-eln ? > > [1] > mock -r fedora-eln-x86_64 --install vtk-devel > > - nothing provides libjawt.so(SUNWprivate_1.1)(64bit) needed by vtk- > devel-8.2.0-17.eln103.x86_64 > Java is FTBFS in ELN right now; we're looking into it. > - nothing provides mysql-devel(x86-64) needed by vtk-devel-8.2.0- > 17.eln103.x86_64 > This might actually be a packaging mistake on the vtk side; it used to be that MariaDB had a virtual `Provides: mysql[-devel]` in it, but that is no longer the case. ___ 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: Follow-up - Please BuildRequire python3-setuptools explicitly
On Mon, Oct 5, 2020 at 6:56 AM Tomas Hrnciar wrote: > > Hello everyone, > > this is a follow-up email to the one I wrote a couple of months ago > (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GCPGM34ZGEOVUHSBGZTRYR5XKHTIJ3T7/). > sgallagh nodejs I've fixed this in the "14" branch (which gets synced to "master") so it will be in the next build. ___ 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: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved
OK, you convinced me: https://src.fedoraproject.org/rpms/systemd/pull-request/37. Let's see what others say. Zbyszek On Fri, Oct 02, 2020 at 12:34:32AM +0200, Marius Schwarz wrote: > Am 01.10.20 um 16:36 schrieb Alexander Bokovoy: > > > > You can also drop a configuration snippet in > > /etc/systemd/resolved.conf.d/ to contain > > > > FallbackDNS= > > > > This will disable global DNS servers for any case. > > > if that would be the default, it would be ok. > > Am 01.10.20 um 16:03 schrieb Michael Catanzaro: > > We are not going to patch out fallback to Cloudflare or Google because > > it is a non-issue. Fallback only happens when you have zero other DNS > > servers configured. When was the last time you connected to a network > > and there's no DHCP, no nothing? The number of users without some > > other working DNS is probably under 0.1%. > > BTW: thumbs up for the DOT proposal. > > I will make it very clear and easy: > > O== Situation for Germany > > GDPR is in place as a EU LAW. The protection rules are only active for > companies or organizations, not for private people. > > 2013 a german court (Kammergericht Berlin) ruled, that IP addresses are > Personal Data. It has never been overruled. > > Personal Data can only be send to none eu countries and corporations, if > there is a data protection law in place that has the same or better > level of protection as the eu law has ( or if it's necessary to buy > stuff (a house, car, whatever ). The pact the EU did with the US was > called Privacy Shield. It imploded (for the second time) a few months > ago. From the moment the eu court rule was public, transfer of personal > data into the us was illegal. > > If you send a DNS REQUEST to a US DNS server from within a company > network, and with ipv6 the internal ip is sent out i learned lately, you > have sent personal data which is protected under the GDRP. It's not > unlikely to use company pcs for private webvisits while having a meal > break. > > Therefor, a os that has google and cloudflare as a default, even if it's > unlikely to happen as you point out, which sends out dns with personal > data in it to a us dns server, brings the company in great trouble with > the law. In the end, this means, you as a company/org need to pay a > (possibly) shitload of money as a fine and therefor they can't use this > os anymore. (someone else on the list pointed this out too.) The > consequence is, Fedora is a juristic risk. [The fine is higher, if you > as corp/org did not document this data transfer in your data protection > memos] Of course a working dns setup will prevent this problem, but > thats not the point. Activists in germany and other countries try to get > more and more gov projects to OSS due to privacy issues with M$. It > would be a shame if Fedora would also count as a potential problem. > > Do we all really want this, for the benefit on 0.1%(as you say) have a > dns lookup instead of a hint, that their systems are broken? > > Pls remember: I'm just the messenger, Í didn't write the laws ;) > > Funfact: last time I checked the northern germany police pc in my city, > they used a fedora based desktop system. I like that fact :D But i'm > pretty sure, they don't like a cloudflare fallback dns once they reach > F33 ( if ever ). > > > > best regards, > Marius Schwarz > ___ > 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 downgrades from fedora 32 -> fedora 33 (updated + annotated list inside)
On Tue, Oct 06, 2020 13:48:34 +0200, Fabio Valentini wrote: > > With the impending final freeze for f33, should I open bugs for the > packages with missing f33 builds and / or updates, so things can at > least get fixed in time for zero-day updates? Yes please. I rely heavily on bugzilla now to poke me XD Thanks again for working on this Fabio. :) -- 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: Bodhi failed to get a resource from PDC ...
Hello, On Tue, Oct 06, 2020 13:43:57 +0200, Michael Schwendt wrote: > Bodhi fails with this error message. Any suggestion on how to continue? > > Builds : Unable to create update. > Bodhi failed to get a resource from PDC at the following URL > "https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=true_path=true=global_component=f32_size=100=rpm_component=claws-mail;. > The status code was "503". > The error was "". This is reported here: https://pagure.io/fedora-infrastructure/issue/9376 Being looked into. -- 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: Package downgrades from fedora 32 -> fedora 33 (updated + annotated list inside)
On Sat, Oct 3, 2020 at 12:53 AM Fabio Valentini wrote: > > Hi everybody, > > I've compiled an updated list of package downgrades when comparing > fedora 32 to fedora 33. Note that a lot of packages were either not > built for f33 at all (packagers missing the branch point?), or had no > bodhi update created for updates (packagers missing the bodhi > activation point?). > > I tried to annotate the list of downgrades with my most likely > explanation (according to information visible in dist-git, koji, > bodhi, and RHBZ). Surprisingly, the list of downgrades caused by FTBFS > issues on fedora 33+ is very short. > > For the packages that are obviously simply missing a koji build and/or > a corresponding bodhi update, should we attempt to fix the obvious > packager oversights? > > --- > > - abseil-cpp is newer in 32 than in 33: > 0:20200225.2-4.fc32 > 0:20200225.2-2.fc33 > - abseil-cpp-devel is newer in 32 than in 33: > 0:20200225.2-4.fc32 > 0:20200225.2-2.fc33 > > This one seems to be in a weird state. The newer version was successfully > built > for f33, but it's only tagged with f33-rebuild in koji. > > - apcupsd is newer in 32 than in 33: > 0:3.14.14-18.fc32 > 0:3.14.14-17.fc32 > - apcupsd-cgi is newer in 32 than in 33: > 0:3.14.14-18.fc32 > 0:3.14.14-17.fc32 > - apcupsd-gui is newer in 32 than in 33: > 0:3.14.14-18.fc32 > 0:3.14.14-17.fc32 > > This is caused by apcupsd being FTBFS for fedora 33+. > > - appstream-data is newer in 32 than in 33: > 0:32-8.fc32 > 0:32-7.fc33 > > This package has not been updated for fedora 33 yet (will this happen before > the GA?) > > - bootupd is newer in 32 than in 33: > 0:0.1.2-2.fc32 > 0:0.1.1-1.fc33 > > Built for f32+, but a bodhi update for f33 seems to be missing. > > - cdist is newer in 32 than in 33: > 0:6.8.0-1.fc32 > 0:6.6.0-2.fc33 > - cdist-doc is newer in 32 than in 33: > 0:6.8.0-1.fc32 > 0:6.6.0-2.fc33 > > Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 > have 6.8.0, but f33 doesn't. > > - clamtk is newer in 32 than in 33: > 0:6.06-1.fc32 > 0:6.05-1.fc33 > > Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 > have 6.8.0, but f33 doesn't. > > - cockpit-composer is newer in 32 than in 33: > 0:24-1.fc32 > 0:23-1.fc33 > > Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 > have version 24, but f33 doesn't. > > - firefox-pkcs11-loader is newer in 32 than in 33: > 0:3.13.6-1.fc32 > 0:3.13.4-1.fc32 > > This is caused by firefox-pkcs11-loader being FTBFS for fedora 33+. > > - golang-github-willf-bitset-devel is newer in 32 than in 33: > 0:1.1.11-1.fc32 > 0:1.1.10-5.fc33 > > Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 > have version 1.1.11, but f33 doesn't. > > - hyperscan is newer in 32 than in 33: > 0:5.3.0-1.fc32 > 0:5.2.1-2.fc32 > - hyperscan-devel is newer in 32 than in 33: > 0:5.3.0-1.fc32 > 0:5.2.1-2.fc32 > > This is caused by hyperscan being FTBFS for fedora 33+. The FTBFS bug was > closed, but no fixed builds for f33+ were attempted. > > - knot is newer in 32 than in 33: > 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 > - knot-devel is newer in 32 than in 33: > 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 > - knot-doc is newer in 32 than in 33: > 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 > - knot-libs is newer in 32 than in 33: > 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 > - knot-utils is newer in 32 than in 33: > 0:3.0.0-1.fc32 > 0:2.9.6-1.fc33 > > knot-3.0.0 was built for f33 and f34, but was unpushed from bodhi after > getting negative karma due to it being an API / ABI (?) breaking update. > Not sure if this had the desired effect, because the 3.0.0 update is already > stable for EPEL7, EPEL8, and fedora 31, 32, and rawhide :) > > - legendary is newer in 32 than in 33: > 0:0.20.1-2.fc32 > 0:0.20.1-1.fc33 > > This was built for f33, but it's missing a bodhi update. > > - libecpg is newer in 32 than in 33: > 0:12.4-1.fc32 > 0:12.3-2.fc33 > - libecpg-devel is newer in 32 than in 33: > 0:12.4-1.fc32 > 0:12.3-2.fc33 > - libpgtypes is newer in 32 than in 33: > 0:12.4-1.fc32 > 0:12.3-2.fc33 > > Updated builds for f33 seem to have been missed by the maintainer, f34 and f32 > have version 12.4, but f33 doesn't. The f33 dist-git branch is also missing > the > corresponding commit. > > - libmediainfo is newer in 32 than in 33: > 0:20.08-1.fc32 > 0:20.03-3.fc33 > - libmediainfo-devel is newer in 32 than in 33: > 0:20.08-1.fc32 > 0:20.03-3.fc33 > - mediainfo is newer in 32 than in 33: > 0:20.08-1.fc32 > 0:20.03-3.fc33 > - mediainfo-gui is newer in 32 than in 33: > 0:20.08-1.fc32 > 0:20.03-3.fc33 > - mediainfo-qt is newer in 32 than in 33: > 0:20.08-1.fc32 > 0:20.03-3.fc33 > > Updated builds for f33 seem to have been missed by the maintainer, all > branches > except f33 have version 20.08. > > - mingw32-mediawriter is newer in 32 than in 33: > 0:4.1.6-1.fc32 > 0:4.1.5-1.fc33 > - mingw64-mediawriter is newer in 32 than in 33: >
Bodhi failed to get a resource from PDC ...
Bodhi fails with this error message. Any suggestion on how to continue? Builds : Unable to create update. Bodhi failed to get a resource from PDC at the following URL "https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=true_path=true=global_component=f32_size=100=rpm_component=claws-mail;. The status code was "503". The error was "". ___ 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 1885368] perl-Digest-MD5-2.58 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885368 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1885423] perl-File-Listing-6.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885423 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-File-Listing-6.11-1.fc ||34 --- Comment #3 from Petr Pisar --- An enhancement release safer for Rawhide only. Besides refactoring code, it also changes how years are passed to Time::Local. -- 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 1885423] perl-File-Listing-6.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885423 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32/33 livedisks do not boot on M$ system(s)
Am 06.10.20 um 01:50 schrieb Chris Murphy: > In this case you can replace it by just copying a substitute > grubx64.efi to the proper location on the USB stick... which might be > EFI/BOOT, I'd have to poke it with a stick to find out. > > I already tried to replace it with a f31 one, it did not help at all. The difference must be something else: a block signature, blockloader, mbr whatever is used on an efi bios with secure boot disabled before that file is loaded. I did not try to boot it with secure boot enabled, maybe i should test that. Best regards, Marius ___ 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: Could Bodhi create some temporary repositories before composes are ready?
Il 06/10/20 09:15, Pavel Raiskup ha scritto: > The KMail app stopped working for me today, and I realized there's > update to which I'd like to give a try: > >https://bodhi.fedoraproject.org/updates/FEDORA-2020-15d324f87c > > In Bodhi, the suggested command to test this update is: > >sudo dnf upgrade --enablerepo=updates-testing > --advisory=FEDORA-2020-15d324f87c > > But that doesn't work because the mirrored updates-testing is not > yet updated. And downloading all the builds manually from Koji > is just too much work ATM. You can let Bodhi client download the builds for you: bodhi updates download --updateid FEDORA-2020-15d324f87c Then dnf install the downloaded builds. > Would it be possible to enhance Bodhi so it provides the repositories > somewhere in the meantime, before composes are ready? > This is not the first time I'd found this feature very convenient. > Very unlikely. That would mean to provide some (a lot of) extra space somewhere. Moreover, Bodhi development workforce is way under the needs... you can try to open a ticket upstream, but that will likely pile up with many others. Mattia ___ 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: build rpm from spec file fails on fedora-eln-armhfp
Ok, Thanks! Pavel Raiskup 于2020年10月6日周二 下午3:24写道： > On Tuesday, October 6, 2020 5:24:09 AM CEST Ruki Wang wrote: > > Thanks, but now all fedora-eln-* failed. > > > > https://copr.fedorainfracloud.org/coprs/waruqi/xmake/build/1695687/ > > > > warning: > /var/lib/mock/fedora-eln-x86_64-1601952807.335959/root/var/cache/dnf/eln-78c0f68aeb10b59c/packages/krb5-libs-1.18.2-24.eln104.x86_64.rpm: > > Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY > > Fedora ELN - Developmental modular packages for 1.6 MB/s | 1.6 kB > 00:00 > > GPG key at > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > (0x9570FF31) is already installed > > The GPG keys listed for the "Fedora ELN - Developmental modular > > packages for the next Enterprise Linux release" repository are already > > installed but they are not correct for this package. > > Check that the correct key URLs are configured for this repository.. > > Failing package is: krb5-libs-1.18.2-24.eln104.x86_64 > > GPG Keys are configured as: > > > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > Public key for redhat-rpm-config-175-1.eln104.noarch.rpm is not > > installed. Failing package is: redhat-rpm-config-175-1.eln104.noarch > > GPG Keys are configured as: > > > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > Public key for rpm-4.16.0-2.eln104.x86_64.rpm is not installed. > > Failing package is: rpm-4.16.0-2.eln104.x86_64 > > GPG Keys are configured as: > > > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > Public key for rpm-build-4.16.0-2.eln104.x86_64.rpm is not installed. > > Failing package is: rpm-build-4.16.0-2.eln104.x86_64 > > GPG Keys are configured as: > > > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > Public key for rpm-build-libs-4.16.0-2.eln104.x86_64.rpm is not > > installed. Failing package is: rpm-build-libs-4.16.0-2.eln104.x86_64 > > GPG Keys are configured as: > > > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > Public key for rpm-libs-4.16.0-2.eln104.x86_64.rpm is not installed. > > Failing package is: rpm-libs-4.16.0-2.eln104.x86_64 > > GPG Keys are configured as: > > > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > Error: GPG check FAILED > > The ELN repo is not mirrored ATM (see discussion [1]), so it is likely > we'll see > some temporary issues like that. Copr/Mock can not do anything sane about > this. > Please re-try the build. > > [1] > https://github.com/rpm-software-management/mock/issues/614#issuecomment-671405333 > > Pavel > > On Monday, October 5, 2020 9:41:44 AM CEST Pavel Raiskup wrote: > > On Monday, October 5, 2020 9:23:14 AM CEST Florian Weimer wrote: > > > * Ruki Wang: > > > > > > > Errors during downloading metadata for repository 'eln': > > > > - Status code: 404 for > https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/compose/Everything/armhfp/os/repodata/repomd.xml > (IP: 67.219.144.68) > > > > > > Looks like COPR is still trying to build ELN on armhfp, but it's not > > > longer available. > > > > > > I believe there is a checkbox in the COPR web UI you can untick, but > > > eventually, this has to be adjusted by the COPR administrators. > > > > Thanks for the reminder. The chroot has just been deactivated in Copr. > > > > Pavel > > > > > Thanks, > > > Florian > > > -- > > > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, > Michael O'Neill > > > ___ > > > 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 > > > > > > > -- Ruki Wang war...@gmail.com https://github.com/waruqi https://twitter.com/waruqi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
[Bug 1885219] perl-Devel-CheckOS-1.84 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885219 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1885121] perl-CGI-4.51 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885121 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CGI-4.51-1.fc34 Resolution|--- |RAWHIDE Last Closed||2020-10-06 08:07:55 -- 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 1885121] perl-CGI-4.51 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885121 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1885000] perl-ExtUtils-MakeMaker-7.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885000 --- Comment #1 from Fedora Update System --- FEDORA-2020-8be581dc39 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8be581dc39 --- Comment #3 from Fedora Update System --- FEDORA-2020-11513a4a33 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-11513a4a33 -- 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 1885000] perl-ExtUtils-MakeMaker-7.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885000 --- Comment #1 from Fedora Update System --- FEDORA-2020-8be581dc39 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8be581dc39 -- 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 1885000] perl-ExtUtils-MakeMaker-7.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1885000 --- Comment #1 from Fedora Update System --- FEDORA-2020-8be581dc39 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8be581dc39 --- Comment #3 from Fedora Update System --- FEDORA-2020-11513a4a33 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-11513a4a33 --- Comment #3 from Fedora Update System --- FEDORA-2020-3791de1048 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-3791de1048 -- 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: Could Bodhi create some temporary repositories before composes are ready?
On Tuesday, October 6, 2020 8:15:24 AM WEST Pavel Raiskup wrote: > The KMail app stopped working for me today, and I realized there's > update to which I'd like to give a try: > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-15d324f87c If you had installed the previous update to kde apps: https://bodhi.fedoraproject.org/updates/FEDORA-2020-94522cc2fa I had the same problem and downgrading just kaccounts-integration, kaccounts- providers and ktp-accounts-kcm and restarting akonadi was enough to have akonadi/kmail working again. > In Bodhi, the suggested command to test this update is: > > sudo dnf upgrade --enablerepo=updates-testing > --advisory=FEDORA-2020-15d324f87c > But that doesn't work because the mirrored updates-testing is not > yet updated. And downloading all the builds manually from Koji > is just too much work ATM. > > Would it be possible to enhance Bodhi so it provides the repositories > somewhere in the meantime, before composes are ready? > This is not the first time I'd found this feature very convenient. For the same reason, the same update, that is feature that I would like to have. :-) > Pavel -- José Abílio___ 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: build rpm from spec file fails on fedora-eln-armhfp
On Tuesday, October 6, 2020 5:24:09 AM CEST Ruki Wang wrote: > Thanks, but now all fedora-eln-* failed. > > https://copr.fedorainfracloud.org/coprs/waruqi/xmake/build/1695687/ > > warning: > /var/lib/mock/fedora-eln-x86_64-1601952807.335959/root/var/cache/dnf/eln-78c0f68aeb10b59c/packages/krb5-libs-1.18.2-24.eln104.x86_64.rpm: > Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY > Fedora ELN - Developmental modular packages for 1.6 MB/s | 1.6 kB 00:00 > GPG key at > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > (0x9570FF31) is already installed > The GPG keys listed for the "Fedora ELN - Developmental modular > packages for the next Enterprise Linux release" repository are already > installed but they are not correct for this package. > Check that the correct key URLs are configured for this repository.. > Failing package is: krb5-libs-1.18.2-24.eln104.x86_64 > GPG Keys are configured as: > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > Public key for redhat-rpm-config-175-1.eln104.noarch.rpm is not > installed. Failing package is: redhat-rpm-config-175-1.eln104.noarch > GPG Keys are configured as: > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > Public key for rpm-4.16.0-2.eln104.x86_64.rpm is not installed. > Failing package is: rpm-4.16.0-2.eln104.x86_64 > GPG Keys are configured as: > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > Public key for rpm-build-4.16.0-2.eln104.x86_64.rpm is not installed. > Failing package is: rpm-build-4.16.0-2.eln104.x86_64 > GPG Keys are configured as: > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > Public key for rpm-build-libs-4.16.0-2.eln104.x86_64.rpm is not > installed. Failing package is: rpm-build-libs-4.16.0-2.eln104.x86_64 > GPG Keys are configured as: > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > Public key for rpm-libs-4.16.0-2.eln104.x86_64.rpm is not installed. > Failing package is: rpm-libs-4.16.0-2.eln104.x86_64 > GPG Keys are configured as: > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > Error: GPG check FAILED The ELN repo is not mirrored ATM (see discussion [1]), so it is likely we'll see some temporary issues like that. Copr/Mock can not do anything sane about this. Please re-try the build. [1] https://github.com/rpm-software-management/mock/issues/614#issuecomment-671405333 Pavel On Monday, October 5, 2020 9:41:44 AM CEST Pavel Raiskup wrote: > On Monday, October 5, 2020 9:23:14 AM CEST Florian Weimer wrote: > > * Ruki Wang: > > > > > Errors during downloading metadata for repository 'eln': > > > - Status code: 404 for > > > https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/compose/Everything/armhfp/os/repodata/repomd.xml > > > (IP: 67.219.144.68) > > > > Looks like COPR is still trying to build ELN on armhfp, but it's not > > longer available. > > > > I believe there is a checkbox in the COPR web UI you can untick, but > > eventually, this has to be adjusted by the COPR administrators. > > Thanks for the reminder. The chroot has just been deactivated in Copr. > > Pavel > > > Thanks, > > Florian > > -- > > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > > Commercial register: Amtsgericht Muenchen, HRB 153243, > > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael > > O'Neill > > ___ > > 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 > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned few more java packages that FTBFS
Hi all, I orphaned few more java packages that do not build and I do not have any use for them anymore: apache-commons-configuration hsqldb1 jboss-jsf-2.1-api jsonp metadata-extractor2 Feel free to take them if you need them. Regards, -- Jakub Jelen Senior Software Engineer Crypto Team, Security Engineering 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://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
