Re: Location of executable code

Le vendredi 22 mai 2020 à 21:31 -0400, Steve Grubb a écrit : > > Over a couple emails I kind of realized that originally this was > framing the > question wrong. My question now is how can we determine what is meant > to be > executable by system applications vs examples and other cruft? There

Re: fedpkg fork broken?

Kevin Fenzi wrote on Fri, May 22, 2020: > So, just to clarify a confusing situation... :) > > a...@pkgs.fedoraproject.org should never have worked. > > If you have pkgs.fedoraproject.org it means you are using SSH, and are a > packager. This is just due to the way pkgs was created. Packagers hav

Re: Location of executable code

Le vendredi 22 mai 2020 à 16:48 -0400, Steve Grubb a écrit : > On Friday, May 22, 2020 4:23:50 PM EDT Przemek Klosowski via devel > wrote: > > > > In general, data is code is data. > > I know this argument well (Weird Machines). I was making the same > argument 10 years ago. :-) It got true

Re: Location of executable code

Le vendredi 22 mai 2020 à 20:41 +0200, Nicolas Mailhot via devel a écrit : > > So, no use looking for non-executable /usr/share. A lot of /usr/share > is executable and will stay that way. Also moving executable things somewhere else would make multiarch (more of) a major hassle. Because the somw

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 dat

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 ___ d

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 > > w

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... :) a...@pkgs.f

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 provid

[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 proba

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: Th

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 it

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 ent

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. > >

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 mu

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 aga

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 devel-l

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 b

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 >> >

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 o

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 o

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 do

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 li

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 be.

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 > > fil

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

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 Thu,

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 ta

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 fo

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 3.

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 o

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 Cl

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 no

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, > ple

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 numb

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 proc

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 pretty

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 numb

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 pytho

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 numb

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: https:/

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 th

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, I

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 devel-le...@lists.fedo

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 ju

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 whateve

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 reas

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. I

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 a

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 reb

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 p

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 o

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 devel-le...@lists.fedorap

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: https://bodh

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 > > numbe

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 co

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.    https://fedoraproject

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

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

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 h

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 etc.

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 t

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 < r...@ringlet.n

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- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4F

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 ca

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 python3

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 y

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: https://pagure.i

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

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 that won't make your life too difficult.

Re: wrong info on apps.fedoraproject.org

On Fri, 22 May 2020 at 08:38, Jos de Kloe wrote: > Something seems wrong in: https://apps.fedoraproject.org/packages/pyproj > The header text and upstream point to pyproject-rpm-macros in stead of > pyproj. > Does anybody know how to fix this? > That application has been in a bad shape for a whi

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

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 command above as the integration test you need to put > >> tests/tests.yml file