[EPEL-devel] Fedora EPEL 8 updates-testing report

The following Fedora EPEL 8 Security updates need testing: Age URL 14 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-03d5f14bbe chromium-81.0.4044.138-1.el8 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d41abf072 perl-Mojolicious-8.42-1.el8 8

[Bug 1838904] perl-perlfaq-5.20200523 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1838904 --- Comment #8 from Fedora Update System --- FEDORA-2020-1a910e5253 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

[Bug 1838904] perl-perlfaq-5.20200523 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1838904 --- Comment #7 from Fedora Update System --- FEDORA-2020-6471c56f67 has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade

Re: Location of executable code

On Fri, May 22, 2020 at 3:20 PM David Malcolm wrote: > Hi Steve > > Your email talks about "application whitelisting" and "executables", > and this thread seems to be getting in to the weeds about things like > the distinction between scripts vs machine code, and modules vs > scripts; code vs

[Bug 1838904] perl-perlfaq-5.20200523 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1838904 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #6 from

[389-devel] 389 DS nightly 2020-05-23 - 94% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/23/report-389-ds-base-1.4.4.2-20200522gitc350ddc.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

Re: fedpkg fork broken?

I figured out my problem, it's the whole confusing what's part of src.fedoraproject.org and what's part of pagure.io... You need both tokens for different actions but one goes in: [fedpkg.pagure] token = [fedpkg.distgit] token = Thanks, Richard ___

Re: Location of executable code

Hello, On Friday, May 22, 2020 6:38:55 PM EDT Kevin Kofler wrote: > > But what I'm finding in practice is that cinnamon places its javascript > > there, there are libexec dirs that contain executable code, there are > > python and byte compiled python over there. In short, the system doesn't > >

Re: The price of FHS

On 5/22/20 8:48 PM, Parker Gibson wrote: The issue I see is that no package management system I know of handles multiple so versions, they explicitly state packages conflict with each-other even if in principle the so versioning means they would not. The example I gave is from my own system.

Re: fedpkg fork broken?

On Sat, May 23, 2020 at 02:19:07AM +0200, Aleksandra Fedorova wrote: > > I've got the same problem. I think it uses wrong remote path: > > a...@pkgs.fedoraproject.org > > Maybe it was working before, but then certain update happened. So, just to clarify a confusing situation... :)

Re: The price of FHS

The issue I see is that no package management system I know of handles multiple so versions, they explicitly state packages conflict with each-other even if in principle the so versioning means they would not. Some repositories can handle multiple major so versions and I do think this may

[Test-Announce] 2020-05-25 @ 15:00 UTC - Fedora QA Meeting

# Fedora Quality Assurance Meeting # Date: 2020-05-25 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! We didn't meet last week, and there's some stuff to follow up on from the previous meeting, so let's

Re: The price of FHS

On Fri, May 22, 2020 at 4:37 PM Stephen John Smoogen wrote: > > > > On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel > wrote: >> >> The File Hierarchy Standard (FHS), is a standard that define where the >> files of a package should be placed in the root directory of the >> systems. It

Re: fedpkg fork broken?

On Mon, 18 May 2020, 14:18 Richard Shaw, wrote: > I'm trying this for the first time (hadn't even noticed it was there!). > I've been using the src.fp.o github style forking from the web. > > I cloned a random project of mine and then tried: > $ fedpkg fork > Could not execute do_distgit_fork:

Re: The price of FHS

On 5/22/20 6:23 PM, Paul Dufresne via devel wrote: So let's take an example: At first you have: /pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains /pkgs/libX_version1 /pkgs/libX_version1 contains libX, version 1. Now you "upgrade" libX vesion 2... because each packages is in

Re: Location of executable code

On 5/22/20 3:54 PM, Michel Alexandre Salim wrote: On 5/22/20 7:30 AM, Steve Grubb wrote: Hello, I am working on our application whitelisting daemon. It uses the rpmdb to derive trust in what's on disk. If we use the whole rpmdb, then the number of files is large. So, to prune the amount of

Re: Location of executable code

On 5/22/20 7:30 AM, Steve Grubb wrote: Hello, I am working on our application whitelisting daemon. It uses the rpmdb to derive trust in what's on disk. If we use the whole rpmdb, then the number of files is large. So, to prune the amount of entries in the trust db down to a reasonable number, I

Re: Location of executable code

Steve Grubb wrote: > But what I'm finding in practice is that cinnamon places its javascript > there, there are libexec dirs that contain executable code, there are > python and byte compiled python over there. In short, the system doesn't > work because critical executables are in /usr/share. >

[Bug 1839251] perl-Regexp-Grammars-1.057 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1839251 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Regexp-Grammars-1.056

Re: The price of FHS

On 5/22/20 4:22 PM, Parker Gibson wrote: I don’t think this is specifically about FHS as it is about shared library management. The underlying hierarchy defined in FHS doesn’t make the dictations about version management that you seem to indicate, nor are the major problems with maintaining

Re: Aggressive updating (Python 3.9): Are we trying to hard?

Miroslav Suchý wrote: > Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a): >> Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8. But >> instead of asking ourselves, "should we push in the VERY latest Python >> and hope it's ok?", we just patch the build system to accept it anyway >>

LLVMgold.so: wrong ELF class: ELFCLASS32

Hi I'm seeing this when running nm nm: /usr/bin/../bin/../lib/bfd-plugins/LLVMgold.so: wrong ELF class: ELFCLASS32 I do indeed have both llvm-libs.i686 as well as llvm-libs.x86_64 installed. Looks like someone is picking up LLVMgold.so from the wrong libdir? Possibly something to report

Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

Am 22.05.20 um 23:16 schrieb Felix Schwarz: > We should push broken updates to EPEL 7/F31. obviously this should read "We should NOT push broken updates" ;-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

[EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

Am 22.05.20 um 23:16 schrieb Felix Schwarz: > We should push broken updates to EPEL 7/F31. obviously this should read "We should NOT push broken updates" ;-) ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email

Re: [EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

Hey, seems like you already built libb2? I hoped we could coordinate the update a bit more so there won't be any breakage. I just added buildroot override (still waiting for it to become active) and I can rebuild borgbackup. I hoped you could do the koji build and then dependent packages would

[EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

Hey, seems like you already built libb2? I hoped we could coordinate the update a bit more so there won't be any breakage. I just added buildroot override (still waiting for it to become active) and I can rebuild borgbackup. I hoped you could do the koji build and then dependent packages would

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

Hi Sérgio, Sérgio Basto writes: > Hi, > > On Tue, 2020-04-14 at 11:09 +0100, Peter Robinson wrote: >> > On 14. 04. 20 11:06, Miro Hrončok wrote: >> > > The following packages are orphaned... >> > > >> > > GConf2alexl, caillon, >> > > caolanm, 1 weeks ago >>

[Bug 1839251] New: perl-Regexp-Grammars-1.056 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1839251 Bug ID: 1839251 Summary: perl-Regexp-Grammars-1.056 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Regexp-Grammars Keywords: FutureFeature,

Re: Location of executable code

On Friday, May 22, 2020 3:19:20 PM EDT David Malcolm wrote: > Your email talks about "application whitelisting" and "executables", > and this thread seems to be getting in to the weeds about things like > the distinction between scripts vs machine code, and modules vs > scripts; code vs data. But

Re: Location of executable code

On Friday, May 22, 2020 4:23:50 PM EDT Przemek Klosowski via devel wrote: > On 5/22/20 1:24 PM, Nico Kadel-Garcia wrote: > > > On Fri, May 22, 2020 at 10:31 AM Steve Grubb wrote: > > > >> I am working on our application whitelisting daemon. > > Interesting concept---could you please elaborate

Re: Self Introduction: Andrzej Bylicki (Andy Mender)

HI Andy! On Tue, 19 May 2020 at 15:55, Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > Hello, Andy! > > On Monday, 18 May 2020 at 22:37, Andy Mender wrote: > > Hello everyone! > > > > Introduction: > > After reading the Fedora docs on packaging, I decided I would like to > join

Re: The price of FHS

On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel < devel@lists.fedoraproject.org> wrote: > The File Hierarchy Standard (FHS), is a standard that define where the > files of a package should be placed in the root directory of the > systems. It probably did not change much since the beginning

Re: Location of executable code

On 5/22/20 1:24 PM, Nico Kadel-Garcia wrote: On Fri, May 22, 2020 at 10:31 AM Steve Grubb wrote: I am working on our application whitelisting daemon. Interesting concept---could you please elaborate on your design? It sounds useful but also challenging, as Nico points out. On what level

Re: The price of FHS

I don’t think this is specifically about FHS as it is about shared library management. The underlying hierarchy defined in FHS doesn’t make the dictations about version management that you seem to indicate, nor are the major problems with maintaining multiple api compatible versions of shared

The price of FHS

The File Hierarchy Standard (FHS), is a standard that define where the files of a package should be placed in the root directory of the systems. It probably did not change much since the beginning of Unix, and it make files be placed where users, developers and administrators expect them to

[389-devel] please review: PR 51111 - Fix ASAN ODR warnings

https://pagure.io/389-ds-base/pull-request/5 -- 389 Directory Server Development Team ___ 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:

Re: Location of executable code

On Fri, 22 May 2020 at 15:20, David Malcolm wrote: > On Fri, 2020-05-22 at 10:30 -0400, Steve Grubb wrote: > > Hello, > > > > I am working on our application whitelisting daemon. It uses the > > rpmdb to > > derive trust in what's on disk. If we use the whole rpmdb, then the > > number of > >

Re: Location of executable code

On Fri, 2020-05-22 at 10:30 -0400, Steve Grubb wrote: > Hello, > > I am working on our application whitelisting daemon. It uses the > rpmdb to > derive trust in what's on disk. If we use the whole rpmdb, then the > number of > files is large. So, to prune the amount of entries in the trust db >

Re: Location of executable code

Le vendredi 22 mai 2020 à 10:30 -0400, Steve Grubb a écrit : > The /usr/share hierarchy is for all read-only architecture > independent data > files. The important part of the FHS definition is “read-only architecture independent“. Because everything on computing storage is data depending on how

Re: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)

On Thu, May 21, 2020 at 18:46:14 -0400, Dennis Payne wrote: The reason for the crashing on startup is that it is not loading the font. I have fixes for this out. Even though this currently just affects rawhide, I have fixed builds for f31 and f32 as well, so if a font file moves a simple

Re: Increasing the packaging team: regular workshops/vFADs/classroom sessions on packaging

Hello, As part of the marketing team, I think we could put a community campaign, with a video series (series means at least 3) posted properly on YouTube and promoted by Twitter, CommBlog and ML: "Package with us!" Wdyt! Br, El jue., 21 may. 2020 a las 6:12, Ankur Sinha () escribió: > On

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 20:05, Adam Williamson wrote: On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote: On 22. 05. 20 19:23, Adam Williamson wrote: So a request here: once the rebuilds are done, before we consider moving them to Rawhide proper, can we have releng run a test compose using the side

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 2020-05-22 at 19:57 +0200, Miro Hrončok wrote: > On 22. 05. 20 19:23, Adam Williamson wrote: > > So a request here: once the rebuilds are done, before we consider > > moving them to Rawhide proper, can we have releng run a test compose > > using the side tag and run openQA on it, to test

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 19:23, Adam Williamson wrote: So a request here: once the rebuilds are done, before we consider moving them to Rawhide proper, can we have releng run a test compose using the side tag and run openQA on it, to test for bugs in the installer or key critpath components caused by the

Re: looking for scipy on python 3.8 (RISCV Fedora Release 32)

On Fri, May 22, 2020 at 5:57 PM Arun Sukumaran Latha wrote: > > Thanks David for looking into the same. > > One more package I would need help build in fedora riscv for ultimately > getting tensorflow compiled. > > The other dependency is: > h5py<2.11.0,>=2.10.0 > > I did try getting the latest

Re: TeXLive 2020 landing in rawhide

On 22. 05. 20 13:51, Fabio Valentini wrote: According to koschei, the graphite2 BuildRequires now pull in *about 300 more (tex + perl) packages than before the 2020 update*, which is slightly concerning? See:https://koschei.fedoraproject.org/build/8369713 I also believe this makes the Python

Re: Location of executable code

* Petr Viktorin: > Does "read-only architecture independent data" mean the files must not > be programs? Not according to the FHS. From the FHS perspective, /usr/share is just like RPM's noarch architecture: completely portable across all architectures. It can even be machine code if it does

Re: Location of executable code

On Fri, May 22, 2020 at 10:31 AM Steve Grubb wrote: > > Hello, > > I am working on our application whitelisting daemon. It uses the rpmdb to > derive trust in what's on disk. If we use the whole rpmdb, then the number of > files is large. So, to prune the amount of entries in the trust db down to

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 2020-05-22 at 03:06 +0200, Miro Hrončok wrote: > Hello, in order to deliver Python 3.9, we are running a coordinated rebuild > in a > side tag. > > https://fedoraproject.org/wiki/Changes/Python3.9 > > If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, >

Re: Location of executable code

On 2020-05-22 17:31, Steve Grubb wrote: On Friday, May 22, 2020 10:39:43 AM EDT Petr Viktorin wrote: On 2020-05-22 16:30, Steve Grubb wrote: Hello, I am working on our application whitelisting daemon. It uses the rpmdb to derive trust in what's on disk. If we use the whole rpmdb, then the

Re: fwupd / LVFS RFE: classifying updates?

On 5/20/20 11:15 AM, Richard Hughes wrote: On Wed, May 20, 2020 at 6:58 PM Michel Alexandre Salim wrote: For normal packages, we just set up dnf-automatic to automatically apply security updates. Would it be possible to flag critical/security firmware updates so that we can just create a

Re: Koji build failure misattribution - root.log instead of build.log?

On 5/20/20 4:26 PM, Adam Williamson wrote: On Wed, 2020-05-20 at 16:15 -0700, Adam Williamson wrote: On Thu, 2020-05-21 at 00:26 +0200, Pavel Raiskup wrote: On Wednesday, May 20, 2020 11:43:10 PM CEST Michel Alexandre Salim wrote: Hi, I often notice that my scratch build right after updating

Re: TeXLive 2020 landing in rawhide

On Friday, 22 May 2020 12.51.26 WEST Fabio Valentini wrote: > Also, the build now fails with "! LaTeX Error: File `hanging.sty' not > found.". graphite2 sources do not contain any .tex files, but > graphite2 uses LaTeX / pdf output when building documentation / manual > with doxygen, so I'm

Re: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)

On Fri, May 22, 2020 at 09:56:48 -0500, Bruno Wolff III wrote: On Fri, May 22, 2020 at 09:03:31 -0500, Bruno Wolff III wrote: I'll look harder to see if I can get a copy of 3.67. It isn't available any more from where I got it and I may have lost the copy I had downloaded to evalute a

Re: Heads up: gdal-3.1.0 coming to rawhide

On 21.05.20 00:55, Sandro Mani wrote: Hi I'm building gdal-3.1.0 in a f33 side-tag, and I'll also rebuild all dependencies: bes cloudcompare dans-gdal-scripts gazebo GMT grass gtatool liblas mapnik mapserver merkaartor ncl nodejs-gdal opencv OpenSceneGraph osgearth postgis python-fiona

Re: Location of executable code

On Friday, May 22, 2020 10:39:43 AM EDT Petr Viktorin wrote: > On 2020-05-22 16:30, Steve Grubb wrote: > > Hello, > > > > I am working on our application whitelisting daemon. It uses the rpmdb to > > derive trust in what's on disk. If we use the whole rpmdb, then the > > number of files is large.

Re: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)

On Fri, May 22, 2020 at 09:56:48 -0500, Bruno Wolff III wrote: On Fri, May 22, 2020 at 09:03:31 -0500, Bruno Wolff III wrote: I'll look harder to see if I can get a copy of 3.67. It isn't available any more from where I got it and I may have lost the copy I had downloaded to evalute a

Re: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)

On Fri, May 22, 2020 at 09:03:31 -0500, Bruno Wolff III wrote: I'll look harder to see if I can get a copy of 3.67. It isn't available any more from where I got it and I may have lost the copy I had downloaded to evalute a number of years ago. There is some source code archived at:

Re: looking for scipy on python 3.8 (RISCV Fedora Release 32)

Thanks David for looking into the same. One more package I would need help build in fedora riscv for ultimately getting tensorflow compiled. The other dependency is: h5py<2.11.0,>=2.10.0 I did try getting the latest one available at http://fedora.riscv.rocks/koji/buildinfo?buildID=149390, but

Re: Location of executable code

On 2020-05-22 16:30, Steve Grubb wrote: Hello, I am working on our application whitelisting daemon. It uses the rpmdb to derive trust in what's on disk. If we use the whole rpmdb, then the number of files is large. So, to prune the amount of entries in the trust db down to a reasonable number,

Retiring nodejs-marked

I retired nodejs-marked yesterday, as it was a duplicate of the "marked" package, which wasn't caught at the time I packaged it. -- Jared Smith ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Location of executable code

Hello, I am working on our application whitelisting daemon. It uses the rpmdb to derive trust in what's on disk. If we use the whole rpmdb, then the number of files is large. So, to prune the amount of entries in the trust db down to a reasonable number, I thought we could jettison anything in

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 2020-05-22 13:59, Tomasz Kłoczko wrote: On Fri, 22 May 2020 at 12:02, Miro Hrončok > wrote: On 22. 05. 20 12:43, Tomasz Kłoczko wrote: > [mode=serious] > On making transition from 3.8.x to 3.9.x all what would be necessary to do would > be

glassfish-hk2 - orphaning event notification

After much trimming, pruning, and hair-pulling by our fearless leader, glassfish-hk2 was determined to be a spurious dependency which Fabio replaced with one line of `sed` magic. Please see: https://pagure.io/stewardship-sig/issue/91 If anyone is interested in taking this package back for

Re: [games-sig] Re: Intent to retire nethack-vultures (Vulture's Eye and Vulture's Claw)

Copying me directory was a good idea to get my attention. Fedora list mail goes to another folder and it is easy for me to miss stuff, though I was planning to double check this thread for objections before doing a retire. On Thu, May 21, 2020 at 18:46:14 -0400, Dennis Payne wrote: The

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22/05/20 14:49 +0200, Miro Hrončok wrote: On 22. 05. 20 13:06, Miro Hrončok wrote: Could you give me the list of packages? Is it this? $ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$ I can see where the sets overlap. Maybe we can figure things out somehow.

Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

Hi, Nico, On Fri, May 22, 2020 at 2:38 PM Nico Kadel-Garcia wrote: > > On Thu, May 21, 2020 at 1:04 PM Richard Shaw wrote: > > > > On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova > > wrote: > >> > >> On Thu, May 21, 2020 at 6:30 PM Richard Shaw wrote: > >> > > >> > On Thu, May 21, 2020

[HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.9 If you see a "Rebuilt for Python 3.9" (or similar) commit in your package, please don't rebuild it in regular rawhide. If you need to, please let me

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22/05/20 13:06 +0200, Miro Hrončok wrote: On 22. 05. 20 12:54, Jonathan Wakely wrote: On 22/05/20 10:47 +0200, Miro Hrončok wrote: On 22. 05. 20 8:28, Jonathan Wakely wrote: On 22/05/20 03:06 +0200, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 13:06, Miro Hrončok wrote: Could you give me the list of packages? Is it this? $ repoquery -C --repo=rawhide{,-source} --whatrequires boost-devel | grep src$ I can see where the sets overlap. Maybe we can figure things out somehow. If this is the list, there are only 67 common

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 12:07, Jonathan Wakely wrote: [..] > Maybe you should make a proper change proposal to do this, instead of > just being sarcastic about the work other people are doing? > I'm not 100% sure am I understand you correctly because I'm not sure is it still something not clear

Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

On Thu, May 21, 2020 at 1:04 PM Richard Shaw wrote: > > On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova > wrote: >> >> On Thu, May 21, 2020 at 6:30 PM Richard Shaw wrote: >> > >> > On Thu, May 21, 2020 at 10:37 AM Przemo Firszt wrote: >> >> >> >> "FreeCAD -t 0" performs approx 470 tests.

Re: Sundials upgrade on Rawhide

Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=44816285 -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature

Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

On Fri, May 22, 2020 at 01:28:14PM +0200, Aleksandra Fedorova wrote: > On Fri, May 22, 2020 at 9:29 AM Petr Pisar wrote: > > > > I'd like to point out that there is a difference in the enviroments between > > these two approaches. > > > > While the manual procedure only installs a binary package

Fedora-Cloud-31-20200522.0 compose check report

No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: HEADS UP: libdav1d SONAME bump from .3 to .4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-05-22 at 11:56 +0200, Igor Raits wrote: > Hello, > > I'm upgrading dav1d from 0.5.x to 0.7.x that is changing SONAME. > There > is only one dependent package in Rawhide - libavif which I will take > care of. This is done:

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 12:02, Miro Hrončok wrote: > On 22. 05. 20 12:43, Tomasz Kłoczko wrote: > > [mode=serious] > > On making transition from 3.8.x to 3.9.x all what would be necessary to > do would > > be just create compat-python3.8 package -> upgrade python.spec to 3.9 -> > monitor > >

Re: TeXLive 2020 landing in rawhide

On Thu, May 14, 2020 at 11:56 PM Tom Callaway wrote: > > I've just kicked off new builds for texlive and texlive-base for TeXLive 2020 > in rawhide. Hopefully, everything that depends on them will continue to work, > but if you notice any new issues generating docs (or any missing components >

Re: FreeCAD dist-git check, WAS:Re: Aggressive updating (Python 3.9): Are we trying to hard?

Hi, Petr, On Fri, May 22, 2020 at 9:29 AM Petr Pisar wrote: > > On Thu, May 21, 2020 at 07:29:35PM +0200, Aleksandra Fedorova wrote: > > On Thu, May 21, 2020 at 7:04 PM Richard Shaw wrote: > > > > > > On Thu, May 21, 2020 at 11:56 AM Aleksandra Fedorova > > > wrote: > > >> > > >> To run the

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 12:54, Jonathan Wakely wrote: On 22/05/20 10:47 +0200, Miro Hrončok wrote: On 22. 05. 20 8:28, Jonathan Wakely wrote: On 22/05/20 03:06 +0200, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag.   

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22/05/20 11:43 +0100, Tomasz Kłoczko wrote: On Fri, 22 May 2020 at 10:42, Miro Hrončok wrote: [..] It is just the component name. The user installable package is still python3. I call it thing-which-should-not-exist or thing-which-shall-not-pass. That way it is easier to pronounce 

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22/05/20 10:47 +0200, Miro Hrončok wrote: On 22. 05. 20 8:28, Jonathan Wakely wrote: On 22/05/20 03:06 +0200, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag.    https://fedoraproject.org/wiki/Changes/Python3.9 If you see a

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 12:43, Tomasz Kłoczko wrote: [mode=serious] On making transition from 3.8.x to 3.9.x all what would be necessary to do would be just create compat-python3.8 package -> upgrade python.spec to 3.9 -> monitor number of packages still dependent on compat-python3.8 to focus what still

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

Am 22.05.20 um 12:47 schrieb Miro Hrončok: >> I was not aware that python-genshi is still part of the initial bootstrap >> sequence. The package does not work with Python 3.9 (upstream problem, the >> usual AST changes). I hope that won't make your life too difficult. > > genshi is used in some

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 9:42, Felix Schwarz wrote: Am 22.05.20 um 03:06 schrieb Miro Hrončok: fschwarz   babel python-genshi I was not aware that python-genshi is still part of the initial bootstrap sequence. The package does not work with Python 3.9 (upstream problem, the usual AST changes). I hope

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 10:42, Miro Hrončok wrote: [..] > It is just the component name. The user installable package is still > python3. > I call it thing-which-should-not-exist or thing-which-shall-not-pass. That way it is easier to pronounce  > Reasoning: > > Build python3, python3-libs

Re: Aggressive updating (Python 3.9): Are we trying to hard?

On Wed, May 20, 2020 at 3:39 PM Miroslav Suchý wrote: > > Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a): > > Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8. But > > instead of asking ourselves, "should we push > > in the VERY latest Python and hope it's ok?", we just patch

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

- Original Message - > From: "Tomasz Kłoczko" > To: "Development discussions related to Fedora" > > Sent: Friday, May 22, 2020 11:51:48 AM > Subject: Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side > tag > On Fri, 22 May 2020 at 10:27, Peter Pentchev <

HEADS UP: libdav1d SONAME bump from .3 to .4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I'm upgrading dav1d from 0.5.x to 0.7.x that is changing SONAME. There is only one dependent package in Rawhide - libavif which I will take care of. - -- Igor Raits -BEGIN PGP SIGNATURE-

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 10:27, Peter Pentchev wrote: [..] > > Originally was python package. Than was python python2 and python3. Now > it > > is python3.9. > > Why not is used still and just python and to provide necessary > dependencies > > during transition python3.8? > > That way as well is

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 11:08, Tomasz Kłoczko wrote: I'm only curious why to make transition to python 3.9 was chosen "debianised way"? Originally was python package. Than was python python2 and python3. Now it is python3.9. It is just the component name. The user installable package is still

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, May 22, 2020 at 10:08:04AM +0100, Tomasz Kłoczko wrote: > On Fri, 22 May 2020 at 02:17, Miro Hrončok wrote: > > > Hello, in order to deliver Python 3.9, we are running a coordinated > > rebuild in a > > side tag. > > > > https://fedoraproject.org/wiki/Changes/Python3.9 > > > [..] >

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On Fri, 22 May 2020 at 02:17, Miro Hrončok wrote: > Hello, in order to deliver Python 3.9, we are running a coordinated > rebuild in a > side tag. > > https://fedoraproject.org/wiki/Changes/Python3.9 > [..] I'm only curious why to make transition to python 3.9 was chosen "debianised way"?

Re: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag

On 22. 05. 20 8:28, Jonathan Wakely wrote: On 22/05/20 03:06 +0200, Miro Hrončok wrote: Hello, in order to deliver Python 3.9, we are running a coordinated rebuild in a side tag.    https://fedoraproject.org/wiki/Changes/Python3.9 If you see a "Rebuilt for Python 3.9" (or similar) commit in

[Bug 1838904] perl-perlfaq-5.20200523 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1838904 --- Comment #5 from Fedora Update System --- FEDORA-2020-6471c56f67 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-6471c56f67 -- You are receiving this mail because: You are on the CC list

[Bug 1838904] perl-perlfaq-5.20200523 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1838904 --- Comment #4 from Fedora Update System --- FEDORA-2020-b96953d5ef has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b96953d5ef -- You are receiving this mail because: You are on the CC list

[Bug 1838904] perl-perlfaq-5.20200523 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1838904 --- Comment #3 from Fedora Update System --- FEDORA-2020-1a910e5253 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1a910e5253 -- You are receiving this mail because: You are on the CC list

[Bug 1838904] perl-perlfaq-5.20200523 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1838904 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version|

[Bug 1838904] perl-perlfaq-5.20200523 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1838904 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED

Fedora-Cloud-32-20200522.0 compose check report

No missing expected images. Soft failed openQA tests: 1/1 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 603163 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/603163 -- Mail generated by check-compose:

  1   2   >