Schedule for Thursday's FPC Meeting (2019-10-03 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-10-03 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2019-10-03 09:00 PDT US/Pacific 2019-10-03 12:00 EDT --> US/Eastern <-- 2019-10-03 16:00 UTC UTC 2019-10-03 17:00 BST Europe/London 2019-10-03 18:00 CEST Europe/Berlin 2019-10-03 18:00 CEST Europe/Paris 2019-10-03 21:30 IST Asia/Calcutta New Day: Friday - 2019-10-04 00:00 HKT Asia/Hong_Kong 2019-10-04 00:00 +08 Asia/Singapore 2019-10-04 01:00 JST Asia/Tokyo 2019-10-04 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = Pull Requests = #topic #814 Add SELinux Independent Policy Guidelines https://pagure.io/packaging-committee/pull-request/814 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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: 2020 Datacenter Move: Request for comments
On 2019-10-02 16:45, Fabio Valentini wrote: On Wed, Oct 2, 2019 at 3:07 AM Brian (bex) Exelbierd wrote: On Tue, Oct 1, 2019 at 10:05 AM Pavel Valena wrote: - Original Message - From: "Jun Aruga" To: "Development discussions related to Fedora" Cc: "Fedora Infrastructure" Sent: Monday, September 30, 2019 8:27:22 PM Subject: Re: 2020 Datacenter Move: Request for comments There's also a video about it from Flock 2019: https://www.youtube.com/watch?v=phCHilTEQb4&list=PL0x39xti0_64C75dRUuwlXlfYRgjgdEP4&index=8&t=0s Thanks. But why is the video mode "Unlisted" not public? -- Jun | He - His - Him Making it public is just a `cosmetic` change IMO, as the `Flock 2019` list is public. But maybe it enhances visibility(searchability?) also. CCing Bex for comments. ;) The ones in this list should be listed. There are about 22 videos still to be reviewed for final clearance. I am in 2 weeks of f2f meetings so i am trying to get to them ASAP. Looking at the fedora youtube channel and the playlist, *all videos except one* (Fedora Flatpaks) are still unlisted. Fabio This could explain, why I got notification only for Fedora Flatpaks video, when I'm subscribed to Fedora Channel on Youtube. Michal regards, bex Thanks, Pavel -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ 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 -- Role: Fedora CPE Team - Software Engineer IRC: mkonecny FAS: zlopez ___ 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: Defining the future of the packager workflow in Fedora
On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote: > > I'm going to ask again what was in my original email: What is your ideal > > workflow? How do you think things should work? > > Is what we have today the ideal state of things? > > If so, great! > > If not, what can we improve and are there things we can easily change that > > will > > make it easier for a majority of packagers? > > My feeling is that you've focused on the wrong part of the workflow. > My feeling is that the basic "commit, push, build, repeat" part of > packaging works reasonably well for most packages. Sure, it isn't > perfect, and it can be tedious to keep branches up to date across many > packages, and it'd be nice if there was more continuous integration > and running of a tests. > > But as a packager, the things that frustrate _me_-- the things I was > proposing to help fix, before I realized tha are all the peripherals: > the bits of the infrastructure that don't feel like they interact as > well with the workflow as they could. At the moment, two of my biggest > complaints are: I very much agree with what Ben says. We need to improve the integration between different components of the packaging infra. > 1. Creating new packages has become (more of) a pain since the > retirement of pkgdb2. I know I keep complaining about needing to > manually fetch Pagure API keys, but it is actually extremely annoying > when I go to request a repo and realize I need to first request a new > API key before doing anything else. The problem isn't the workflow, > per se, but the infrastructure: reviews could really use a better > platform than bugzilla. If reviews were more integrated into the > tooling, automatic checks like fedora-review could maybe be ran > automatically. Maybe approving a new package could even automatically > create the repository, without the requestor having to do anything! > > 2. Release monitoring is a wonderful tool, but it's poorly integrated > with the rest of the project. As a packager maintaining probably more > packages than I should, getting release monitoring notifications to > tell me to pay attention to a particular package is incredibly useful. > But I feel like we could do more with the information. There are > nodejs packages out there, to take an ecosystem at random, that have > had open tickets created by release monitoring for four+ years, and > the only activity on those tickets is the release monitoring bot > detecting new versions. Eventually, maybe, a human comes across the > package and realizes it might be unmaintained, and proceeds with the > nonresponsive maintainer policy or manages to track down the > maintainer to find out why the package hasn't been updated. I don't > say this to criticize anyone in particular, but surely we could be > more proactive here? Yep. Not every package is the same. For stuff like simple python/nodejs/rust/ruby/perl/… packages, I know that the only thing I do is mechanically bump the version and rebuild. I don't take a careful look at the changes in the package, I don't do any non-automated checks; if it builds, it gets shipped. For such packages, there really would be no difference if a bot was doing all the steps I'm doing now. But I don't think creating things from scratch is the answer. I think we need to find ways to extend and integrate what we already have. In particular, if we want to keep support for existing workflows that people use, we cannot just add new services and deprecate an old one. We need to grow new functionality in the existing ones. Zbyszek > Basically, I don't think we really need an entirely new packaging > workflow. (I would argue that attempts to impose an entirely new > packaging workflow-- like modularity-- are one of the reasons > packaging has gotten harder recently...). We need to improve the > contributor-facing _infrastructure_ to make the current workflow > better. > > I would personally advocate starting with a serious look at the review > process, and the tooling around it. If for no other reason than it is > the first thing most new contributors will interact with, so perhaps > it is in our interest to make it as pleasant as possible. ___ 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: Defining the future of the packager workflow in Fedora
On 10/2/19 8:33 PM, Matthew Miller wrote: On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote: ○ Every changes to dist-git is done via pull-requests Erm, no thank you. Pull requests are a terrible workflow. It's definitely the winning workflow in the open source world today, particularly for smaller and drive-by contributions, which I think we'd like to encourage. It's an awesome workflow for those cases. Not so much when you are the maintainer of said piece. And there _are_ real tracking and review benefits to having everything go through that workflow. Speaking out of experience from another project going all pull-requests: Yes, there are benefits. I do like somebody elses (faster) computer running the test-suite. In dist-git the "does it even build" would be an awesome gate to have at the push stage, deity knows I've done my share of "oops, ..." commits there that wouldn't exist if there was a gate. My issue with all this is that the pull-request workflow (speaking generally) as we know it introduces a significant overhead to the maintainer even for the simplest changes. As a developer, I want to just push the damn thing already and be done with it. Instead the pull-request model is like a ship-in-a-bottle workflow where you first do the work preliminary locally and then push it someplace remote to fiddle it into it's place with cumbersome remote controls. And then spend even more time tidying up over leftover branches here and there, updating your local copy to what you just did and other tedious administrativia. If the maintainer overhead could be eliminated (via automation) it would be awesome. As it is, most of the time it absolutely does not feel worth it. - Panu - ___ 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: CGAL soname "bump" in rawhide
On 02. 10. 19 16:16, laurent.rineau__fed...@normalesup.org wrote: On Wednesday, October 2, 2019 3:19:09 PM CEST Miro Hrončok wrote: On 01. 10. 19 18:47, laurent.rineau__fed...@normalesup.org wrote: With CGAL-5.0, CGAL is becoming a header-only C++ library of templates. That means that CGAL libraries will disappear, in particular libCGAL.so.13. I've tried to rebuild OpenSCAD, but it appears some headers are gone: /usr/include/CGAL/config.h:161:12: fatal error: CGAL/compiler_config.h: No such file or directory 161 | # include https://koji.fedoraproject.org/koji/taskinfo?taskID=38005057 I just made a pull-request to the upstream openscad, and another one in rpms/ openscad. https://src.fedoraproject.org/rpms/openscad/pull-request/9 Building now. Thanks for the awesomely fast response to this! -- 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
Re: Defining the future of the packager workflow in Fedora
On 03. 10. 19 1:32, Kevin Fenzi wrote: I'm not sure how to handle the dychomoty between having different spec files for each release and wanting to maintain just one spec that has a bunch of crazy conditionals in it. Even thought I do this too, I think we need a workflow that discourages this somehow. I believe that moving release tag and changelog entry to annotated tags solves this problem (or makes it insignificant). It means you can just cleanly cherry pick a fix anywhere it is relevant (most of the time) instead of fighting the changelog conflicts all the time. -- 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
Re: Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation
Stephen Gallagher wrote: > So, looking at the license of that tool, it seems to be fine to > redistribute it unmodified... so what if we wrote a tool that would > run the `acpidump` and `acpixtract` locally, submit it to a very > simple web service and get back the config file for their system? How about we just reverse-engineer what those blobs do and reimplement them as Free Software? Kevin Kofler ___ 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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)
Stephen John Smoogen wrote: > OK at the moment it looks like we seem to average 311,000 ip addresses > per day doing a daily checkin for Fedora. Out of those ~13,400 are > x86_32. The majority of the x86_32 are pre-F28 with only about 3400 > (about 14% of total x86_32 and ~1% of all Fedora users) of them being > F28,F29,F30, or rawhide. The opposite is true for the other > architectures with the majority running F30, then F29, then F28 and > then a thin long tail for everything before that.] > > Now these statistics are not absolute numbers and could hide all kinds > of things.. I would say though that the majority of x86_32 is on > versions we no longer support and so we do not need to worry about > breaking large numbers of systems. You are still breaking thousands of systems. (3400 is more than three thousands.) Kevin Kofler ___ 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: Defining the future of the packager workflow in Fedora
Matthew Miller wrote: > Do you have an alternative proposal? Have you seen my reply elsewhere in this thread? I wrote there: > You need a different CI approach. Maybe: > * a push hook that just locks the repository and does the tests before > validating the push, though I can see that becoming a PITA as well, or > * an asynchronous CI push hook that just notifies the maintainer on > failures, but does not otherwise touch the repository, or > * an asynchronous CI push hook that automatically reverts commits that > fail the CI tests, or even > * an asynchronous CI push hook that automatically uses a force push to > revert the commits that fail the CI tests in such a way that they vanish > from history entirely, as if they had never happened, > or something more clever that we have not thought of yet. What is clear is that submitting pull requests to myself does not make any sense whatsoever. Kevin Kofler ___ 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: Defining the future of the packager workflow in Fedora
Miro Hrončok wrote: > On 03. 10. 19 1:32, Kevin Fenzi wrote: >> I'm not sure how to handle the dychomoty between having different spec >> files for each release and wanting to maintain just one spec that has a >> bunch of crazy conditionals in it. Even thought I do this too, I think >> we need a workflow that discourages this somehow. > > I believe that moving release tag and changelog entry to annotated tags > solves this problem (or makes it insignificant). > > It means you can just cleanly cherry pick a fix anywhere it is relevant > (most of the time) instead of fighting the changelog conflicts all the > time. I don't understand the people actually maintaining different changelogs for the releases. I just merge master into the release branches when I push an update, and if that includes some changelog entries for Rawhide-only mass rebuilds, so be it. Removing them is not worth breaking fast-forwardability of the branches. I even go as far as reverting branch-only commits and then doing the bidirectional merge trick to restore fast forwardability. That of course clobbers the branch-only changelog section and replaces it with the one from master, but that's just how things are. Again, I think fast-forwardability is more useful than per-branch changelogs. Kevin Kofler ___ 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: Defining the future of the packager workflow in Fedora
Kevin Fenzi wrote: > I'm not sure how to handle the dychomoty between having different spec > files for each release and wanting to maintain just one spec that has a > bunch of crazy conditionals in it. Even thought I do this too, I think > we need a workflow that discourages this somehow. I don't see what's wrong about the conditionals. Usually, the packages just work across releases with few to no conditionals. Occasionally, there is a conditional. It is still usually not worth letting the branches diverge. I only maintain different specfiles per branch if I actually want to ship different versions of the upstream software there. And also, is the fancy Modularity everyone except me is so excited about not actually about moving towards the one specfile for all Fedora releases model, among other things? But of course, the shared specfile can also easily be done without Modularity, with fast-forward merges as it has always been done. Kevin Kofler ___ 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: Fedora 32 Self-Contained Change proposal: Better Thermal Management for the Workstation
On Thu, Oct 3, 2019 at 5:51 AM Kevin Kofler wrote: > How about we just reverse-engineer what those blobs do and reimplement > them > as Free Software? > If I'm reading the comments right in the bugzilla report linked above, it sounds like Lenovo is going to do the right thing and put out an update BIOS for doing thermal management in the BIOS itself, rather than having the OS control it. I realize that probably doesn't cover everyone's use cases (or maybe not even older-model Lenovo laptops), but at least for me, this sounds like a more sane approach than trying to guess/reverse engineer what the OS is supposed to tell the hardware. -Jared ___ 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
postgresql.service (postgresql-11.5-1.fc30)
Reposting message to initscripts-devel: Hi, A slight modification to the postgresql startup script: postgresql.log.1 is the output from systemctl status postgresql before applying the drop-in. postgresql.log.2 is the output from systemctl status postgresql after applying the drop-in. postgresql.service.conf is the actual drop-in from /etc/systemd/system/postgresql.service.d applied to the Fedora 30 postgresql-11.5-1.fc30 package. The drop-in setting should replace the unit file setting in /usr/lib/systemd/system/postgresql.service. Have a pleasant day, Mischa Baars. ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2019-09-24 09:45:45 CEST; 1min 25s ago Process: 742 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (code=exited, status=0/SUCCESS) Main PID: 760 (postmaster) Tasks: 8 (limit: ) Memory: 27.6M CGroup: /system.slice/postgresql.service ├─760 /usr/bin/postmaster -D /var/lib/pgsql/data ├─775 postgres: logger ├─778 postgres: checkpointer ├─779 postgres: background writer ├─780 postgres: walwriter ├─781 postgres: autovacuum launcher ├─782 postgres: stats collector └─783 postgres: logical replication launcher Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.207 CEST [760] LOG: listening on IPv6 address "::1", port 5432 Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.207 CEST [760] LOG: listening on IPv4 address "127.0.0.1", port 5432 Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.215 CEST [760] LOG: could not bind IPv4 address "192.168.1.13": Cannot assign requested address Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.215 CEST [760] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.215 CEST [760] WARNING: could not create listen socket for "192.168.1.13" Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.215 CEST [760] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.220 CEST [760] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432" Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.279 CEST [760] LOG: redirecting log output to logging collector process Sep 24 09:45:45 dt0d.cyberfiber.eu postmaster[760]: 2019-09-24 09:45:45.279 CEST [760] HINT: Future log output will appear in directory "log". Sep 24 09:45:45 dt0d.cyberfiber.eu systemd[1]: Started PostgreSQL database server. ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/postgresql.service.d └─postgresql.service.conf Active: active (running) since Tue 2019-09-24 09:49:55 CEST; 58s ago Process: 957 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgresql (code=exited, status=0/SUCCESS) Main PID: 964 (postmaster) Tasks: 8 (limit: ) Memory: 26.3M CGroup: /system.slice/postgresql.service ├─964 /usr/bin/postmaster -D /var/lib/pgsql/data ├─982 postgres: logger ├─984 postgres: checkpointer ├─985 postgres: background writer ├─986 postgres: walwriter ├─987 postgres: autovacuum launcher ├─988 postgres: stats collector └─989 postgres: logical replication launcher Sep 24 09:49:55 dt0d.cyberfiber.eu systemd[1]: Starting PostgreSQL database server... Sep 24 09:49:55 dt0d.cyberfiber.eu postmaster[964]: 2019-09-24 09:49:55.225 CEST [964] LOG: listening on IPv6 address "::1", port 5432 Sep 24 09:49:55 dt0d.cyberfiber.eu postmaster[964]: 2019-09-24 09:49:55.225 CEST [964] LOG: listening on IPv4 address "127.0.0.1", port 5432 Sep 24 09:49:55 dt0d.cyberfiber.eu postmaster[964]: 2019-09-24 09:49:55.232 CEST [964] LOG: listening on IPv4 address "192.168.1.13", port 5432 Sep 24 09:49:55 dt0d.cyberfiber.eu postmaster[964]: 2019-09-24 09:49:55.233 CEST [964] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" Sep 24 09:49:55 dt0d.cyberfiber.eu postmaster[964]: 2019-09-24 09:49:55.236 CEST [964] LOG: listening on Unix socket "/tmp/.s.PGSQL.5432" Sep 24 09:49:55 dt0d.cyberfiber.eu postmaster[964]: 2019-09-24 09:49:55.303 CEST [964] LOG: redirecting log output to logging collector process Sep 24 09:49:55 dt0d.cyberfiber.eu postmaster[964]: 2019-09-24 09:49:55.303 CEST [964] HINT: Future log output will appear in directory "log". Sep 24 09:49:55 dt0d.cyberfiber.eu systemd[1]: Started PostgreSQL database server. # It's not recommended to mod
Re: Defining the future of the packager workflow in Fedora
On 03. 10. 19 11:58, Kevin Kofler wrote: I don't understand the people actually maintaining different changelogs for the releases. I just merge master into the release branches when I push an update, and if that includes some changelog entries for Rawhide-only mass rebuilds, so be it. Removing them is not worth breaking fast-forwardability of the branches. It goes like this: - master and f31 are at the same commit "aa" - I push a change only possible in rawhide, commit "bb" to master (it includes release bump and changelog entry) - a commit relevant for both, "cc" is pushed to master (it includes release bump and changelog entry) - on f31, I run `git cherry-pick cc` => conflict I don't worry about having "Fedora 31 mass rebuild" or "Rebuilt for python 3.8" changelong entries in Fedora 29 (it gives me a little flinch, but nothing serious). i worry about the bb commit I cannot merge into f31 (e.g. if it implements some Fedora 32 change). Then obviously, people start inventing %if spaghetti. -- 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
Intent to orphan python-unittest2
Hello mostly Bcced maintainers of packages impacted by this. I maintain python-unittest2, a backport of the standard library unittest module from Python 3 to Python 2 (mostly) [1]. We are removing python2-unittest2 soon, as nothing depends on it any more [2]. I'd retire the package, as it makes no sense on Python 3, however there are packages that use python3-unittest2 for various invalid reasons. The proper action is to fix the packages to use unittest from the standard library, but I lack the energy to coordinate that, so i just decided to just orphan it. That said, if you want my help with the migration, let me know! Runtime dependents: python-testtools Buildtime dependents: ProDy beaker cloud-init compose-utils fedpkg jpype pungi pyephem python-agate python-billiard python-case python-funcsigs (this is also a backport) python-hdmf python-leather python-linecache2 (this is also a backport) python-mimerender python-parameterized python-pyclipper python-pykafka python-pynwb python-ripozo python-rsa python-testtools python-traceback2 (this is also a backport) python-tw2-core python-unicodecsv [1] https://pypi.org/project/unittest2/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1757022 -- 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
Minimization Objective report
This is the Minimization Objective [0] update. Status: Discovery phase == Next phase definition == I'm putting together a proposal for the next phase approval. I've made a Logic Model [1] so far, more is coming soon. See the issue [2] to get more updates and to give feedback which is very welcome. == Splitting out systemd-sysusers == We still don't want Systemd in containers [3]. Trying to get the sysusers package split out (asked upstream) [4] so packages can use it without pulling the whole Systemd in. == Feedback Pipeline and Hacktoberfest == We're participating in Hacktoberfest [5] with Feedback Pipeline [6] to potentially get some contributions! == How to get involved == See if there is anything interesting to you on action plan [42], or reach out with something you think is useful but is missing there. Open a ticket in the tracker [43] or discuss in #fedora-devel on IRC. Cheers, Adam [0] Objective: https://docs.fedoraproject.org/en-US/minimization/ [1] Logic Model: https://asamalik.fedorapeople.org/fedora-minimization-logic-model.pdf [2] Next phase issue: https://pagure.io/minimization/issue/15 [3] systemd-sysusers vs. containers: https://pagure.io/minimization/issue/13 [4] Splitting sysusers out: https://github.com/systemd/systemd/issues/13653 [5] Hacktoberfest: https://fedoramagazine.org/fedora-projects-for-hacktoberfest/ [6] Feedback Pipeline: https://github.com/minimization/feedback-pipeline [42] Action plan: https://docs.fedoraproject.org/en-US/minimization/action-plan/ [43] Issue tracker: https://pagure.io/minimization/issues -- Adam Šamalík --- Senior Software Engineer Red Hat ___ 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
Fwd: [rpms/future] PR #5: re-enable future for python2
-- Forwarded message - From: Kenneth Topp Date: Thu, Oct 3, 2019 at 2:31 AM Subject: [rpms/future] PR #5: re-enable future for python2 To: toppk opened a new pull-request against the project: `future` that you are following: `` re-enable future for python2 `` To reply, visit the link below https://src.fedoraproject.org/rpms/future/pull-request/5 -- *--Antonio Trande* *mail*: mailto:sagit...@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: Defining the future of the packager workflow in Fedora
On Wed, 2019-10-02 at 14:44 -0400, Colin Walters wrote: > > On Wed, Oct 2, 2019, at 1:40 PM, Fabio Valentini wrote: > > > As others in the thread have pointed out, mandatory pull requests just > > make no sense for most single-maintainer projects, which most packages > > probably are. > > Well, a lot of this relates to what the *merge policy* is. If a PR submitter > can merge their own PRs, and there's a > mechanism to do "merge when tests pass" (this is an important aspect), then > submitting a PR can be just about as > equally ergonomic as `git push`. Yeah, that sounds good & nice improvement to the currently available options. In some cases I run scratchbuilds as a kind of a smoke tests before the "real" build - this way I could just use this and save some time. :) All in all I think much of this discussion feels a bit redundant to me - lets just implement the support for improved PRs that can be easily & automatically created and that triger all sorts of tests and builds. If the new system is good, I'm sure many maintainers would switch to it to everyones benefit - less regressions & less time taken maintaining packages. At the same time if other maintainers have their own workflow that is not compatible with the PR workflow or makes it redundant for their packages, they should not be forced to use it. > In OpenShift we use Prow, which has the latter; I really like it. However we > also *require* peer review (submitters > can't merge their own PRs). I'd like to require review, but it does seem > like a prerequisite is moving away from the > one-repo-per-package model. > ___ > 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: Defining the future of the packager workflow in Fedora
On Wed, Oct 02, 2019 at 04:32:30PM -0700, Kevin Fenzi wrote: > I'm not sure how to handle the dychomoty between having different spec > files for each release and wanting to maintain just one spec that has a > bunch of crazy conditionals in it. Even thought I do this too, I think > we need a workflow that discourages this somehow. Which one are we discouraging? -- Matthew Miller Fedora Project Leader ___ 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: Defining the future of the packager workflow in Fedora
On Thu, Oct 03, 2019 at 11:52:32AM +0200, Kevin Kofler wrote: > Have you seen my reply elsewhere in this thread? I did, thanks. And I can see that as a fine model too. Looking for more ideas from Richard as well. > What is clear is that submitting pull requests to myself does not make any > sense whatsoever. Yes, I can certainly sympathize with that. -- Matthew Miller Fedora Project Leader ___ 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
Old changelog entries removal
Hello all. Is it possible to remove old %changelog entries from SPECs? I can't find information about this in Fedora packaging guidelines. All history still can be found in git log. -- 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: Defining the future of the packager workflow in Fedora
Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a): > Miro Hrončok wrote: >> On 03. 10. 19 1:32, Kevin Fenzi wrote: >>> I'm not sure how to handle the dychomoty between having different spec >>> files for each release and wanting to maintain just one spec that has a >>> bunch of crazy conditionals in it. Even thought I do this too, I think >>> we need a workflow that discourages this somehow. >> I believe that moving release tag and changelog entry to annotated tags >> solves this problem (or makes it insignificant). >> >> It means you can just cleanly cherry pick a fix anywhere it is relevant >> (most of the time) instead of fighting the changelog conflicts all the >> time. > I don't understand the people actually maintaining different changelogs for > the releases. I just merge master into the release branches when I push an > update, and if that includes some changelog entries for Rawhide-only mass > rebuilds, so be it. Removing them is not worth breaking fast-forwardability > of the branches. It depends how you maintain your packages. My guess is (and I am sorry if I am mistaken) that you don't follow the https://fedoraproject.org/wiki/Updates_Policy#Philosophy If you followed this policy, then you would touch the stable branches just rarely and therefore keeping them fast forwardable would be just waste of time. Vít > > I even go as far as reverting branch-only commits and then doing the > bidirectional merge trick to restore fast forwardability. That of course > clobbers the branch-only changelog section and replaces it with the one from > master, but that's just how things are. Again, I think fast-forwardability > is more useful than per-branch changelogs. > > Kevin Kofler > ___ > 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: Old changelog entries removal
On Thu, Oct 3, 2019 at 9:21 AM Vitaly Zaitsev via devel wrote: > > Hello all. > > Is it possible to remove old %changelog entries from SPECs? I can't find > information about this in Fedora packaging guidelines. Yes. josh > > All history still can be found in git log. > > -- > 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 ___ 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: Old changelog entries removal
On Thu, Oct 03, 2019 at 02:45:20PM +0200, Vitaly Zaitsev via devel wrote: > Is it possible to remove old %changelog entries from SPECs? I can't find > information about this in Fedora packaging guidelines. > All history still can be found in git log. Whether or not it's documented policy (and I can't remember or find anything either), many packages have the practice of trimming very old entries. I'm looking at `filesystem` and `setup`, both have existed since time immemorial (back to RHL pre-history) -- and which currently have changelogs starting from 2017. -- Matthew Miller Fedora Project Leader ___ 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: Defining the future of the packager workflow in Fedora
Dne 03. 10. 19 v 12:18 Miro Hrončok napsal(a): Then obviously, people start inventing %if spaghetti. Nope, %if spaghetti comes from people who are upstream author of some project (usually layered application) and have to support the packages (usually cli tools for their project) for all Fedoras, Epels. Also for Debians, Suses, Mageias... And they are actually also package maintainers in those distributions. And they do not want to maintain various versions of spec files in various distributions. In all projects, I have been working so far, the push to Fedora from upstream was fully automated and I did not need to know about dist-git branches at all. -- 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: Defining the future of the packager workflow in Fedora
Dne 03. 10. 19 v 14:35 Matthew Miller napsal(a): > On Wed, Oct 02, 2019 at 04:32:30PM -0700, Kevin Fenzi wrote: >> I'm not sure how to handle the dychomoty between having different spec >> files for each release and wanting to maintain just one spec that has a >> bunch of crazy conditionals in it. Even thought I do this too, I think >> we need a workflow that discourages this somehow. > Which one are we discouraging? > > This is where this was discussed, although not that explicitly: https://pagure.io/packaging-committee/issue/742 https://pagure.io/packaging-committee/issue/744 Conditions should be discouraged, because they makes the maintenance of packages harder. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Old changelog entries removal
Dne 03. 10. 19 v 14:45 Vitaly Zaitsev via devel napsal(a):
Hello all.
Is it possible to remove old %changelog entries from SPECs? I can't find
information about this in Fedora packaging guidelines.
All history still can be found in git log.
Rpmbuild actually removes all entries older than %_changelog_trimtime
In Fedora this macro is defined as
-13: _changelog_trimtime%{lua:print(os.time() - 2 * 365 * 86400)}
I.e. everything older than 2 years is discarded in build time.
--
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: Old changelog entries removal
On Thu, Oct 03, 2019 at 02:45:20PM +0200, Vitaly Zaitsev via devel wrote: > Hello all. > > Is it possible to remove old %changelog entries from SPECs? I can't find > information about this in Fedora packaging guidelines. > > All history still can be found in git log. We already set an rpm variable (sorry, I don't remember the name), that trims changelogs in the binary file to fixed time, I think two years. But if you want to trim the spec file, I'm sure you can do that too. 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
Re: Old changelog entries removal
On Thu, Oct 03, 2019 at 03:40:43PM +0200, Miroslav Suchý wrote:
> Rpmbuild actually removes all entries older than %_changelog_trimtime
> In Fedora this macro is defined as
> -13: _changelog_trimtime%{lua:print(os.time() - 2 * 365 * 86400)}
> I.e. everything older than 2 years is discarded in build time.
Wow, I totally forgot about that. Carry on. :)
--
Matthew Miller
Fedora Project Leader
___
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: Old changelog entries removal
On Thu, Oct 03, 2019 at 09:23:16AM -0400, Josh Boyer wrote: > On Thu, Oct 3, 2019 at 9:21 AM Vitaly Zaitsev via devel > wrote: > > > > Hello all. > > > > Is it possible to remove old %changelog entries from SPECs? I can't find > > information about this in Fedora packaging guidelines. > > Yes. FWIW, my approach is to purge all changelog entries older than 2 years the first time I touch a package in January each year. Is there any value in having guidelines to encourage some policy in this area, so maintainer approach it in a consistent way ? I would suggest we even go as far as having a script to automatically purge changelogs when branching dist git. Cull everything older than the last NN Fedora releases, for some reasonable value of NN. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: Old changelog entries removal
On Thu, Oct 03, 2019 at 02:47:27PM +0100, Daniel P. Berrangé wrote: > FWIW, my approach is to purge all changelog entries older than 2 years > the first time I touch a package in January each year. Is there any value > in having guidelines to encourage some policy in this area, so maintainer > approach it in a consistent way ? > > I would suggest we even go as far as having a script to automatically > purge changelogs when branching dist git. Cull everything older than > the last NN Fedora releases, for some reasonable value of NN. I think rather than this, we should bite the bullet and remove changelogs entirely from spec files. -- Matthew Miller Fedora Project Leader ___ 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: Old changelog entries removal
On Thu, Oct 03, 2019 at 09:51:01AM -0400, Matthew Miller wrote: > On Thu, Oct 03, 2019 at 02:47:27PM +0100, Daniel P. Berrangé wrote: > > FWIW, my approach is to purge all changelog entries older than 2 years > > the first time I touch a package in January each year. Is there any value > > in having guidelines to encourage some policy in this area, so maintainer > > approach it in a consistent way ? > > > > I would suggest we even go as far as having a script to automatically > > purge changelogs when branching dist git. Cull everything older than > > the last NN Fedora releases, for some reasonable value of NN. > > I think rather than this, we should bite the bullet and remove changelogs > entirely from spec files. I certainly won't complain if that's done :-) Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: Defining the future of the packager workflow in Fedora
On 03. 10. 19 15:23, Vít Ondruch wrote: Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a): Miro Hrončok wrote: On 03. 10. 19 1:32, Kevin Fenzi wrote: I'm not sure how to handle the dychomoty between having different spec files for each release and wanting to maintain just one spec that has a bunch of crazy conditionals in it. Even thought I do this too, I think we need a workflow that discourages this somehow. I believe that moving release tag and changelog entry to annotated tags solves this problem (or makes it insignificant). It means you can just cleanly cherry pick a fix anywhere it is relevant (most of the time) instead of fighting the changelog conflicts all the time. I don't understand the people actually maintaining different changelogs for the releases. I just merge master into the release branches when I push an update, and if that includes some changelog entries for Rawhide-only mass rebuilds, so be it. Removing them is not worth breaking fast-forwardability of the branches. It depends how you maintain your packages. My guess is (and I am sorry if I am mistaken) that you don't follow the https://fedoraproject.org/wiki/Updates_Policy#Philosophy I do. If you followed this policy, then you would touch the stable branches just rarely and therefore keeping them fast forwardable would be just waste of time. I touch stable branches for bugfix upgrades. -- 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
Re: Old changelog entries removal
Once upon a time, Matthew Miller said: > I think rather than this, we should bite the bullet and remove changelogs > entirely from spec files. I find "rpm -q --changelog" useful (at least when maintainers put useful info there, which isn't always), so please don't. -- Chris Adams ___ 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: Old changelog entries removal
On 10/3/19 10:16 AM, Chris Adams wrote:
Once upon a time, Matthew Miller said:
I think rather than this, we should bite the bullet and remove changelogs
entirely from spec files.
I find "rpm -q --changelog" useful (at least when maintainers put useful
info there, which isn't always), so please don't.
I am in favor of removing changelogs from spec files, but I do
understand that some people find them useful. How about a meet halfway
point and have a macro that maintainers can use to automatically
generate spec file changelog blocks for projects which we are also the
upstream for?
I have this silly script to generate an spec file changelog block
(complete with the hyphen prefixing and wrapping of lines and escaping
percent signs) that generates a block from the most recent tag on a git
repo:
==
#!/bin/sh
PATH=/usr/bin
CWD="$(pwd)"
LATEST_TAG="$(git tag --sort=taggerdate | tail -n 1)"
git log --format=%s ${LATEST_TAG}.. | tac | while read line ; do
first=1
echo "${line}" | sed -e 's|%|%%|g' | fold -s -w 70 | \
while read subline ; do
if [ ${first} -eq 1 ]; then
echo "- ${subline}"
first=0
else
echo " ${subline}"
fi
done
done
==
I take this output and paste it in the spec file and then delete the
lines I don't want. Could be expanded to take a repo as a parameter, etc.
Dunno, just an idea.
--
David Cantrell
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: Old changelog entries removal
On 03. 10. 19 16:16, Chris Adams wrote: Once upon a time, Matthew Miller said: I think rather than this, we should bite the bullet and remove changelogs entirely from spec files. I find "rpm -q --changelog" useful (at least when maintainers put useful info there, which isn't always), so please don't. That would prevail. -- 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
Re: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)
On Thu, 3 Oct 2019 at 05:50, Kevin Kofler wrote: > > Stephen John Smoogen wrote: > > OK at the moment it looks like we seem to average 311,000 ip addresses > > per day doing a daily checkin for Fedora. Out of those ~13,400 are > > x86_32. The majority of the x86_32 are pre-F28 with only about 3400 > > (about 14% of total x86_32 and ~1% of all Fedora users) of them being > > F28,F29,F30, or rawhide. The opposite is true for the other > > architectures with the majority running F30, then F29, then F28 and > > then a thin long tail for everything before that.] > > > > Now these statistics are not absolute numbers and could hide all kinds > > of things.. I would say though that the majority of x86_32 is on > > versions we no longer support and so we do not need to worry about > > breaking large numbers of systems. > > You are still breaking thousands of systems. (3400 is more than three > thousands.) What do you mean by breaking breaking because you use that term like a sledge hammer for anything from a 'pixel off' bug to 'too old software is in repos', 'too young software is in repos' , 'software is not in repos' to 'can't boot'. After a while, I assumed the only way I can't break a system is to never unbox it.. but I expect there is probably some way that is also a broken system. https://www.youtube.com/watch?v=6DGNZnfKYnU -- 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: Old changelog entries removal
On Thu, Oct 03, 2019 at 10:21:37AM -0400, David Cantrell wrote:
> On 10/3/19 10:16 AM, Chris Adams wrote:
> > Once upon a time, Matthew Miller said:
> > > I think rather than this, we should bite the bullet and remove changelogs
> > > entirely from spec files.
> >
> > I find "rpm -q --changelog" useful (at least when maintainers put useful
> > info there, which isn't always), so please don't.
>
> I am in favor of removing changelogs from spec files, but I do understand
> that some people find them useful. How about a meet halfway point and have
> a macro that maintainers can use to automatically generate spec file
> changelog blocks for projects which we are also the upstream for?
>
> I have this silly script to generate an spec file changelog block (complete
> with the hyphen prefixing and wrapping of lines and escaping percent signs)
> that generates a block from the most recent tag on a git repo:
>
> ==
> #!/bin/sh
>
> PATH=/usr/bin
> CWD="$(pwd)"
>
> LATEST_TAG="$(git tag --sort=taggerdate | tail -n 1)"
>
> git log --format=%s ${LATEST_TAG}.. | tac | while read line ; do
> first=1
> echo "${line}" | sed -e 's|%|%%|g' | fold -s -w 70 | \
> while read subline ; do
> if [ ${first} -eq 1 ]; then
> echo "- ${subline}"
> first=0
> else
> echo " ${subline}"
> fi
> done
> done
> ==
>
> I take this output and paste it in the spec file and then delete the lines I
> don't want. Could be expanded to take a repo as a parameter, etc.
Or just add some RPM metadata tags to record the upstream SCM type + URL +
branch / release tag, etc. The user can thus easily find the upstream
full commit logs corresponding to the pacakge.
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Old changelog entries removal
Once upon a time, Daniel P. Berrangé said: > Or just add some RPM metadata tags to record the upstream SCM type + URL + > branch / release tag, etc. The user can thus easily find the upstream > full commit logs corresponding to the pacakge. IMHO that is only good when the Fedora package is nothing but the upstream code, built with defaults. As soon as Fedora needs to add a patch and/or systemd unit(s), change options, etc., there should be a Fedora changelog. And even when it's a straight build of upstream, some maintainers include RH Bugzilla numbers in their changelog entries, which is useful too. -- Chris Adams ___ 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: Old changelog entries removal
On 10/3/19 10:29 AM, Daniel P. Berrangé wrote:
On Thu, Oct 03, 2019 at 10:21:37AM -0400, David Cantrell wrote:
On 10/3/19 10:16 AM, Chris Adams wrote:
Once upon a time, Matthew Miller said:
I think rather than this, we should bite the bullet and remove changelogs
entirely from spec files.
I find "rpm -q --changelog" useful (at least when maintainers put useful
info there, which isn't always), so please don't.
I am in favor of removing changelogs from spec files, but I do understand
that some people find them useful. How about a meet halfway point and have
a macro that maintainers can use to automatically generate spec file
changelog blocks for projects which we are also the upstream for?
I have this silly script to generate an spec file changelog block (complete
with the hyphen prefixing and wrapping of lines and escaping percent signs)
that generates a block from the most recent tag on a git repo:
==
#!/bin/sh
PATH=/usr/bin
CWD="$(pwd)"
LATEST_TAG="$(git tag --sort=taggerdate | tail -n 1)"
git log --format=%s ${LATEST_TAG}.. | tac | while read line ; do
first=1
echo "${line}" | sed -e 's|%|%%|g' | fold -s -w 70 | \
while read subline ; do
if [ ${first} -eq 1 ]; then
echo "- ${subline}"
first=0
else
echo " ${subline}"
fi
done
done
==
I take this output and paste it in the spec file and then delete the lines I
don't want. Could be expanded to take a repo as a parameter, etc.
Or just add some RPM metadata tags to record the upstream SCM type + URL +
branch / release tag, etc. The user can thus easily find the upstream
full commit logs corresponding to the pacakge.
That works too. A %global upstream_changelog and "rpm -q --changelog"
could look for that and display the value if it exists --or-- pull down
the info and display it for minimal impact to current users.
--
David Cantrell
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: Ohio LinuxFest 2019
Ben, I'm in Colorado, but absolutely willing to travel to Ohio to help staff the booth... I don't know if there is budget for travel, but if there is, and there is no one closer who wants to help, let me know! :) Geoff Marr IRC: coremodule On Wed, Oct 2, 2019 at 1:48 PM Ben Cotton wrote: > I proposed a Fedora BoF for Ohio LinuxFest[1], to be held 1–2 November > in Columbus, Ohio, USA. The BoF is accepted, and the organizers said > there is still expo space available. > > I didn't get a reponse on the Ambassadors list when I asked if we'll > have a presence there, but I'll get us a Fedora booth if I can find at > least a few people willing to staff it. I'd like for us to connect > with some potential contributors, particularly in non-code areas in > addition to talking to existing Fedora contributors and users. > > If you don't want to staff a booth, I hope if you're in the area > you'll stop by the BoF. I'll post it to the Events calendar[2] on > Fedocal once the schedule is published. > > [1] https://ohiolinux.org/ > [2] https://apps.fedoraproject.org/calendar/Events/ > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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: Old changelog entries removal
On Thu, Oct 03, 2019 at 09:16:15AM -0500, Chris Adams wrote: > > I think rather than this, we should bite the bullet and remove changelogs > > entirely from spec files. > I find "rpm -q --changelog" useful (at least when maintainers put useful > info there, which isn't always), so please don't. I know -- I'm a former sysadmin myself and I'm pretty sure I made that same argument on this list several years ago. But let's not box ourselves in. There's plenty of ways to provide equivalent and perhaps more useful information in a similarly easy on-system fashion *without* the specfile mess. -- Matthew Miller Fedora Project Leader ___ 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: Old changelog entries removal
On Thu, 2019-10-03 at 09:37 -0500, Chris Adams wrote: > Once upon a time, Daniel P. Berrangé said: > > Or just add some RPM metadata tags to record the upstream SCM type + URL + > > branch / release tag, etc. The user can thus easily find the upstream > > full commit logs corresponding to the pacakge. > > IMHO that is only good when the Fedora package is nothing but the > upstream code, built with defaults. As soon as Fedora needs to add a > patch and/or systemd unit(s), change options, etc., there should be a > Fedora changelog. Also, the current changelogs are self contained & do not require internet access. Remote changelog URLs might become inaccessible over time, making tracking down behavior changes & tricky bugs problematic. > > And even when it's a straight build of upstream, some maintainers > include RH Bugzilla numbers in their changelog entries, which is useful > too. > > -- > Chris Adams > ___ > 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: Old changelog entries removal
On Thu, Oct 03, 2019 at 09:37:31AM -0500, Chris Adams wrote: > Once upon a time, Daniel P. Berrangé said: > > Or just add some RPM metadata tags to record the upstream SCM type + URL + > > branch / release tag, etc. The user can thus easily find the upstream > > full commit logs corresponding to the pacakge. > > IMHO that is only good when the Fedora package is nothing but the > upstream code, built with defaults. As soon as Fedora needs to add a > patch and/or systemd unit(s), change options, etc., there should be a > Fedora changelog. I doesn't have to be mutually exclusive with RPM changelogs. I think having a record of upstream SCM would be useful regardless. Many times when submitting patches to Fedora packages, I've been told to send my patch to upstream insteadwhich means trying to figure out where that upstream is for this given RPM. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: Defining the future of the packager workflow in Fedora
Dne 03. 10. 19 v 15:56 Miro Hrončok napsal(a): > On 03. 10. 19 15:23, Vít Ondruch wrote: >> >> Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a): >>> Miro Hrončok wrote: On 03. 10. 19 1:32, Kevin Fenzi wrote: > I'm not sure how to handle the dychomoty between having different > spec > files for each release and wanting to maintain just one spec that > has a > bunch of crazy conditionals in it. Even thought I do this too, I > think > we need a workflow that discourages this somehow. I believe that moving release tag and changelog entry to annotated tags solves this problem (or makes it insignificant). It means you can just cleanly cherry pick a fix anywhere it is relevant (most of the time) instead of fighting the changelog conflicts all the time. >>> I don't understand the people actually maintaining different >>> changelogs for >>> the releases. I just merge master into the release branches when I >>> push an >>> update, and if that includes some changelog entries for Rawhide-only >>> mass >>> rebuilds, so be it. Removing them is not worth breaking >>> fast-forwardability >>> of the branches. >> >> >> It depends how you maintain your packages. My guess is (and I am sorry >> if I am mistaken) that you don't follow the >> >> https://fedoraproject.org/wiki/Updates_Policy#Philosophy > > I do. > >> If you followed this policy, then you would touch the stable branches >> just rarely and therefore keeping them fast forwardable would be just >> waste of time. > > I touch stable branches for bugfix upgrades. > But this sooner or later means rebase in Rawhide and just applying patches in the stable branch. So my point still stands. Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Old changelog entries removal
Once upon a time, Daniel P. Berrangé said: > I think having a record of upstream SCM would be useful regardless. Many > times when submitting patches to Fedora packages, I've been told to send > my patch to upstream insteadwhich means trying to figure out where > that upstream is for this given RPM. "rpm -qi" and look at the URL? The other thing that makes source code changelogs less useful in some cases is that they are often very verbose, with info that isn't clear to end users. They show changes that are often not relevant (like maybe between release 1.2.1 and 1.2.2 they tried a fix to a bug and reverted it - who cares in terms of RPMs?). -- Chris Adams ___ 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: Defining the future of the packager workflow in Fedora
On Thu, 3 Oct 2019 at 11:20, Vít Ondruch wrote: > > > Dne 03. 10. 19 v 15:56 Miro Hrončok napsal(a): > > On 03. 10. 19 15:23, Vít Ondruch wrote: > >> > >> Dne 03. 10. 19 v 11:58 Kevin Kofler napsal(a): > >>> Miro Hrončok wrote: > On 03. 10. 19 1:32, Kevin Fenzi wrote: > > I'm not sure how to handle the dychomoty between having different > > spec > > files for each release and wanting to maintain just one spec that > > has a > > bunch of crazy conditionals in it. Even thought I do this too, I > > think > > we need a workflow that discourages this somehow. > I believe that moving release tag and changelog entry to annotated > tags > solves this problem (or makes it insignificant). > > It means you can just cleanly cherry pick a fix anywhere it is > relevant > (most of the time) instead of fighting the changelog conflicts all the > time. > >>> I don't understand the people actually maintaining different > >>> changelogs for > >>> the releases. I just merge master into the release branches when I > >>> push an > >>> update, and if that includes some changelog entries for Rawhide-only > >>> mass > >>> rebuilds, so be it. Removing them is not worth breaking > >>> fast-forwardability > >>> of the branches. > >> > >> > >> It depends how you maintain your packages. My guess is (and I am sorry > >> if I am mistaken) that you don't follow the > >> > >> https://fedoraproject.org/wiki/Updates_Policy#Philosophy > > > > I do. > > > >> If you followed this policy, then you would touch the stable branches > >> just rarely and therefore keeping them fast forwardable would be just > >> waste of time. > > > > I touch stable branches for bugfix upgrades. > > > > But this sooner or later means rebase in Rawhide and just applying > patches in the stable branch. So my point still stands. Which point? You have had multiple. The one where you say doesn't follow the procedure does not stand. -- 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: Defining the future of the packager workflow in Fedora
On Thu, 2019-10-03 at 11:58 +0200, Kevin Kofler wrote: > I even go as far as reverting branch-only commits and then doing the > bidirectional merge trick to restore fast forwardability. That of > course > clobbers the branch-only changelog section and replaces it with the > one from > master, but that's just how things are. Again, I think fast- > forwardability > is more useful than per-branch changelogs. It's not an either-or. If you resolve the conflict, you can have fast- forwarding *and* not pass irrelevant/confusing changelogs on to the end user. I personally avoid if statements in spec files and just resolve conflicts. As pointed out elsewhere, we would have fewer conflicts if we could get the version, release, and changelog out of the spec file, and then I think maintaining different spec in different release branches would be easier than it is today. signature.asc Description: This is a digitally signed message part ___ 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: Defining the future of the packager workflow in Fedora
On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote: > On Wed, 2 Oct 2019 at 19:34, Matthew Miller > wrote: > > > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote: > > > > ○ Every changes to dist-git is done via pull-requests > > > Erm, no thank you. Pull requests are a terrible workflow. > > > > It's definitely the winning workflow in the open source world today, > > particularly for smaller and drive-by contributions, which I think we'd > > like to encourage. And there _are_ real tracking and review benefits to > > having everything go through that workflow. > > > > > Do you have an alternative proposal? > > > > Continuous Integration can be done without PRs (this is not easy in the > open source world because you cannot grant commit access to every > contributors, this is not a problem for us since only the package > maintainers have commit access), in fact eXtrem Programming [0] is all > about pushing as often and as fast as possible to the main branch in order > to get early feedback. Instead of running the tests against a PR it is > possible to run the tests against the commits in the main development > branch. I believe that in our case knowing if a particular commit broke the > branch is as valuable as knowing if the tests failed against a PR. > Yeah, no thanks. As someone who endlessly chasing breakages I can tell you it is miserable. That approach sounds like an eXtremly good way for folks to just walk away from the project. We can have machines check for correctness with tests, why on earth would you enforce that check *after* accepting changes? - Jeremy ___ 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: Old changelog entries removal
On Thu, Oct 03, 2019 at 10:19:40AM -0500, Chris Adams wrote: > The other thing that makes source code changelogs less useful in some > cases is that they are often very verbose, with info that isn't clear to > end users. They show changes that are often not relevant (like maybe > between release 1.2.1 and 1.2.2 they tried a fix to a bug and reverted > it - who cares in terms of RPMs?). Yeah: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YDN6EODKKIG2U6HHTY6DGRZZ2IJO64CG/ -- Matthew Miller Fedora Project Leader ___ 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: Defining the future of the packager workflow in Fedora
On Wed, Oct 2, 2019 at 9:20 PM Neal Gompa wrote: > > Unfortunately, it doesn't scale for the large number of packages we > have. Pull requests would work if we had mergify[1] working on > Dist-Git, otherwise I can't see how it'd work. > > [1]: https://github.com/Mergifyio/mergify-engine > > Since some months we (the team that maintain softwarefactory-project.io and review.rdoproject.org) are working on making Zuul [1] compatible with Pagure in order to implement a packager workflow through Zuul's jobs around the Pull Request model. Zuul is a powerful gating system, scalable, that support cross-repository jobs and artifacts sharing between jobs out of the box. Zuul's jobs are Ansible playbooks. We managed to do great progress that we shown at last Flock. We are tracking the progress in this EPIC [2]. Here is how a project is configured: [3], the template is defined like so: [4], and here the job definition of rawhide-rpm-scratch-build: [5] Zuul's jobs configuration is flexible and we can provide templates that fit different needs, whether the packager want a full workflow (from the scratch build, various validation jobs such as linting/rpminspect to the regular build) or just the scratch build. We will soon propose this as an opt-in service for the interested packagers. CI resources capacity will come from softwarefactory-project.io. [1]: https://zuul-ci.org/ [2]: https://teams.fedoraproject.org/project/ci/epic/14 [3]: https://pagure.io/fedora-zuul-jobs-config/blob/master/f/zuul.d/projects.yaml#_5 [4]: https://pagure.io/fedora-zuul-jobs/blob/master/f/zuul.d/templates.yaml [5]: https://pagure.io/fedora-zuul-jobs/blob/master/f/zuul.d/jobs.yaml#_1 ___ 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: Old changelog entries removal
On 10/3/19 9:45 AM, Martin Kolman wrote: Also, the current changelogs are self contained & do not require internet access. Remote changelog URLs might become inaccessible over time, making tracking down behavior changes & tricky bugs problematic. Yes, there are systems that do not have Internet access. Examples: - Classified systems with no access at all - Proxy restricted systems (behind a web filter that may block) It's incredibly helpful to have rpm -q $PKG --changelog available. Whatever change is made it needs to be available offline. ___ 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: Old changelog entries removal
On Thu, Oct 03, 2019 at 11:13:32AM -0500, Michael Cronenworth wrote: > >Remote changelog URLs might become inaccessible over time, making tracking > >down > >behavior changes & tricky bugs problematic. > Yes, there are systems that do not have Internet access. > Examples: > - Classified systems with no access at all > - Proxy restricted systems (behind a web filter that may block) > It's incredibly helpful to have rpm -q $PKG --changelog available. > Whatever change is made it needs to be available offline. I think providing whatever as a %doc would fit most use-cases. Or it could be a special document thing like %license. -- Matthew Miller Fedora Project Leader ___ 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
Logs of the weekly NeuroFedora meeting: October 3, 2019
Hello, Here are the logs from today's meeting. The next meeting will be in a week's time. It will be chaired by @ankursinha (me). - HTML logs: https://meetbot.fedoraproject.org/fedora-neuro/2019-10-03/neurofedora.2019-10-03-15.06.log.html - HTML minutes: https://meetbot.fedoraproject.org/fedora-neuro/2019-10-03/neurofedora.2019-10-03-15.06.html The text minutes are pasted below for your convenience: = #fedora-neuro: "NeuroFedora - 2019-10-03" = Meeting started by bt0 at 15:06:58 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-neuro/2019-10-03/neurofedora.2019-10-03-15.06.log.html . Meeting summary --- * Introductions and Roll call (bt0, 15:07:45) * Alberto Rodriguez (bt0dotninja), UTC-5 (America/Mexico-City), CommOps, Marketing, packaging, neurofedora, Fedora-Join and more... (bt0, 15:08:13) * Ankur Sinha (ankursinha/FranciscoD): UTC+1 (Europe/London), NeuroFedora, Join, Packaging, and a few others :) (FranciscoD, 15:08:54) * Today's agenda (bt0, 15:13:37) * Pagure tickets at: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting (bt0, 15:13:56) * Open bugs at: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=neuro-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emaildocs_contact1=1&emaillongdesc1=1&emailqa_contact1=1&emailreporter1=1&emailtype1=substring&list_id=10455921&query_format=advanced (bt0, 15:13:56) * Review of current progress (bt0, 15:14:15) * Action items from previous meeting (bt0, 15:14:16) * Planning what we want to do next (bt0, 15:14:16) * Neuroscience query of the week (bt0, 15:14:16) * Next meeting chair selection (bt0, 15:14:16) * Open floor (bt0, 15:14:16) * Review of pagure tickets (bt0, 15:15:29) * https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting (bt0, 15:16:00) * Ticket #293 (bt0, 15:17:58) * https://pagure.io/neuro-sig/NeuroFedora/issue/293 (bt0, 15:18:06) * Ticket #250 (bt0, 15:23:06) * https://pagure.io/neuro-sig/NeuroFedora/issue/250 (bt0, 15:23:11) * LINK: https://fedorapeople.org/groups/neuro-sig/ (FranciscoD, 15:33:05) * LINK: https://fedorapeople.org/groups/neuro-sig/Fedora-31-Comp-Neuro-20191003-1.iso (FranciscoD, 15:33:11) * ACTION: MeWjOr think about whether tags would help on the neuro-scripts repo and add them if required (FranciscoD, 15:38:44) * ACTION: MeWjOr file an issue and investigate why the comp-neuro installer looks like the netinstaller and not the live workstation one (FranciscoD, 15:39:08) * Planning what we want to do next (bt0, 15:40:36) * Change proposal https://fedoraproject.org/wiki/Changes/Comp_Neuro_Lab (FranciscoD, 15:41:35) * Tracker bug https://bugzilla.redhat.com/show_bug.cgi?id=1758209 (FranciscoD, 15:41:42) * FESCo approval: https://pagure.io/fesco/issue/2237 (FranciscoD, 15:41:54) * At the moment we have 47 neuro-imaging related tools in the packaging queue: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=F%3A+Neuroimaging (FranciscoD, 15:44:04) * LINK: https://apps.fedoraproject.org/packages/InsightToolkit/ (FranciscoD, 15:47:36) * InsightToolkit updating bug https://bugzilla.redhat.com/show_bug.cgi?id=1340300 (MeWjOr, 15:48:51) * ACTION: mhough create a new ticket to document what ITK features we need enabled (FranciscoD, 15:50:33) * ACTION: mhough block other packages that need these features (FranciscoD, 15:50:56) * ACTION: FranciscoD look at updating ITK to new version (FranciscoD, 15:51:07) * ACTION: FranciscoD sponsor mhough to packagers and e-mail -devel letting community know (FranciscoD, 15:55:32) * ACTION: FranciscoD write blog post on neurofedora updates (FranciscoD, 15:55:48) * ACTION: mhough share desktop file with MeWjOr to figure out tweaks (FranciscoD, 15:57:14) * Chair for next week (FranciscoD, 16:01:12) * FranciscoD will chair next week's meeting (FranciscoD, 16:02:15) * Open Floor (FranciscoD, 16:02:37) * LINK: https://medium.com/the-spike/why-model-the-brain-c7a8e160e566 -> is an easier post to read (FranciscoD, 16:17:08) * LINK: https://www.nest-simulator.org/helpindex/cc/aeif_cond_alpha.html -> all units listed there (FranciscoD, 16:24:29) Meeting ended at 16:25:29 UTC. Action Items * MeWjOr think about whether tags would help on the neuro-scripts repo and add them if required * MeWjOr file an issue and investigate why the comp-neuro installer looks like the netinstaller and not the live workstation one * mhough create a new ticket to document what ITK features we need enabled * mhough block other packages th
Re: Old changelog entries removal
> "MM" == Matthew Miller writes: MM> Whether or not it's documented policy (and I can't remember or find MM> anything either), many packages have the practice of trimming very MM> old entries. You can't always do this. I tried to purge changelog entries from a package older than 2010 and was not permitted to do so: https://src.fedoraproject.org/rpms/cyrus-imapd/c/4672136ce3276859bc1971075a87a30a47f9995b?branch=master All I could figure was that the person who originally developed the packages back before 2006 had objected that their changelog entries had been removed. There might even have been some kind of agreement between them and Red Hat which of course isn't documented anywhere, and shouldn't apply to Fedora anyway. So I'd certainly love it if there was a distro-wide policy about this, with a requirement that weird exceptional cases like this be documented publicly. There is also valid discussion to be had about giving credit, and whether changelog entries are a valid way of accomplishing that. (I would argue that they aren't and that the SCM history should be sufficient, but I personally don't care if my name is in the credits or not.) - J< ___ 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: Defining the future of the packager workflow in Fedora
On Thu, Oct 3, 2019, 17:43 Jeremy Cline wrote: > On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote: > > On Wed, 2 Oct 2019 at 19:34, Matthew Miller > > wrote: > > > > > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote: > > > > > ○ Every changes to dist-git is done via pull-requests > > > > Erm, no thank you. Pull requests are a terrible workflow. > > > > > > It's definitely the winning workflow in the open source world today, > > > particularly for smaller and drive-by contributions, which I think we'd > > > like to encourage. And there _are_ real tracking and review benefits to > > > having everything go through that workflow. > > > > > > > > Do you have an alternative proposal? > > > > > > > Continuous Integration can be done without PRs (this is not easy in the > > open source world because you cannot grant commit access to every > > contributors, this is not a problem for us since only the package > > maintainers have commit access), in fact eXtrem Programming [0] is all > > about pushing as often and as fast as possible to the main branch in > order > > to get early feedback. Instead of running the tests against a PR it is > > possible to run the tests against the commits in the main development > > branch. I believe that in our case knowing if a particular commit broke > the > > branch is as valuable as knowing if the tests failed against a PR. > > > > Yeah, no thanks. As someone who endlessly chasing breakages I can tell > you it is miserable. That approach sounds like an eXtremly good way for > folks to just walk away from the project. > > We can have machines check for correctness with tests, why on earth > would you enforce that check *after* accepting changes? > I think that it would be better to know which commit messed up your branch than not (currently the case). Currently there is no concept of "accepting a change" for packages, since packagers are just pushing commits to branches. To me running tests after the push is a good compromise and I don't see how that would drive people out of the project compare to enforcing all changes to be made via PR. > - Jeremy > ___ > 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: Old changelog entries removal
* Daniel P. Berrangé [03/10/2019 14:47] :
>
> FWIW, my approach is to purge all changelog entries older than 2 years
> the first time I touch a package in January each year. Is there any value
> in having guidelines to encourage some policy in this area, so maintainer
> approach it in a consistent way ?
FTR, this is done automatically by this snippet in redhat-rpm-config:
# Automatically trim changelog entries after 2 years
%_changelog_trimtime%{lua:print(os.time() - 2 * 365 * 86400)}
https://bugzilla.redhat.com/show_bug.cgi?id=1722806
Emmanuel
___
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: Defining the future of the packager workflow in Fedora
On Thu, Oct 03, 2019 at 11:42:02AM -0400, Randy Barlow wrote: > On Thu, 2019-10-03 at 11:58 +0200, Kevin Kofler wrote: > > I even go as far as reverting branch-only commits and then doing the > > bidirectional merge trick to restore fast forwardability. That of > > course > > clobbers the branch-only changelog section and replaces it with the > > one from > > master, but that's just how things are. Again, I think fast- > > forwardability > > is more useful than per-branch changelogs. > > It's not an either-or. If you resolve the conflict, you can have fast- > forwarding *and* not pass irrelevant/confusing changelogs on to the end > user. > > I personally avoid if statements in spec files and just resolve > conflicts. > > As pointed out elsewhere, we would have fewer conflicts if we could get > the version, release, and changelog out of the spec file, and then I > think maintaining different spec in different release branches would be > easier than it is today. Small correction: not the version. Just the release and changelog. 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
Request to re-review jboss-logging-tools package
Hello everyone! We, the Dogtag PKI team, would like to revive the jboss-logging-tools which was retired as part of the Fedora orphaning process. This package is a direct dependency for dogtag-pki project, which in turn is a dependency for FreeIPA. I'd honored if someone can review [1] our package and help revive it. [1] Review ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1758293 Thanks, --Dinesh signature.asc Description: This is a digitally signed message part ___ 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
Don't add default contents in `fedpkg request-branch` tickets Was: Re: can we merge package.cfg into master
On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote: > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote: > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto > > wrote: > > > Hi, > > > epel 8 brings a new file called package.cfg, I strongly prefer to > > > keep > > > branches mergeable with fast forward , may we merge this into > > > master ? > > > like I did in pngquant [1] > > > > > > > It disables the normal build behavior for all non-master branches, so > > you don't want to do that. > > Well , I want keep my branches mergeable ! Same problem. I came across several epel8 branch requests ... and there always is some default 'package.cfg' file I don't really mind as I observed (the builds against epel8 just succeed without that). More, sometimes the README.md is added. Could we stop doing that? Unless it is really reasonable, I don't plan to make differences in maintained branches, and to achieve that with the current approach -- I have to go the ugly way (merge epel8 to master and vice versa, so histories in all branches are ugly forever). It would be better if we were either "just" allowed to push to not-yet-existing branch, or optionally begin the branch from in-advance specified hash. Pavel > > > > > > -- > > 真実はいつも一つ！/ Always, there's only one truth! > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- > Sérgio M. B. > ___ > 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: Request to re-review jboss-logging-tools package
On Thu, Oct 3, 2019 at 9:11 PM Dinesh Prasanth Moluguwan Krishnamoorthy wrote: > > Hello everyone! > > We, the Dogtag PKI team, would like to revive the jboss-logging-tools > which was retired as part of the Fedora orphaning process. > > This package is a direct dependency for dogtag-pki project, which in > turn is a dependency for FreeIPA. > > I'd honored if someone can review [1] our package and help revive it. I've assigned the review request to me, and left some initial comments. Fabio > [1] Review ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1758293 > > Thanks, > --Dinesh ___ 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 32 System-Wide Change proposal: binutils 2.33
https://fedoraproject.org/wiki/Changes/BINUTILS233 == Summary == Rebase the binutils package from version 2.32 to version 2.33. == Owner == * Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc] * Email: ni...@redhat.com == Detailed Description == Switch the binutils package from being based on the 2.32 release of the GNU binutils to being based on the 2.33 release. This release will bring in numerous bug fixes, as well as support for the CTF debug format. == Benefit to Fedora == The main benefit will be the bug fixes and the improvement to the linker. In addition the new support for the CTF debug format will help consumers of CTF, most notably the kernel. == Scope == * Proposal owners: Change the source parameter in the binutils.spec rpm and adjust the local patches to take account of the bugs that are now already fixed. This is a significant change to the underlying tools used to build Fedora and so there should be a mass rebuild in order for the changes to be noticed across the system. * Other developers: No other work should be necessary. Once the rebase is in place and the buildroot contains the new binutils its use should be automatic. * Release engineering: [https://pagure.io/releng/issue/8837] A mass rebuild will be required. * Policies and guidelines: No update needed. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The binutils are backwards compatible with previous releases, so no changes should be necessary. == How To Test == The binutils package does include its own set of testsuites which check basic functionality. The real test however is by rebuilding other packages which depend upon the binutils, or more likely, upon gcc. If these packages continue to work then the binutils update has not broken anything. == User Experience == The change should not be noticeable to the user. == Dependencies == This update has no hard dependencies on any other package. There are other packages that do depend upon the binutils however. Most notably gcc and redhat-rpm-config. == Contingency Plan == * Contingency mechanism: Revert to the 2.32 binutils as currently used in rawhide. This work can be done by me, should it prove necessary. * Contingency deadline: Beta Freeze. == Documentation == Documentation is not currently available, due to the fact that the 2.33 release has not yet been created. (It is hoped that the release will happen before the Fedora 32 mass rebuild). -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
License in spec file
I'm trying to build an RPM of a python package. The LICENSE file of the python package states that it is released under MIT license. But there is a file, _version.py, where you can read: Parts of `extract_components` are taken from the pypa packaging project (https://github.com/pypa/packaging) which is dual licensed: > This file is dual licensed under the terms of the Apache License, Version > 2.0, and the BSD License. See the LICENSE file in the root of (the pypa) > repository for complete details. The question is, what should I put in the License tag of the SPEC file? Is MIT sufficient? Thanks, A. ___ 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: License in spec file
On 03. 10. 19 23:34, alcir...@gmail.com wrote: I'm trying to build an RPM of a python package. The LICENSE file of the python package states that it is released under MIT license. But there is a file, _version.py, where you can read: Parts of `extract_components` are taken from the pypa packaging project (https://github.com/pypa/packaging) which is dual licensed: This file is dual licensed under the terms of the Apache License, Version 2.0, and the BSD License. See the LICENSE file in the root of (the pypa) repository for complete details. The question is, what should I put in the License tag of the SPEC file? MIT and (BSD or ASL 2.0) Don't forget to put a comment into spec that explains this, like: # mostly MIT, parts of extract_components from python-packaging (BSD or ASL 2.0) License: MIT and (BSD or ASL 2.0) Is MIT sufficient? No. -- 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
Re: Fwd: bodhi submitted ntl-11.3.4-1.fc32 to stable
On Wed, Oct 2, 2019 at 11:45 AM Kevin Fenzi wrote: > So, this is my 'fault' I guess. > > There were some builds stuck in the signing tag in rawhide, so I > retagged them to get them signed and in. In this case it made an 'older' > build show up. ;( > > I'll check f32 for older builds and fix them all. > > The cause of some builds not being signed seems to be fas throwing 500 > errors sporadically. We are trying to track down the cause of that now. Thanks for fixing it, Kevin. Good luck tracking down the 500 errors. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Test-Announce] Fedora 31 Branched 20191003.n.1 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 31 Branched 20191003.n.1. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20190928.n.0: anaconda-31.22.4-1.fc31.src, 20191003.n.1: anaconda-31.22.5-1.fc31.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/31 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20191003.n.1_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20191003.n.1_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20191003.n.1_Base https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20191003.n.1_Server https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20191003.n.1_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20191003.n.1_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_31_Branched_20191003.n.1_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Defining the future of the packager workflow in Fedora
On Thu, Oct 03, 2019 at 08:42:36PM +0200, Clement Verna wrote: > On Thu, Oct 3, 2019, 17:43 Jeremy Cline wrote: > > > On Wed, Oct 02, 2019 at 08:26:16PM +0200, Clement Verna wrote: > > > On Wed, 2 Oct 2019 at 19:34, Matthew Miller > > > wrote: > > > > > > > On Wed, Oct 02, 2019 at 05:31:56PM +0100, Richard W.M. Jones wrote: > > > > > > ○ Every changes to dist-git is done via pull-requests > > > > > Erm, no thank you. Pull requests are a terrible workflow. > > > > > > > > It's definitely the winning workflow in the open source world today, > > > > particularly for smaller and drive-by contributions, which I think we'd > > > > like to encourage. And there _are_ real tracking and review benefits to > > > > having everything go through that workflow. > > > > > > > > > > > Do you have an alternative proposal? > > > > > > > > > > Continuous Integration can be done without PRs (this is not easy in the > > > open source world because you cannot grant commit access to every > > > contributors, this is not a problem for us since only the package > > > maintainers have commit access), in fact eXtrem Programming [0] is all > > > about pushing as often and as fast as possible to the main branch in > > order > > > to get early feedback. Instead of running the tests against a PR it is > > > possible to run the tests against the commits in the main development > > > branch. I believe that in our case knowing if a particular commit broke > > the > > > branch is as valuable as knowing if the tests failed against a PR. > > > > > > > Yeah, no thanks. As someone who endlessly chasing breakages I can tell > > you it is miserable. That approach sounds like an eXtremly good way for > > folks to just walk away from the project. > > > > We can have machines check for correctness with tests, why on earth > > would you enforce that check *after* accepting changes? > > > > I think that it would be better to know which commit messed up your branch > than not (currently the case). Currently there is no concept of "accepting > a change" for packages, since packagers are just pushing commits to > branches. To me running tests after the push is a good compromise and I > don't see how that would drive people out of the project compare to > enforcing all changes to be made via PR. > My reaction was mostly to the concept of pushing everything as fast as possible to a "main branch". And yes, running some tests after the fact is better than running no tests ever (and has other purposes). However, finding problems *before* they happen is orders of magnitude more valuable than just merging, hoping, and testing afterwards to figure out where your hope strategy let you down. It should be encouraged by making the workflow the best choice for the developer, not by forcing them down that path. Furthermore, it's a compromise you don't have to make. Do what ever other CI system does: allow it to run on PRs *and* on whatever branches you want... Perhaps even continuously* on a branch or branches to ensure it integrates with components properly. *for some value of continuous ___ 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: Fwd: bodhi submitted ntl-11.3.4-1.fc32 to stable
On Thu, Oct 03, 2019 at 04:32:04PM -0600, Jerry James wrote: > On Wed, Oct 2, 2019 at 11:45 AM Kevin Fenzi wrote: > > So, this is my 'fault' I guess. > > > > There were some builds stuck in the signing tag in rawhide, so I > > retagged them to get them signed and in. In this case it made an 'older' > > build show up. ;( > > > > I'll check f32 for older builds and fix them all. > > > > The cause of some builds not being signed seems to be fas throwing 500 > > errors sporadically. We are trying to track down the cause of that now. > > Thanks for fixing it, Kevin. Good luck tracking down the 500 errors. We think we have those fixed now. If anyone sees errors from fas, please let us know. 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: New updates straight to obsolete after Epoch bump?!?
Anyone have any ideas? I tried re-submitting them but they were obsoleted by bodhi again. Thanks, Richard > ___ 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 31 compose report: 20191003.n.1 changes
OLD: Fedora-31-20191001.n.0
NEW: Fedora-31-20191003.n.1
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 35
Dropped packages:2
Upgraded packages: 98
Downgraded packages: 0
Size of added packages: 59.73 MiB
Size of dropped packages:327.71 KiB
Size of upgraded packages: 5.15 GiB
Size of downgraded packages: 0 B
Size change of upgraded packages: 6.87 MiB
Size change of downgraded packages: 0 B
= ADDED IMAGES =
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-armhfp-31-20191003.n.1-sda.raw.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-31-20191003.n.1.iso
= DROPPED IMAGES =
= ADDED PACKAGES =
Package: R-AsioHeaders-1.12.1.1-1.fc31
Summary: Asio C++ Header Files
RPMs:R-AsioHeaders-devel
Size:349.52 KiB
Package: R-systemfonts-0.1.1-1.fc31
Summary: System Native Font Finding
RPMs:R-systemfonts
Size:190.64 KiB
Package: R-wesanderson-0.3.6-1.fc31
Summary: Wes Anderson Palette Generator
RPMs:R-wesanderson
Size:28.97 KiB
Package: cutter-1.2.6-3.fc29
Summary: Unit Testing Framework for C/C++
RPMs:cutter cutter-devel cutter-gui cutter-report
Size:3.74 MiB
Package: gap-pkg-cohomolo-1.6.8-1.fc31
Summary: Cohomology groups of finite groups on finite modules
RPMs:gap-pkg-cohomolo gap-pkg-cohomolo-doc
Size:1.78 MiB
Package: gap-pkg-corelg-1.51-1.fc31
Summary: Computation with real Lie groups
RPMs:gap-pkg-corelg gap-pkg-corelg-doc
Size:910.58 KiB
Package: gap-pkg-curlinterface-2.1.1-1.fc31
Summary: Simple web access for GAP
RPMs:gap-pkg-curlinterface gap-pkg-curlinterface-doc
Size:300.27 KiB
Package: gap-pkg-datastructures-0.2.4-1.fc31
Summary: Standard data structures for GAP
RPMs:gap-pkg-datastructures gap-pkg-datastructures-doc
Size:687.86 KiB
Package: gap-pkg-liealgdb-2.2-1.fc31
Summary: Database of Lie algebras
RPMs:gap-pkg-liealgdb gap-pkg-liealgdb-doc
Size:523.38 KiB
Package: gap-pkg-liepring-1.9.2-1.fc31
Summary: Database and algorithms for Lie p-rings
RPMs:gap-pkg-liepring gap-pkg-liepring-doc
Size:1.62 MiB
Package: gap-pkg-liering-2.4.1-1.fc31
Summary: Computing with finitely presented Lie rings
RPMs:gap-pkg-liering gap-pkg-liering-doc
Size:516.27 KiB
Package: gap-pkg-loops-3.4.1-1.fc31
Summary: Computing with quasigroups and loops
RPMs:gap-pkg-loops gap-pkg-loops-doc
Size:977.91 KiB
Package: gap-pkg-mapclass-1.4.4-1.fc31
Summary: Calculate mapping class group orbits for a finite group
RPMs:gap-pkg-mapclass gap-pkg-mapclass-doc
Size:296.39 KiB
Package: gap-pkg-quagroup-1.8.1-1.fc31
Summary: Computations with quantum groups
RPMs:gap-pkg-quagroup gap-pkg-quagroup-doc
Size:544.54 KiB
Package: gap-pkg-repsn-3.1.0-1.fc31
Summary: Representations of finite groups
RPMs:gap-pkg-repsn gap-pkg-repsn-doc
Size:256.49 KiB
Package: gap-pkg-sla-1.5.2-1.fc31
Summary: Computing with simple Lie algebras
RPMs:gap-pkg-sla gap-pkg-sla-doc
Size:807.34 KiB
Package: golang-github-bep-tmc-0.5.1-1.fc31
Summary: Basic map[string]interface{} JSON roundtrip with custom adapters
RPMs:golang-github-bep-tmc-devel
Size:15.38 KiB
Package: golang-github-captncraig-caddy-realip-0-0.1.20190922git6df827e.fc31
Summary: Real-IP middleware for caddy
RPMs:golang-github-captncraig-caddy-realip-devel
Size:14.65 KiB
Package: golang-github-google-cmdtest-0.1.0-1.fc31
Summary: Simplify testing of command-line interfaces
RPMs:golang-github-google-cmdtest-devel
Size:22.34 KiB
Package: gstreamer-plugins-espeak-0.5.0-7.fc31
Summary: A simple gstreamer plugin to use espeak
RPMs:gstreamer-plugins-espeak
Size:194.62 KiB
Package: ibm-plex-fonts-2.0.0-1.fc31
Summary: IBM's Plex fonts
RPMs:ibm-plex-arabic-fonts ibm-plex-devanagari-fonts ibm-plex-fonts-common
ibm-plex-mono-fonts ibm-plex-sans-condensed-fonts ibm-plex-sans-fonts
ibm-plex-sans-hebrew-fonts ibm-plex-sans-thai-looped-fonts ibm-plex-serif-fonts
ibm-plex-thai-fonts
Size:4.80 MiB
Package: libdivide-2.0-1.fc31
Summary: Optimized integer division
RPMs:libdivide-devel
Size:28.36 KiB
Package: nodejs-gaze-0.5.1-7.fc27
Summary: A globbing fs.watch wrapper built from parts of other watch libraries
RPMs:nodejs-gaze
Size:16.86 KiB
Package: php-phpdocumentor-reflection-common2-2.0.0-2.fc31
Summary: Common reflection classes used by phpdocumentor
RPMs:php-phpdocumentor-reflection-common2
Size:11.95 KiB
Package: php-phpdocumentor-type-resolver1-1.0.1-1.fc31
Summary: A PSR-5 based resolver of Class names, Types and Structural Element
Names
RPMs:php-phpdocumentor-type-resolver1
Size:26.57 KiB
Package: php-phplang-scope-exit-1.0.0-2.fc31
Summary: Emulation of SCOPE_EXIT construct from C++
RPMs:php-phplang-scope-exit
Size:10.36 KiB
Package: php-scssphp-scssphp-1.0.4-1.fc31
Summary: Compiler for SCSS
RPMs:php-scssphp-scssphp
Size:70.39 KiB
Package
Fedora-31-20191003.n.1 compose check report
No missing expected images. Failed openQA tests: 5/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-31-20191001.n.0): ID: 462758 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/462758 ID: 462828 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/462828 Old failures (same test failed in Fedora-31-20191001.n.0): ID: 462751 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/462751 ID: 462764 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/462764 ID: 462787 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/462787 ID: 462798 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/462798 Soft failed openQA tests: 2/153 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-31-20191001.n.0): ID: 462780 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/462780 Old soft failures (same test soft failed in Fedora-31-20191001.n.0): ID: 462868 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/462868 Passed openQA tests: 146/153 (x86_64) New passes (same test not passed in Fedora-31-20191001.n.0): ID: 462740 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/462740 Skipped non-gating openQA tests: 1 of 155 Installed system changes in test x86_64 Server-boot-iso install_default@uefi: Mount / size changed from 7578 to 7978 MiB Mount /boot/efi size changed from 598 to 199 MiB Previous test data: https://openqa.fedoraproject.org/tests/461030#downloads Current test data: https://openqa.fedoraproject.org/tests/462719#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: Mount / size changed from 7578 to 7978 MiB Mount /boot/efi size changed from 598 to 199 MiB Previous test data: https://openqa.fedoraproject.org/tests/461034#downloads Current test data: https://openqa.fedoraproject.org/tests/462723#downloads Installed system changes in test x86_64 Everything-boot-iso install_default@uefi: Mount / size changed from 7404 to 7798 MiB Mount /boot/efi size changed from 598 to 199 MiB Previous test data: https://openqa.fedoraproject.org/tests/461064#downloads Current test data: https://openqa.fedoraproject.org/tests/462754#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: Used mem changed from 938 MiB to 736 MiB System load changed from 1.21 to 2.19 Previous test data: https://openqa.fedoraproject.org/tests/461081#downloads Current test data: https://openqa.fedoraproject.org/tests/462771#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: Mount / size changed from 7404 to 7798 MiB Mount /boot/efi size changed from 598 to 199 MiB 1 services(s) added since previous compose: pcscd.service System load changed from 0.72 to 1.04 Average CPU usage changed from 25.97142857 to 12.56190476 Previous test data: https://openqa.fedoraproject.org/tests/461083#downloads Current test data: https://openqa.fedoraproject.org/tests/462773#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Mount /sysroot size changed from 7404 to 7798 MiB Mount /boot/efi size changed from 598 to 199 MiB Previous test data: https://openqa.fedoraproject.org/tests/461101#downloads Current test data: https://openqa.fedoraproject.org/tests/462789#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: System load changed from 0.20 to 0.09 Previous test data: https://openqa.fedoraproject.org/tests/461099#downloads Current test data: https://openqa.fedoraproject.org/tests/462790#downloads Installed system changes in test x86_64 universal install_package_set_kde: System load changed from 1.00 to 2.40 Previous test data: https://openqa.fedoraproject.org/tests/461146#downloads Current test data: https://openqa.fedoraproject.org/tests/462838#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS-UP: PJHP 7.4 coming to rawhide
Le 02/10/2019 à 08:37, Remi Collet a écrit : > Hi, > > See: https://fedoraproject.org/wiki/Changes/php74 > Mass rebuild done php-7.4.0~RC3-1.fc32 graphviz-2.42.2-2.fc32 php-ast-1.0.3-2.fc32 php-facedetect-1.2.0-0.9.20180306gitc717941.fc32 php-geos-1.0.0-13.fc32 php-horde-horde-lz4-1.0.10-14.fc32 php-libvirt-0.5.4-9.fc32 php-maxminddb-1.5.0-2.fc32 php-pecl-amqp-1.9.4-4.fc32 php-pecl-apcu-5.1.17-3.fc32 php-pecl-apcu-bc-1.0.5-3.fc32 php-pecl-apfd-1.0.1-18.fc32 php-pecl-couchbase2-2.6.1-3.fc32 php-pecl-dio-0.1.0-11.fc32 php-pecl-ds-1.2.9-3.fc32 php-pecl-event-2.5.0-3.fc32 php-pecl-fann-1.1.1-14.fc32 php-pecl-gearman-2.0.6-2.fc32 php-pecl-geoip-1.1.1-11.fc32 php-pecl-gmagick-2.0.5~RC1-1.fc32 php-pecl-http-3.2.1-3.fc32 php-pecl-igbinary-3.0.1-3.fc32 php-pecl-imagick-3.4.4-3.fc32 php-pecl-inotify-2.0.0-9.fc32 php-pecl-json-post-1.0.1-16.fc32 php-pecl-krb5-1.1.2-6.fc32 php-pecl-lzf-1.6.7-3.fc32 php-pecl-mailparse-3.0.3-3.fc32 php-pecl-mcrypt-1.0.3-1.fc32 php-pecl-memcache-4.0.4-1.fc32 php-pecl-memcached-3.1.3-4.fc32 php-pecl-mongodb-1.6.0-2.fc32 php-pecl-msgpack-2.0.3-4.fc32 php-pecl-oauth-2.0.3-4.fc32 php-pecl-pcov-1.0.6-1.fc32 php-pecl-pq-2.1.5-4.fc32 php-pecl-propro-2.1.0-6.fc32 php-pecl-psr-0.7.0-2.fc32 php-pecl-radius-1.4.0-0.11.b1.fc32 php-pecl-raphf-2.0.0-12.fc32 php-pecl-redis5-5.0.2-2.fc32 php-pecl-rrd-2.0.1-13.fc32 php-pecl-selinux-0.4.2-5.fc32 php-pecl-solr2-2.5.0-3.fc32 php-pecl-ssdeep-1.1.0-6.fc32 php-pecl-ssh2-1.2-2.fc32 php-pecl-timecop-1.2.10-8.fc32 php-pecl-uopz-6.1.1-2.fc32 php-pecl-uuid-1.0.4-17.fc32 php-pecl-xattr-1.3.0-13.fc32 php-pecl-xdebug-2.8.0~beta2-2.fc32 php-pecl-xmldiff-1.1.2-13.fc32 php-pecl-yac-2.0.2-9.fc32 php-pecl-yaml-2.0.4-4.fc32 php-pecl-zip-1.15.5-2.fc32 php-phpiredis-1.0.0-14.fc32 php-smbclient-1.0.0-4.fc32 php-zstd-0.7.3-3.fc32 Not build as already FTBFS redland-bindings, mlt, remctl and ming New FTBFS with 7.4 libguestfs-1.41.4-2.fc32 #1758413 php-zmq-1.1.3-13.fc32 #1758410 Remi ___ 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
