Re: Unretire nodejs-gaze
On Wed, Oct 2, 2019 at 11:21 PM Jared K. Smith wrote: > > On Wed, Oct 2, 2019 at 9:32 AM Jared K. Smith > wrote: >> >> I blindly assumed it had been eight weeks already, so I requested a >> re-review at RHBZ#1755147. Obviously I'll just close that review request if >> we can get this unretired before the deadline. > > > It looks like this has been un-retired, so I'll go ahead and try to push an > updated build to rawhide just as soon as the Koji outage is over. Oops, I missed that you had requested a re-review. Thanks! Let me know if I can be of any help. Cheers, Ben Rosser ___ 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 Tue, Oct 1, 2019 at 4:09 PM Stephen Gallagher wrote: > > On Mon, Sep 23, 2019 at 10:21 AM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/ThermalManagementWS > > > > == Summary == > > Better thermal management and peak performance on Intel CPUs by > > including thermald in the default install. > > > Install the packages and use e.g. turbostat to monitor the > > performance. Improvements may only be visible if the non-free > > dptfxtract package is also installed. > > > > 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? We Privacy alert :) I'd rather we ship the database in the RPM (or a dedicated sub-package) and let the match happen locally. Dridi ___ 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, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote: > Good Morning Everyone, ...snip... So, a few thoughts in general on the thread and ideas... I think it might be helpfull for us to come up with some personas? I know that kind of thing seems silly a lot of the time, but I think we have some pretty clear ones and it would help us come up with a workflow that could work for much of our maintainers instead of just one group. ie, for example I think we have a group of folks who maintain a very small number of packages. These folks might be upstream maintaining their software as a fedora package or just someone who uses / cares for it. They want something simple where they can update packages/modules from upstream releases on an optional number of releases using just a tarball or other release artifacts. Then there's people who maintain 100's or many hundreds of packages, usually in a stack (perl, ruby, node, etc). They want the ability to update things but they also need to make big changes accross their collection of packages for improvments or changes in the ecosystem. There's people who maintain a application and it's deps who may need/want to update/test things in a bundle, etc. There's people who care about EPEL and want to follow the Fedora branches, but only if they don't make major changes. And likely other cases I haven't thought of in a few seconds of pondering, but we should definitely consider in our design. I think it's pretty clear that the "Everything is a PR" work flow doesn't work for everyone. As well as the "Sources are a git repo". So, I think a ideal setup would allow people to make choices and switch between them. Of course I don't think we should just allow everything, but we should have path's that cover a large group and choices only where we have to to accomodate the needs of the different groups. I like the idea of leveraging tags as a way to provide information to our new system what to build and test. Allowing commits without builds/testing would help the ecosystem user make a bunch of changes, then they could tag that what they have is ready to build/test/make an update out of, while a user doing just small updates could tag on every commit if they wanted to. Perhaps we could also determine all the information we want in tags and design it such that a web application, a cli application or even a user who understood the format could just git tag and enter the needed information. This would allow groups using each of those to all work the same way as they choose. If we went crazy far down this road: what if all our information is in tags? who can commit, whois watching, etc... but then we would have to hate ourselves enough to do gpg signed commits to make sure who was who. I think we all agree we need to handle release and changelogs in an automated way that lets commits/PR's be more generally useful. I also think we have not really any good tools for maintainers to know important things like: "what is the full list of everything my package depends on" or "Of all the things my package depends on, what hasn't been updated in X years" or "What media is my package on?" which we have wanted for ages. Not sure if that fits in here, but it would sure be nice to have, and it would be required for any of the 'rebuild things that depend on my package when I change it'. 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. Anyhow, I think it might be worth making some personas and trying to map out how tags could contain the information we might want and how that would look? 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
Review swap (htslib)
Hi all, Someone (especially proven packagers), could you review below library package related to bio science? It has already been reviewed several times. I think I fixed every items mentioned by a reviewer. Review Request: htslib - C library for high-throughput sequencing data formats (required for `samtools`) https://bugzilla.redhat.com/show_bug.cgi?id=1326504 Happy to review anything in exchange. Thanks. -- Jun | He - His - Him ___ 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
I'm late to the party, but here we go anyway. Pierre-Yves Chibon writes: > [snip] > > Here is what the vision we came to and that we would like to discuss: > > ○ Every changes to dist-git is done via pull-requests As long as this is not mandatory, sure. > ○ Pull-requests are automatically tested > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji Make that every tag and we are sold. > ○ Every build in koji results automatically in an update in bodhi > ○ Every update in bodhi is automatically tested > ○ If the tests pass, the update is automatically pushed to the repository So no more user's testing being able to test updates manually? I have packages where I'd actually prefer them to be tested manually (i3, i3status, i3lock, sway et al), because I haven't had the time to setup openQA for these yet. > > > For this workflow to work nicely we need to fix a few things first: > > - We need to work on the change logs in the spec files, as otherwise > pull-requests are going to conflict more often than not Let's please just get rid of them and the same for the Release tag (that should be automatically bumped by the build system on each rebuild, as we want automatic rebuilds, don't we?). > - We need to fine a place to insert the end-user information about an update > (in > the PR description?) The git tag as Randy & Jeremy suggested. > [snip] > > Do you like this vision? Would you change some pieces of it? Would you change > it > entirely? > In an ideal world, what would packaging software look like to you? Like a combination of our current way of doing things combined with openSUSE's Open Build Service (not only the automatic rebuild part, although that is nice too). What imho OBS did right is that it provides a single entry point for packaging: a unified web UI with all the information & build states and a unified CLI client for doing literally everything. You want to update package `foo`? `osc branch devel:FooProj:foo && osc checkout home:MyUserName:branches:devel:FooProj:foo`, make your changes there, commit them and send a submitrequest (something like a pull request). You want to become maintainer of a package? `osc reqmaintainership`. Who maintains `bar`? `osc maintainer bar`. And so on… So what I'd love to see would be the single entry point to packaging that Christopher described, not only as a web application, but also as a CLI client. To be more specific: - My package's spec file is tracked in dist-git or git + git-lsf, depending on a setting I'll either have one branch for all the Fedora & EPEL versions or one branch for each version. - Commits to the repository result in CI run (a default one, like rpmlint + additional custom tests). I can push -f all commits since the last tag, but nothing before that. Once I tag a commit, it is build "for real" (and tested) and automatically submitted as an update to bodhi. The changelog gets generated from the tag message and included into bodhi. On the other hand it must be possible to submit multiple packages as an update. I could imagine something like a `fedpkg update-multiple package1:$commit1 package2:$commit2 -m $message` that would tag the specified commits and push all builds into a single update to bodhi. - the-new-hotness will send pull requests once a package is updated upstream. The pull request gets built & tested as an ordinary commit would. As a packager I have the option to "merge + tag" (also being able to modify the tag), which automatically submits this as an update. This would tremendously simplify the update process for most of my packages. - If I would have a package that requires a lot of patches, then I can be granted the option to use source-git and keep my patches as commits on top of an upstream branch. This should imho require some form of approval though, as this can easily escalate into hundreds of patches. - Package updates cause a rebuild of all dependencies (+ a test run of each of these). Only a successful rebuild is allowed to be submitted to bodhi. - Allow the creation of package "namespaces" or "projects" (stolen from OBS' development projects): a packager or a group can create a namespace on the git forge, into which they can fork/link arbitrary packages from the distribution. The forked packages become a part of the buildroot of this namespace, all others are inherited from the distribution itself and are unaffected by changes in this namespace. This should allow packagers to run experiments which do not affect the distributions build root, but still be able to test the impact of their changes on a larger set of packages. Packagers should then be able to send their changes back via a mass-pull-request/mass-commit. - Extend the fedpkg CLI to support more actions on pagure, e.g. finding out who is the current package maintainer of Foo or forking the package Bar and sending a PR back. Hope all of this makes s
Re: packaging: upgrade a library to a header-only library
Miro Hrončok wrote:
> - cmake files usually go into %{_libdir} and such packages cannot be
> noarch as well
smart cmake noarch projects can use %{_datadir}/cmake instead
-- rex
___
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 Atomic Host Two Week Release Announcement: 29.20191001.0
On 10/2/19 5:25 PM, nore...@fedoraproject.org wrote: > > A new Fedora Atomic Host update is available via an OSTree update: > > Version: 29.20191001.0 > Commit(x86_64): > 15b8a10f8b587c2a037a592806dc04e9cdf6ab1c73c6e49fdaacab1b1174b9ab > Commit(aarch64): > 2b83282e976249b8e1910a7292379753b006851078e9bcea279ff3b6483ee602 > Commit(ppc64le): > 7ed4f0395e22000ffe372132c791a8dded291063d5c184e2470dde13c0eb3ba2 > > > We are releasing images from multiple architectures but please note > that x86_64 architecture is the only one that undergoes automated > testing at this time. > > Existing systems can be upgraded in place via e.g. `atomic host upgrade`. > > Corresponding image media for new installations can be downloaded from: > > https://getfedora.org/en/atomic/download/ > > Alternatively, image artifacts can be found at the following links: > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0.aarch64.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0.aarch64.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20191001.0.iso > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0.ppc64le.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0.ppc64le.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20191001.0.iso > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0.x86_64.qcow2 > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0.x86_64.raw.xz > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191001.0.x86_64.vagrant-libvirt.box > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191001.0.x86_64.vagrant-virtualbox.box > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20191001.0.iso > > Respective signed CHECKSUM files can be found here: > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0-aarch64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20191001.0-aarch64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0-ppc64le-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20191001.0-ppc64le-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0-x86_64-CHECKSUM > https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20191001.0-x86_64-CHECKSUM > > For direct download, the "latest" targets are always available here: > x86_64: > https://getfedora.org/atomic_qcow2_x86_64_latest > https://getfedora.org/atomic_raw_x86_64_latest > https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest > https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest > https://getfedora.org/atomic_dvd_ostree_x86_64_latest > > aarch64: > https://getfedora.org/atomic_qcow2_aarch64_latest > https://getfedora.org/atomic_raw_aarch64_latest > https://getfedora.org/atomic_dvd_ostree_aarch64_latest > > ppc64le: > https://getfedora.org/atomic_qcow2_ppc64le_latest > https://getfedora.org/atomic_raw_ppc64le_latest > https://getfedora.org/atomic_dvd_ostree_ppc64le_latest > > Filename fetching URLs are available here: > x86_64: > https://getfedora.org/atomic_qcow2_x86_64_latest_filename > https://getfedora.org/atomic_raw_x86_64_latest_filename > https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename > https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename > https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename > > aarch64: > https://getfedora.org/atomic_qcow2_aarch64_latest_filename > https://getfedora.org/atomic_raw_aarch64_latest_filename > https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename >
Fedora Atomic Host Two Week Release Announcement: 29.20191001.0
A new Fedora Atomic Host update is available via an OSTree update: Version: 29.20191001.0 Commit(x86_64): 15b8a10f8b587c2a037a592806dc04e9cdf6ab1c73c6e49fdaacab1b1174b9ab Commit(aarch64): 2b83282e976249b8e1910a7292379753b006851078e9bcea279ff3b6483ee602 Commit(ppc64le): 7ed4f0395e22000ffe372132c791a8dded291063d5c184e2470dde13c0eb3ba2 We are releasing images from multiple architectures but please note that x86_64 architecture is the only one that undergoes automated testing at this time. Existing systems can be upgraded in place via e.g. `atomic host upgrade`. Corresponding image media for new installations can be downloaded from: https://getfedora.org/en/atomic/download/ Alternatively, image artifacts can be found at the following links: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0.aarch64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0.aarch64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20191001.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0.ppc64le.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0.ppc64le.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20191001.0.iso https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0.x86_64.qcow2 https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0.x86_64.raw.xz https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191001.0.x86_64.vagrant-libvirt.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20191001.0.x86_64.vagrant-virtualbox.box https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20191001.0.iso Respective signed CHECKSUM files can be found here: https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20191001.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20191001.0-aarch64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20191001.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20191001.0-ppc64le-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20191001.0-x86_64-CHECKSUM https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20191001.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20191001.0-x86_64-CHECKSUM For direct download, the "latest" targets are always available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest https://getfedora.org/atomic_raw_x86_64_latest https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest https://getfedora.org/atomic_dvd_ostree_x86_64_latest aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest https://getfedora.org/atomic_raw_aarch64_latest https://getfedora.org/atomic_dvd_ostree_aarch64_latest ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest https://getfedora.org/atomic_raw_ppc64le_latest https://getfedora.org/atomic_dvd_ostree_ppc64le_latest Filename fetching URLs are available here: x86_64: https://getfedora.org/atomic_qcow2_x86_64_latest_filename https://getfedora.org/atomic_raw_x86_64_latest_filename https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename aarch64: https://getfedora.org/atomic_qcow2_aarch64_latest_filename https://getfedora.org/atomic_raw_aarch64_latest_filename https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename ppc64le: https://getfedora.org/atomic_qcow2_ppc64le_latest_filename https://getfedora.org/atomic_raw_ppc64le_latest_filename https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam
Re: Unretire nodejs-gaze
On Wed, Oct 2, 2019 at 9:32 AM Jared K. Smith wrote: > I blindly assumed it had been eight weeks already, so I requested a > re-review at RHBZ#1755147. Obviously I'll just close that review request > if we can get this unretired before the deadline. > It looks like this has been un-retired, so I'll go ahead and try to push an updated build to rawhide just as soon as the Koji outage is over. -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
Re: Defining the future of the packager workflow in Fedora
On Wed, Oct 2, 2019 at 4:06 PM Simo Sorce wrote: > > On Wed, 2019-10-02 at 15:57 -0400, Colin Walters wrote: > > > > On Wed, Oct 2, 2019, at 3:18 PM, Neal Gompa wrote: > > > On Wed, Oct 2, 2019 at 2:45 PM 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`. > > > > 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). > > > > > > 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 > > > > Yes, I mentioned Prow which does something similar. > > https://github.com/kubernetes/test-infra/tree/master/prow > > Which as I noted we use today in OpenShift and are moving to use in the > > CoreOS group as well. > > I do not know how it is working today, but when I was working on it it > was a real chore as PRs would regularly flake. Most of the time it was > openshift/kube's code fault, other times it wasn't and would cause a > lot of overhead for teams to babysit PRs that should have just merged. > Kubernetes' project infrastructure is probably a very bad example, as it's primarily geared to support the CNCF's crazy process rather than helping developers. > > > > I'm surprised you didn't realize these issues. You've examined Git > > > very deeply and you should be more than aware of how bad of idea it > > > would be to use a monorepo for package sources. We don't have separate > > > Git repos per package for no reason... > > > > https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow > > links to a number which do it today. You're right that there are > > tradeoffs; I think the best is probably something closer to what > > OpenEmbedded is doing with "layered" repos, not one gigantic dist-git > > repo. > > > > It certainly seems to me the current Fedora setup is basically just > > inertia from the first dist-cvs -> dist-git conversion; no one really > > in the intervening time has had the power/will to change the > > underlying layers, just add new layers on top. > > Both are true probably, there is inertia and the tradeoffs probably > were not worth the change so far. > Dist-CVS is effectively a monorepo, just as Mageia's Dist-SVN is. Those SCMs have the advantage of supporting subtree checkouts as a first-class operation, and don't do proper "clones" like Git and Mercurial do. That makes it *much* simpler to deal with. I think layered repos would not be significantly better than just having groups and subgroups to organize the package sources git repos. You'd get the same organizational benefits, anyway. -- 真実はいつも一つ！/ 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
Re: Defining the future of the packager workflow in Fedora
On Wed, 2019-10-02 at 15:57 -0400, Colin Walters wrote: > > On Wed, Oct 2, 2019, at 3:18 PM, Neal Gompa wrote: > > On Wed, Oct 2, 2019 at 2:45 PM 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`. > > > 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). > > > > 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 > > Yes, I mentioned Prow which does something similar. > https://github.com/kubernetes/test-infra/tree/master/prow > Which as I noted we use today in OpenShift and are moving to use in the > CoreOS group as well. I do not know how it is working today, but when I was working on it it was a real chore as PRs would regularly flake. Most of the time it was openshift/kube's code fault, other times it wasn't and would cause a lot of overhead for teams to babysit PRs that should have just merged. > > I'm surprised you didn't realize these issues. You've examined Git > > very deeply and you should be more than aware of how bad of idea it > > would be to use a monorepo for package sources. We don't have separate > > Git repos per package for no reason... > > https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow > links to a number which do it today. You're right that there are > tradeoffs; I think the best is probably something closer to what > OpenEmbedded is doing with "layered" repos, not one gigantic dist-git > repo. > > It certainly seems to me the current Fedora setup is basically just > inertia from the first dist-cvs -> dist-git conversion; no one really > in the intervening time has had the power/will to change the > underlying layers, just add new layers on top. Both are true probably, there is inertia and the tradeoffs probably were not worth the change so far. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
New updates straight to obsolete after Epoch bump?!?
I messed up and build PySide2 5.13.x before I relealized that I should have built the latest 5.12.x as the MAJOR.MINOR has to match the version of Qt and we have not updated to 5.13 yet. So I bumped the Epoch in the spec file and built 5.12.5 but when I submitted updates for f31 and 30 they pretty much went straight to obsolete. The auto-update for rawhide worked fine. f31: https://bodhi.fedoraproject.org/updates/FEDORA-2019-51f88396ca f30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-005d5f20fb What's going on here? 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
Re: Defining the future of the packager workflow in Fedora
On Wed, Oct 2, 2019, at 3:18 PM, Neal Gompa wrote: > On Wed, Oct 2, 2019 at 2:45 PM 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`. > > 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). > > 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 Yes, I mentioned Prow which does something similar. https://github.com/kubernetes/test-infra/tree/master/prow Which as I noted we use today in OpenShift and are moving to use in the CoreOS group as well. > I'm surprised you didn't realize these issues. You've examined Git > very deeply and you should be more than aware of how bad of idea it > would be to use a monorepo for package sources. We don't have separate > Git repos per package for no reason... https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow links to a number which do it today. You're right that there are tradeoffs; I think the best is probably something closer to what OpenEmbedded is doing with "layered" repos, not one gigantic dist-git repo. It certainly seems to me the current Fedora setup is basically just inertia from the first dist-cvs -> dist-git conversion; no one really in the intervening time has had the power/will to change the underlying layers, just add new layers on top. ___ 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
Ohio LinuxFest 2019
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
Re: Defining the future of the packager workflow in Fedora
On Wed, Oct 2, 2019 at 3:18 PM Neal Gompa wrote: > > On Wed, Oct 2, 2019 at 2:45 PM 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`. > > 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). > > 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 > > > I'd like to require review, but it does seem like a prerequisite is moving > > away from the one-repo-per-package model. > > No it isn't. A pre-requisite would be that we'd require maintainer > teams, and have to make those first-class in Fedora (rather than > barely third-class as they are now). Besides, I've worked in > distributions where you have monorepo package source control, and it's > arguably worse. Rolling through the revisions is difficult, dealing > with searching through the tree is hard, and features like git blame > basically don't work (they time out more often than they return > results). Meaning that we'd need groups and subgroups that have ACL > inheritance for projects, among other things. > Erk, this is not worded in the right order... I mean this instead: No it isn't. A pre-requisite would be that we'd require maintainer teams, and have to make those first-class in Fedora (rather than barely third-class as they are now). Meaning that we'd need groups and subgroups that have ACL inheritance for projects, among other things. Besides, I've worked in distributions where you have monorepo package source control, and it's arguably worse. Rolling through the revisions is difficult, dealing with searching through the tree is hard, and features like git blame basically don't work (they time out more often than they return results). > I'm surprised you didn't realize these issues. You've examined Git > very deeply and you should be more than aware of how bad of idea it > would be to use a monorepo for package sources. We don't have separate > Git repos per package for no reason... > > > -- > 真実はいつも一つ！/ Always, there's only one truth! -- 真実はいつも一つ！/ 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
Re: Defining the future of the packager workflow in Fedora
On Wed, Oct 2, 2019 at 2:45 PM 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`. > 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). 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 > I'd like to require review, but it does seem like a prerequisite is moving > away from the one-repo-per-package model. No it isn't. A pre-requisite would be that we'd require maintainer teams, and have to make those first-class in Fedora (rather than barely third-class as they are now). Besides, I've worked in distributions where you have monorepo package source control, and it's arguably worse. Rolling through the revisions is difficult, dealing with searching through the tree is hard, and features like git blame basically don't work (they time out more often than they return results). Meaning that we'd need groups and subgroups that have ACL inheritance for projects, among other things. I'm surprised you didn't realize these issues. You've examined Git very deeply and you should be more than aware of how bad of idea it would be to use a monorepo for package sources. We don't have separate Git repos per package for no reason... -- 真実はいつも一つ！/ 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
Re: Defining the future of the packager workflow in Fedora
"Colin Walters" writes: > 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`. With about six more emails about it, sure. And another piece of infrastructure that has to be up and bug-free. Even the gating and bodhi emails today are rather a lot: I don't want to be notified if everything worked correctly. > 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. It also requires people to do the review, which many packages don't have. For many teams, this would more than double the time spent on packaging. That's not tenable. Thanks, --Robbie 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: Update pushed to F31 updates-testing not happening ?
Hi, On 02-10-2019 16:59, Kevin Fenzi wrote: On Wed, Oct 02, 2019 at 01:55:23PM +0200, Clement Verna wrote: On Wed, 2 Oct 2019 at 12:49, Hans de Goede wrote: Hi All, We currently have 61 updates pending for being pushed to F31 updates-testing and no push seems to have happened for aprox. 48 hours or so ? This is https://github.com/fedora-infra/bodhi/issues/3471 biting us. I have removed the updates without builds from the push so that we can resume it. The bug is not easy to reproduce, but we could just eject from the updates that don't have a build from the push to prevent the failure. I've resumed the pushes... Thank you both for taking care of this. Regards, Hans ___ 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: Intent to unretire qm-dsp
Il giorno mer, 02/10/2019 alle 14.32 +0200, Guido Aulisi ha scritto: > Hi, > I'm going to unretire qm-dsp in all current Fedora supported > releases, > because it's a dependency for ardour5. > > I will file a review request ASAP, I have already made a scratch > build > in rawhide: > https://koji.fedoraproject.org/koji/taskinfo?taskID=38004441 > > FAS account: tartina I filed a review request for this https://bugzilla.redhat.com/show_bug.cgi?id=1757778 Ciao Guido ___ 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 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`. 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
Re: Defining the future of the packager workflow in Fedora
On Wed, Oct 2, 2019 at 8:17 PM Ben Rosser wrote: > > On Wed, Oct 2, 2019 at 1:59 PM Pierre-Yves Chibon wrote: > > There are regularly people complaining on this very list about how hard > > packaging has become. So here is a thread trying to see if you can come up > > with > > a long term, ideal, vision of what the packager workflow should be so we can > > work towards it. > > I'm such a person. I tried to put together an Objective on this topic > back in January before realizing I didn't have enough time to drive it > forwards due to real life commitments. > > I may not have said it explicitly in my other replies on the thread, > but I _am_ glad to see people thinking seriously about ways to improve > the packager experience. So I appreciate your proposal, even if I > disagree with the proposed pull request workflow. > > That being said... > > > 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: Whoops, I meant to write here: "things I was proposing to help fix, before I realized that I didn't have the time" > > 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? > > 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. > > Ben Rosser ___ 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, 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. [0] - http://www.extremeprogramming.org/rules/integrateoften.html > > > -- > 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 > ___ 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 1:59 PM Pierre-Yves Chibon wrote: > There are regularly people complaining on this very list about how hard > packaging has become. So here is a thread trying to see if you can come up > with > a long term, ideal, vision of what the packager workflow should be so we can > work towards it. I'm such a person. I tried to put together an Objective on this topic back in January before realizing I didn't have enough time to drive it forwards due to real life commitments. I may not have said it explicitly in my other replies on the thread, but I _am_ glad to see people thinking seriously about ways to improve the packager experience. So I appreciate your proposal, even if I disagree with the proposed pull request workflow. That being said... > 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: 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? 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. Ben Rosser ___ 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 Wed, 2 Oct 2019 at 12:43, Richard W.M. Jones wrote: > > On Sat, Sep 28, 2019 at 04:49:08PM -0700, John M. Harris Jr wrote: > > Perhaps the same reason that many people still run i686 based hardware, and > > will be unable to use Fedora after the release of F31: Why fix what isn't > > broken? > > But the question is: Are they running qemu on this hardware? The last > i686 machine I had that could run qemu guests - very slowly by modern > standards - was manufactured in 2006, and I just last month got rid of it. > > (As an aside Fedora/i686 has been effectively dead for quite a long > time, so I'm pretty sure no one is running a supported Fedora on i686. > They may be running a long out of support Fedora though. I had to put > Debian on my i686 machine towards the end.) 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. -- 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: Fwd: bodhi submitted ntl-11.3.4-1.fc32 to stable
On Wed, Oct 02, 2019 at 10:13:43AM -0600, Jerry James wrote: > I just received the email below. I built ntl-11.3.4-1.fc32 on > September 24. Later that day, upstream released version 11.4.0, so I > built ntl-11.4.0-1.fc32 the next day, September 25. Why has the > previous build suddenly come back from the dead? Having it go stable > now is going to break all of the ntl-using packages that I built > against 11.4.0 last week. > > Can somebody please do whatever is necessary to have the 11.4.0 build > be the one that is current in Rawhide? Thank you. 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. 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: Defining the future of the packager workflow in Fedora
On Wed, Oct 2, 2019 at 7: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. And there _are_ real tracking and review benefits to > having everything go through that workflow. 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. > Do you have an alternative proposal? As long as PRs are opt-in, for example, if you explicitly *want* to trigger some tests or have somebody review your changes, then I'm all for it. The Stewardship SIG is using that exact workflow right now. But forcing people to open and triage Pull Requests for every single packaging change is *crazy* and will probably make it impossible for me to continue maintaining the (pretty big) number of packages I own. Fabio > > -- > 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 ___ 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 [02/10/2019 13:33] : > >And there _are_ real tracking and review benefits to > having everything go through that workflow. > > Do you have an alternative proposal? I'm fine with the workflow we have now. Small and drive-by contributions can by contributed via pull requests while core contributers (can) commit directly to master if they so wish. 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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)
On Wednesday, October 2, 2019 9:42:57 AM MST Richard W.M. Jones wrote: > On Sat, Sep 28, 2019 at 04:49:08PM -0700, John M. Harris Jr wrote: > > > Perhaps the same reason that many people still run i686 based hardware, > > and will be unable to use Fedora after the release of F31: Why fix what > > isn't broken? > > > But the question is: Are they running qemu on this hardware? The last > i686 machine I had that could run qemu guests - very slowly by modern > standards - was manufactured in 2006, and I just last month got rid of it. > > (As an aside Fedora/i686 has been effectively dead for quite a long > time, so I'm pretty sure no one is running a supported Fedora on i686. > They may be running a long out of support Fedora though. I had to put > Debian on my i686 machine towards the end.) Fedora on i686 is not dead, and will not be until the release of F31, and the end of F30. There are users running Fedora on i686, such as myself. The arbitrary decision to simply stop supporting i686 has not yet killed off our i686 users. -- John M. Harris, Jr. Splentity ___ 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 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? -- 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: Impact of dropping QEMU emulation on 32-bit hosts ? (~Fedora 33)
On Sat, Sep 28, 2019 at 04:49:08PM -0700, John M. Harris Jr wrote: > Perhaps the same reason that many people still run i686 based hardware, and > will be unable to use Fedora after the release of F31: Why fix what isn't > broken? But the question is: Are they running qemu on this hardware? The last i686 machine I had that could run qemu guests - very slowly by modern standards - was manufactured in 2006, and I just last month got rid of it. (As an aside Fedora/i686 has been effectively dead for quite a long time, so I'm pretty sure no one is running a supported Fedora on i686. They may be running a long out of support Fedora though. I had to put Debian on my i686 machine towards the end.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote: > ○ Every changes to dist-git is done via pull-requests Erm, no thank you. Pull requests are a terrible workflow. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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
Vagrant 2.2 / Fedora 30+ issues anyone?
Hello, jstanek pinged me today with some weird errors :) so I got tempted to ask: Is anyone else experiencing some Vagrant-related issues? Most probable cause: - there was a Change, in which `qemu://session` (user session) is used by default. That means root privilleges are not required anymore for vagrant+libvirt But: - some network settings are currently limited (f.e. IP change) - the location of the VM images, even the base one, was moved to home directory (`~/.local/share/libvirt/images/` instead of `/var/lib/libvirt/images`) - flipping the option back to `qemu://system` disrupts halted machines (no images-moving magic is there) If you wan't just the IP of the machine, you can simply `vagrant ssh-config`. If you really need to use some custom networking setup (or need to access your existing box), you can change the libvirt provider's option `qemu_use_session`. - To change it for one guest, you need to add to your Vagrantfile (where it fits): ``` config.vm.provider :libvirt do |libvirt| libvirt.qemu_use_session = false end ``` - To change it for all user's instances, you can add the setting above to `~/.vagrant.d/Vagrantfile` (or create the file). Then you can set it back to `true` on per-guest basis as needed. Note: - prior to flipping the setting, `destroy` the instance(s) it affects (`vagrant global-status`) - to remove base image from libvirt storage, use always: `sudo virsh vol-list --pool default` to list images and `sudo virsh vol-delete --pool default fedora-VAGRANTSLASH-29-cloud-base_vagrant_box_image_29.20181024.1.img` or similar to remove them (without `sudo` for `qemu://session`). You can read more on the change here: https://fedoraproject.org/wiki/Changes/Vagrant_2.2_with_QEMU_Session If you encounter any issues, please ping me (pvalena on #fedora-devel) or create a bug (http://bugzilla.redhat.com/). Cheers, Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fwd: bodhi submitted ntl-11.3.4-1.fc32 to stable
I just received the email below. I built ntl-11.3.4-1.fc32 on September 24. Later that day, upstream released version 11.4.0, so I built ntl-11.4.0-1.fc32 the next day, September 25. Why has the previous build suddenly come back from the dead? Having it go stable now is going to break all of the ntl-using packages that I built against 11.4.0 last week. Can somebody please do whatever is necessary to have the 11.4.0 build be the one that is current in Rawhide? Thank you. -- Forwarded message - From: Date: Wed, Oct 2, 2019 at 10:03 AM Subject: bodhi submitted ntl-11.3.4-1.fc32 to stable To: Notification time stamped 2019-10-02 15:54:12 UTC bodhi submitted ntl-11.3.4-1.fc32 to stable https://bodhi.fedoraproject.org/updates/FEDORA-2019-2ce9d4c6a6 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications/jjames.id.fedoraproject.org/email/24784 -- 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
Re: Update pushed to F31 updates-testing not happening ?
On Wed, Oct 02, 2019 at 01:55:23PM +0200, Clement Verna wrote: > On Wed, 2 Oct 2019 at 12:49, Hans de Goede wrote: > > > Hi All, > > > > We currently have 61 updates pending for being pushed to > > F31 updates-testing and no push seems to have happened for > > aprox. 48 hours or so ? > > > > This is https://github.com/fedora-infra/bodhi/issues/3471 biting us. I have > removed the updates without builds from the push so that we can resume it. > > The bug is not easy to reproduce, but we could just eject from the updates > that don't have a build from the push to prevent the failure. I've resumed the pushes... 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: 2020 Datacenter Move: Request for comments
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 > 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
Re: CGAL soname "bump" in rawhide
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 ___ 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: Unretire nodejs-gaze
On Tue, Oct 1, 2019 at 10:46 AM Ben Rosser wrote: > About a month ago I requested to unretire some nodejs packages in > order to get the "grunt" stack working again. At least one more > package still needs to be unretired to fix the > nodejs-grunt-contrib-watch package, nodejs-gaze: > > https://src.fedoraproject.org/rpms/nodejs-gaze > > This was retired just under eight weeks ago for being FTBFS-- on > 2019-08-08. Hopefully it still is within the deadline for not > requiring rereview (that's eight weeks on Thursday)! > > I'll submit a releng ticket, and am notifying devel as requested by the > policy. > I blindly assumed it had been eight weeks already, so I requested a re-review at RHBZ#1755147. Obviously I'll just close that review request if we can get this unretired before the deadline. -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
Re: CGAL soname "bump" in rawhide
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 -- 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 Wed, Oct 2, 2019 at 8:42 AM Stephen John Smoogen wrote: > > On Wed, 2 Oct 2019 at 03:39, Felix Schwarz wrote: > > > > > > Am 01.10.19 um 16:55 schrieb Stephen John Smoogen: > > > Then there are problems with budgets and figuring out what exactly it > > > would cost. We fall outside of many of the 'caveats' that would allow > > > us to get free. > > > > IIRC at the time when Fedora evaluated its options the open source version > > of > > Gitlab was more limited than today. AFAIK Debian + FreeDesktop developers > > worked with Gitlab Inc. and finally succeeded in getting necessary features > > included in the open source version. > > > > If the evaluation was done today and there were no Pagure I suspect Fedora > > would use gitlab as well. > > > > (I'm also wondering if Fedora writes too much custom infrastructure when > > there > > are "open core" offerings which might provide more features - e.g. Gitlab > > instead of Pagure, sentry instead of abrt. But I'm aware of limited > > ressources > > and I trust my fellow Fedorians with their judgement.) > > > > One of the goals many early Fedora participants had was that Fedora > was to be an incubator for open source software which isn't available > as FLOSS elsewhere. The issue though is that software does not spring > up instantly from the head of Zeus fully formed. It takes years and a > lot of effort. Other things can overtake what you are working on and > just be so much larger and bigger than what is now. It can also be > that what communities want changes faster than it takes for the > software to be written. > For those that might have forgotten, Ansible is a fantastic success story from those principles (It started as a fedorahosted project called func). It took a while for it to take off, but it did. -- 真実はいつも一つ！/ 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
Re: Defining the future of the packager workflow in Fedora
On Wed, 2 Oct 2019 at 03:39, Felix Schwarz wrote: > > > Am 01.10.19 um 16:55 schrieb Stephen John Smoogen: > > Then there are problems with budgets and figuring out what exactly it > > would cost. We fall outside of many of the 'caveats' that would allow > > us to get free. > > IIRC at the time when Fedora evaluated its options the open source version of > Gitlab was more limited than today. AFAIK Debian + FreeDesktop developers > worked with Gitlab Inc. and finally succeeded in getting necessary features > included in the open source version. > > If the evaluation was done today and there were no Pagure I suspect Fedora > would use gitlab as well. > > (I'm also wondering if Fedora writes too much custom infrastructure when there > are "open core" offerings which might provide more features - e.g. Gitlab > instead of Pagure, sentry instead of abrt. But I'm aware of limited ressources > and I trust my fellow Fedorians with their judgement.) > One of the goals many early Fedora participants had was that Fedora was to be an incubator for open source software which isn't available as FLOSS elsewhere. The issue though is that software does not spring up instantly from the head of Zeus fully formed. It takes years and a lot of effort. Other things can overtake what you are working on and just be so much larger and bigger than what is now. It can also be that what communities want changes faster than it takes for the software to be written. > Felix -- 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 Wed, Oct 02, 2019 at 03:29:23AM +0200, Pierre-Yves Chibon wrote: > On Thu, Sep 26, 2019 at 11:30:28AM -0700, Troy Dawson wrote: > > On Thu, Sep 26, 2019 at 10:48 AM Robbie Harwood wrote: > > > > > > Pierre-Yves Chibon writes: > > > > > > > Here is what the vision we came to and that we would like to discuss: > > > > > > > > ○ Every changes to dist-git is done via pull-requests > > > > ○ Pull-requests are automatically tested > > > > ○ Every commit to dist-git (ie: PR merged) is automatically built in > > > > koji > > > > ○ Every build in koji results automatically in an update in bodhi > > > > ○ Every update in bodhi is automatically tested > > > > ○ If the tests pass, the update is automatically pushed to the > > > > repository > > > > > > I have a *lot* of objections to this workflow, but maybe it'd be better > > > to take a step back. > > > > > > Instead of trying to create a new workflow, why are you not starting > > > with defining what we have now? And if there are problems with it that > > > need to be addressed, what are they and why do they motivate these > > > changes to you? > > > > > > > I'd like to second this question. > > What are the problems with our current workflows? > > At the beginning of this message you said there were several packaging > > initiatives being worked on, but for those of us that didn't go to > > Flock, we don't know what those are. > > There was a talk from Neil that has been linked to elsewhere in this thread Oups, the talk was from Neal and Igor. Sorry for the typo there. Pierre ___ 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 unretire qm-dsp
Hi, I'm going to unretire qm-dsp in all current Fedora supported releases, because it's a dependency for ardour5. I will file a review request ASAP, I have already made a scratch build in rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=38004441 FAS account: tartina Ciao ___ 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: Rawhide rebuild of Python packages with old bytecode version
On 02. 10. 19 12:30, Fabio Valentini wrote: With hindsight, I guess it was also a wise decision to postpone python 3.8 to fedora 32?:) It was. -- 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 Thu, Sep 26, 2019 at 03:33:11PM +0100, Daniel P. Berrangé wrote: > On Thu, Sep 26, 2019 at 04:24:29PM +0200, Pierre-Yves Chibon wrote: > > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote: > > > On Thu, Sep 26, 2019 at 11:36:10AM +0200, Pierre-Yves Chibon wrote: > > > > Good Morning Everyone, > > > > > > > > At Flock, a few of us met to discuss a future vision of the packager > > > > workflow. > > > > This discussion was triggered by the realization that a number of > > > > initiatives > > > > are happening around packaging in Fedora but there is no real shared > > > > vision on > > > > what we want the packager UX/workflow to be. > > > > The lack of vision on the packager workflow means we could deploy > > > > something > > > > today, thinking it is the improvement over the current workflow but > > > > would > > > > prevent us from (or make it harder to) doing other changes afterwords > > > > that would > > > > be even more beneficial.. > > > > > > > > So once that concern was raised, we took some time during the Fedora > > > > Infrastructure hackfest to gather the people interested around a white > > > > board and > > > > brainstorm on what a future packager workflow could look like. > > > > > > > > We tried not to link this process to any tool in particular as well as > > > > focus on > > > > the what and why rather than any how. > > > > > > > > Here is what the vision we came to and that we would like to discuss: > > > > > > > > ○ Every changes to dist-git is done via pull-requests > > > > ○ Pull-requests are automatically tested > > > > ○ Every commit to dist-git (ie: PR merged) is automatically built in > > > > koji > > > > ○ Every build in koji results automatically in an update in bodhi > > > > ○ Every update in bodhi is automatically tested > > > > ○ If the tests pass, the update is automatically pushed to the > > > > repository > > > > > > For packages I maintain, my preference is to touch dist-git as little > > > as possible. Ideally I would never touch dist-git at all & rather wish > > > it didn't exist at all in its current form of spec+patchfiles. > > > > > > Instead I prefer a clone of the master upstream git repo and maintain a > > > branch with patches cherry-picked into it. This is used to auto-generate > > > patches for the Fedora RPM, at the same time updating the patch file list > > > in the RPM spec. The only manual step is adding the changelog entry & > > > bumping release number. > > > > > > The ideas above around associating CI with pull requests make a lot of > > > conceptual sense & align with modern github/gitlab software development > > > best practices followed by non-distro software upstreams. Automatically > > > triggering builds from merged PRs similarly makes sense, especially > > > if that can automate bumping spec release number & adding a changelog > > > entry based on the pull request subject. > > > > > > > > > Obviously I can still use my upstream git repo branch and change the > > > scripts to generate a pull request to dist-git instead. The downside > > > is if the PR fails, I now how to rebase my real git repo & re-submit > > > and new PR. > > > > > > So if we're talking "ideal" long term vision though, I'd rather eliminate > > > the dist-git repo intermediate step as IMHO it adds no value, only > > > complexity > > > for the sake of historical compat with the way Red Hat distros has worked > > > dating back years. Its time to say goodbye to this historical way as the > > > world has moved on since this spec+patches approach was invented in the > > > days of CVS source control. > > > > > > Allow packagers to have a clone of the upstraem git repo, and use the > > > pull-requests and run Fedora CI testing against the Fedora branch of > > > the upstream repo instead of against dist-git. > > > > > > In this way, maintaining packages in Fedora would be functionally > > > identical > > > to how an upstream project maintains their own stable branches. The only > > > Fedora difference would be that the branch would need to include the RPM > > > spec file in some well defined place. > > > > I like this. > > It means that the build-system would have to generate the tarball of the > > source > > and put it into dist-git at srpm-build time (I believe we still want to > > store a > > copy of the sources used for a build). > > It doesn't have to generate a tarball. There's still the option of using the > lookaside cache to acquire the tarball as today. I don't mind the lookaside > cache since its rarely touched, doesn't cause inconvenience in the same way > patches in dist-git do. I had in mind generating the tarball as a way to make sure the sources don't disappear and we are able to reproduce the builds > > - Do you have in mind that the copy/fork of upstream would be in our > > dist-git or > > in other places on the internet? If the later, how would you recommend > > contributors to find it? > > Ideally I think Fedora
Re: Defining the future of the packager workflow in Fedora
On Thu, Sep 26, 2019 at 11:23:21AM -0500, Michael Cronenworth wrote: > On 9/26/19 10:28 AM, Pierre-Yves Chibon wrote: > > Would this change if the PR was automatically tested for you without you > > having > > to do anything? > > I always run local mock builds prior to commits. Maybe not everyone likes to > do this and wants Koji to do it for them, but I prefer local mock builds. > Having it done for me is redundant. I don't think I would stop doing local > mock builds. There are more tests we can do than simply: does it build? There is also the: Does it install? Does it upgrade? Does it uninstall? Does the machine still boot after installing it? Does it adhere to our packaging guidelines? So, all of the work the CI SIG folks are trying to set up these days. Pierre ___ 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, Sep 26, 2019 at 11:24:28AM -0500, Michael Cronenworth wrote: > On 9/26/19 9:07 AM, Pierre-Yves Chibon wrote: > > What is so different in Fedora that we cannot move to this model? > > Is it a tooling issue? > > Is it something else? > > As others have already stated that may work in projects with tens, hundreds, > or thousands of contributors, but most of Fedora packages are owned and > maintained by a single person. I'm not going to wait around for anyone to > review my commit or comment on it. No one tests or comments on most of my > Bodhi updates. > > The same development model for upstream projects is not 1:1 to Fedora > packaging. Stop trying to force it. It may just be a wording issue, but I would really appreciate if you would not attribute me thoughts I've never had. I think I have been clear that this thread is about proposing something, everything in it is up for debate and discussion. If every discussion that is started is treated as something that is "forced" then it's questioning (at least to me). > > > I don't want a build for every commit. Sometimes I cache changes for > > > future > > > releases. A commit does*not* always equal an update. > > There are a few ways to approach this: > > - don't bump the release in the spec file, the build will be triggered and > > will > >just never complete > > It should be an opt-in feature. Who called for this feature? I don't > remember seeing anyone ask for it. If you want a name then I'll put mine, this is something that I've found would be useful in more than one occasion. Making it opt-in is definitely possible but the rest of your comment makes me wonder if it's even wanted. > > - have a magic keyword in the commit message that prevents the build from > >happening at all > No, thanks. Requires way too much human interaction (memory). > > - is an extra build in rawhide such a big deal? > It may fail to build because of a dependency on other features not yet in > place... so it *must* be opt-in. > > - gate at bodhi level builds that have the same rpm payload as the previous > >build shipped > >--> this is what OpenSUSE does btw, when you build an update, they > > rebuild the > >entire dependency tree but will filter out the RPM whose payload haven't > >changed from the update that is pushed to the users. > > If you want to spend time doing this go ahead, but it feels like a waste of > resources and talent. It's also what would provide one of the greatest return on investment. It should basically solve all the broken-deps reports, the un-announced soname bumps and so on. > > > This proposed workflow model doesn't help me. It hurts. It makes me think > > > of > > > dropping my roles from Fedora. > > Seeing you leave is really not the idea and would be the opposite result. > > > > The way I thought of this was: > > - is it easier to ask everyone for what their ideal workflow would be? > > or > > - present a workflow (which is hopefully not entirely insane) and encourage > > the > >community to patch it so we end up with something that is consensual > > between > >all of us? > > > > I went with the later approach. Using the brainstorming session at flock, > > I'm > > proposing*a* workflow, it's not perfect, it may not not ideal for everyone > > but > > it's a start and we can patch it as much as we want. > > We may end up with something entirely different from what I'm proposing and > > that's fine, but at least we'll have an agreed upon idea of where we want > > to go > > (ie: a long term vision) > > > > > > Does that make sense? > > I am sorry if the wording I've used didn't make this clear in my initial > > email > > :( > > If you want to have fedpkg do all of this for you buy default, sure, fine. > It should /also/ have a configuration able to be defined to disable all of > this automatic stuff. The reverse could also happen. Bake all this > functionality in and make it opt-in. > > Again, who was asking for all of this? Why do we need to have someone asking to propose something? There are regularly people complaining on this very list about how hard packaging has become. So here is a thread trying to see if you can come up with a long term, ideal, vision of what the packager workflow should be so we can work towards it. 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? > The only interesting part is the automated testing and automated push to > stable, but that would take years to implement distro wide. The CI SIG folks are actively working towards this. It is a slow process but hopefully we are improving things there. Pierre ___ devel mailing list -- devel@lists.fedoraproject.org To
Re: Finding out ownership of packages & branches
On Mon, Sep 30, 2019 at 09:27:29PM +0200, Tim Jackson wrote: > On 30/09/2019 21:02, Stephen John Smoogen wrote: > > On Mon, 30 Sep 2019 at 14:54, Tim Jackson wrote: > > > > Where is the canonical source these days for establishing package > > > (co-)ownership, in particular in relation to individual branches? > > > branch ownership died 2-3 years ago. a replacement was asked to be > > looked at but has been side-lined for so long.. I think we can call it > > dead. > > OK, thanks for the quick reply. I guess it was something to do with this? > https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching > > So, these days, if - for example - I take and build a package in EPEL, > intending to maintain it only there (potentially only in one branch there), > there's no possible way in the future for anyone to (programmatically) > identify me as the "EPEL-x branch owner"?. There is work planned to be able to show in the UI of src.fedoraproject.org the point of contact for the Fedora and the Fedora EPEL components as they would appear in bugzilla. This is not a per-branch identification but it would be consistent with the level of granularity we have with bugzilla. > Similarly, bug reports on all branches go to all maintainers? (It seems > co-maintainers possibly get cc'd). (If it's still valid, this perhaps is a > manual way to change: > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_become_the_default_assignee_of_a_branch_in_bugzilla.3F > ) That should be correct, though currently the script that syncs from dist-git to bugzilla is running into a number of issues so it may not entirely work as intended. It's in our backlog. > Is the current state documented anywhere? (is it roughly this? > https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb ) > > Is the (known) lack of branch ownership documented in a bug anywhere? I > didn't find anything in the FESco issue list, open or closed. It was a conscious decision and in that sense is not a bug. > I guess we lost the metadata (e.g. branch ownership) that already existed > along the way? I believe we still have a dump of the pkgdb database from when we decommissioned it but at this point (2 years later now?) I doubt we want to get back to it. > > https://src.fedoraproject.org/rpms/nagios > > click on members > > the people who are listed there are the comaintainers though I expect > > several of them have completely forgotten or know it anymore :). > > Hmm, OK, "members" is perhaps not the term I would have chosen, but I guess > it answers the question. Are all co-maintainers, or are "admins" > co-maintainers and "committers" other interested parties who've been granted > commit access? Committers have commit access Admins have commit access and can administer the settings of the project. Both of them are co-maintainer since they can commit. Hoping this helps, Pierre ___ 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, Sep 26, 2019 at 11:30:28AM -0700, Troy Dawson wrote: > On Thu, Sep 26, 2019 at 10:48 AM Robbie Harwood wrote: > > > > Pierre-Yves Chibon writes: > > > > > Here is what the vision we came to and that we would like to discuss: > > > > > > ○ Every changes to dist-git is done via pull-requests > > > ○ Pull-requests are automatically tested > > > ○ Every commit to dist-git (ie: PR merged) is automatically built in koji > > > ○ Every build in koji results automatically in an update in bodhi > > > ○ Every update in bodhi is automatically tested > > > ○ If the tests pass, the update is automatically pushed to the repository > > > > I have a *lot* of objections to this workflow, but maybe it'd be better > > to take a step back. > > > > Instead of trying to create a new workflow, why are you not starting > > with defining what we have now? And if there are problems with it that > > need to be addressed, what are they and why do they motivate these > > changes to you? > > > > I'd like to second this question. > What are the problems with our current workflows? > At the beginning of this message you said there were several packaging > initiatives being worked on, but for those of us that didn't go to > Flock, we don't know what those are. There was a talk from Neil that has been linked to elsewhere in this thread which is an example of ideas impacting the packager workflow. There is the CI work which is impacting the packager workflow. These two are the ones that I come up from the top of my head but I'm sure there are more. > Basically, we (those not in the room with you) are starting here on > earth, while you are talking about how to properly breath while on the > moon. There is alot of disconnect between where we are and what you > are talking about. Sorry if that's the feeling I'm giving, it's really not what I was trying to convey. What I wanted to do is to have a discussion to discuss what we would like the packaging experience to be in Fedora. I thought that having a strawman proposal of what such vision could be would be a good starting point as it would give us something to discuss, change and adjust so we can come up with some sort of consensus ideal packaging workflow in Fedora. This way when we make changes to the packager workflow we have something to measure the impact of the changes toward the long term objective (ie: is this change a step forward the ideal packager workflow or something that is a step back and therefore will need to be adjusted for later?). Does that make sense? Pierre ___ 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: Update pushed to F31 updates-testing not happening ?
On Wed, 2 Oct 2019 at 12:49, Hans de Goede wrote: > Hi All, > > We currently have 61 updates pending for being pushed to > F31 updates-testing and no push seems to have happened for > aprox. 48 hours or so ? > This is https://github.com/fedora-infra/bodhi/issues/3471 biting us. I have removed the updates without builds from the push so that we can resume it. The bug is not easy to reproduce, but we could just eject from the updates that don't have a build from the push to prevent the failure. > Regards, > > Hans > ___ > 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, 2019-10-02 at 09:39 +0200, Felix Schwarz wrote: > Am 01.10.19 um 16:55 schrieb Stephen John Smoogen: > > Then there are problems with budgets and figuring out what exactly it > > would cost. We fall outside of many of the 'caveats' that would allow > > us to get free. > > IIRC at the time when Fedora evaluated its options the open source version of > Gitlab was more limited than today. AFAIK Debian + FreeDesktop developers > worked with Gitlab Inc. and finally succeeded in getting necessary features > included in the open source version. > > If the evaluation was done today and there were no Pagure I suspect Fedora > would use gitlab as well. > > (I'm also wondering if Fedora writes too much custom infrastructure when > there > are "open core" offerings which might provide more features - e.g. Gitlab > instead of Pagure, sentry instead of abrt. But I'm aware of limited > ressources > and I trust my fellow Fedorians with their judgement.) Personally I still think it's not a very good idea to depend on any open-core infrastructure software, due to the possibility of conflict of interrest in the future. Eq. the company behind the software will not accept your patches as it clashes with their business model & proprietary code additions they sell to their customers. Then you will have to maintain those patches pretty much indefinitely. Might as well use a fully open source solution to avoid such future pitfalls. > > Felix > ___ > 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
Update pushed to F31 updates-testing not happening ?
Hi All, We currently have 61 updates pending for being pushed to F31 updates-testing and no push seems to have happened for aprox. 48 hours or so ? Regards, Hans ___ 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: Rawhide rebuild of Python packages with old bytecode version
On Wed, Oct 2, 2019 at 9:47 AM Miro Hrončok wrote: > > Hello, > Python packages built with Python < 3.8.0b4 have invalid bytecode version, > because the version was updated in 3.8.0b4. > > To see why this is a problem, follow the bugreport: > > https://bugzilla.redhat.com/show_bug.cgi?id=1748018 > > We were waiting for 3.8.0rc1 to see if the version is not updated once more. > It was not. > > After rc1 hits the f32 buildroot we will mass bump and rebuild all Python > packages that still have the old bytecode. Thank you for dealing with this. With hindsight, I guess it was also a wise decision to postpone python 3.8 to fedora 32? :) Fabio > The list of packages based on data from Monday (to be updated): > > 2ping > 5minute > APLpy > ATpy > Cython > GitPython > Mayavi > NLopt > OpenIPMI > OpenLP > ProDy > PyDrive > PyGreSQL > PyMca > PyQt4 > PySolFC > PyX > RBTools > SoapySDR > ViTables > WALinuxAgent > abrt > abrt-server-info-page > adapt > airnef > alot > ampy > ansible-bender > ansible-lint > ansible-review > antimony > appliance-tools > apx > arandr > artifacts > asciidoc > asciinema > assimp > astrometry > asv > atomic-reactor > aubio > audit > authselect > autoarchive > autojump > autokey > avogadro2-libs > awake > babeltrace > bandit > barman > battray > bcc > beets > binwalk > blivet-gui > blueman > bodhi > boom-boot > boost > borgmatic > botan > botan2 > bpython > brotli > btest > btrfs-sxbackup > buildbot > bumpversion > cairo-dock-plug-ins > calamares > cantoolz > capstone > caribou > ccsm > cheat > cinch > classification-banner > cloud-init > clufter > clustershell > codespell > colin > commissaire-client > compose-utils > concordance > congruity > conu > copr-cli > copr-keygen > copr-messaging > copr-rpmbuild > copydeps > cranc > csmock > csound > csvdiff > cura > cura-lulzbot > custodia > cxxtest > d-feet > datanommer-commands > dbus-python > ddupdate > debconf > deltarpm > devscripts > diceware > diffoscope > distcc > distro-info > dlrn > dnf-plugin-diff > dnf-plugin-ovl > dnf-plugins-core > dnfdaemon > dnfdragora > docker-compose > doge > dogtail > dot2tex > dput-ng > dxf2gcode > dynaconf > electrum > enjarify > enki > eric > esptool > etckeeper > evemu > execdb > fabric > fail2ban > fapolicyd > fedfind > fedmod > fedmsg > fedpkg > file > firewalld > flann > flatcam > flatpak-module-tools > flent > fmf > fontdump > fonts-tweak-tool > freeipa > freeipa-desktop-profile > freeipa-healthcheck > fros > fusion-icon > future > gajim > gaupol > gcc > gcovr > gerrymander > ginga > git-archive-all > git-pull-request > git-review > gitg > glances > gmsh > gnofract4d > gnome-abrt > gns3-net-converter > go2rpm > gofer > gom > goobook > google-api-python-client > google-compute-engine-tools > gpaw > gpgme > gphotoframe > gpsd > graphviz > grin > grpc > gtimelog > gtts > gtts-token > guake > gumbo-parser > gyp > h5py > hamlib > hashid > hatch > heat-cfntools > heketi > hgsvn > hivex > holland > hovercraft > httpie > httpwatcher > hugin > ibus-cangjie > imgbased > inception > insight > ioc-writer > iotop > irclog2html > is-it-in-rhel > jabberpy > javapackages-tools > jpype > jrnl > json_diff > keycloak-httpd-client-install > khal > khard > kicad > kismon > kobo > koji-containerbuild > koschei > lammps > lazygal > lcm > ldns > lecm > legofy > lensfun > libCombine > libbatch > libbytesize > libcaca > libcap-ng > libchewing > libcomps > libgexiv2 > libgit2-glib > libgpuarray > libiio > libkdtree++ > libkml > libkolabxml > liblinear > liblouis > libnuml > liborcus > libpfm > libprelude > libpreludedb > libproxy > librepo > libreport > libsbml > libsedml > libselinux > libsemanage > libsmbios > libsoc > libsolv > libstoragemgmt > libtaskotron > libtdb > libvoikko > libxc > libxml2 > libyang > libyui-bindings > lightdm-gtk-greeter-settings > limnoria > lirc > livecd-tools > lnst > loook > lorax > lttng-ust > m2crypto > mailman3-fedmsg-plugin > manuale > marisa > mate-menu > mathgl > med > meld > menulibre > meson > mgarepo > mir > mirrormanager2 > mlpack > mnemosyne > mod_wsgi > modtools > module-build-service-copr > mpi4py > msoffcrypto-tool > mu > mycli > mysql-connector-python > nest > net-snmp > netcdf4-python > netgen-mesher > netstat-monitor > neuron > newt > nfoview > nfsometer > nml > nmstate > nodepool > notmuch > nototools > nova-agent > nvmetcli > nyx > oct2spec > odcs > odfpy > ogr2osm > omniORB > omniORBpy > onboard > onionshare > openbabel > openmeeg > openscap > openscap-daemon > openslide-python > opentrep > openwsman > oraculum > osbs-client > osc > otf2 > oz > pacemaker > pag > pagure > pagure-dist-git > paperwork > parsero > patool > pcp > pcp2pdf > pcs > pdfposter > percol > petsc4py > pew > pgzero > photocollage > pipenv > piper > pipsi > pitivi > pkgwat > pki-core > playitagainsam > poetry > poezio > portmidi > powerline > prelude-correlator > preprocess > prewikka > printrun > proselint > protobuf > pss > pssh > ptpython > py-bcrypt > py-radix > py3status > py4j > pyOpenSSL > pyaudio > p
Re: packaging: upgrade a library to a header-only library
I wrote:
> Indeed, CMake will also find CMake data under %{_datadir}, and data for
> noarch packages must be installed there.
>
> CMake will not do it automagically for you, you need to actually
> explicitly install the files to the proper place. INSTALL(EXPORTS takes a
> DESTINATION argument:
> https://cmake.org/cmake/help/v3.15/command/install.html#installing-exports
> It needs to be set to the correct path.
PS: I guess all upstreams just copy&paste the example in:
https://cmake.org/cmake/help/v3.15/manual/cmake-packages.7.html#creating-packages
which hardcodes:
set(ConfigPackageLocation lib/cmake/ClimbingStats)
and do not understand that architecture-independent packages should use:
set(ConfigPackageLocation share/cmake/ClimbingStats)
instead (and hardcoding "lib" is entirely wrong because this should usually
be "lib64" on Fedora).
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: packaging: upgrade a library to a header-only library
Neal Gompa wrote:
> If it's a header-only library, CMake stuff being installed into
> %{_libdir} is probably wrong. CMake has a noarch path in %{_datadir},
> so it probably needs fixing to use that.
Indeed, CMake will also find CMake data under %{_datadir}, and data for
noarch packages must be installed there.
CMake will not do it automagically for you, you need to actually explicitly
install the files to the proper place. INSTALL(EXPORTS takes a DESTINATION
argument:
https://cmake.org/cmake/help/v3.15/command/install.html#installing-exports
It needs to be set to the correct path.
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: packaging: upgrade a library to a header-only library
Richard Shaw wrote: > Could you build the package twice using mock (x86_64 and i686) and run > rpmdiff on them to see if there's anything significant? FYI, if you use an arch-specific dummy main package and a noarch -devel subpackage, that is actually automatically done by Koji at every build. So if there is arch-specific content of any kind (arch-specific paths, multilib conflicts (arch-specific file contents), etc.), it will fail the build. Of course, if you use a noarch main package, you're on your own (Koji will only build it once on a random architecture), but that is frowned upon anyway, because tests (%check) will also only be run on one architecture. 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: Proposal to use repo files in Anaconda environment
On Thu, 2019-09-26 at 08:26 -0700, Brian C. Lane wrote: > On Thu, Sep 26, 2019 at 02:25:49PM +0200, jkone...@redhat.com wrote: > > On Fri, 2019-09-20 at 10:21 -0700, Brian C. Lane wrote: > > > On Tue, Sep 17, 2019 at 03:09:01PM +0200, jkone...@redhat.com > > > wrote: > > [snip] > > > > With an updates.img solution like you are describing here is > > > there > > > anything > > > to be done? Can't it already drop new repos into > > > /etc/yum.repos.d/ or > > > /etc/anaconda.repos.d/ ? > > > > In general no, it should work without changes. That is a great > > benefit > > of this solution. The only thing is if we want to create a tool for > > the > > updates image creation. > > > > I was also thinking about a behavior nuances. Like, if we want to > > change default behavior of how Anaconda works with these > > repositories > > than it may be interesting to have a separate folder to found out > > these > > repositories. > > > > > With my lmc patch for certs I am doing something like this, but > > > only > > > with the cert files, not the repo files. updates.img > > > > > > https://github.com/weldr/lorax/pull/839 > > > > Our idea is to have everything as part of the updates image, repo > > files > > and certificates. > > > > > From the perspective of lmc no-virt mode and lorax-composer > > > (which > > > use anaconda directly) it would be most useful to add a --repo > > > and/or > > > --repodir cmdline option to anaconda that adds the repos to the > > > dnf > > > base > > > object, similar to the way that lorax does things: > > > > > > https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L114 > > > > > > updates.img doesn't help with these use cases. > > > > Seems interesting. I'm just thinking if we don't want to rather use > > configuration files for Anaconda. Not sure, it would require a > > change > > in the Anaconda but shouldn't be that hard. > > > > FYI: Configuration files were added to Anaconda recently to be able > > override behavior and it is the replacement for install classes. > > For > > you it would mean that you will create the configuration file (ini > > format) in the specified directory to tell us where to look for the > > repo files. > > > > There is also a question, is there a use for the --repodir which > > can't > > be solved by changing configuration files of Anaconda or otherwise > > what > > is the preferred way here? > > Oh, interesting! I wasn't aware of that, I'll take a look at it and > see > if I can make it work w/o any other changes. Yes, I think it will be interesting for your. However, we have to first implement the drop dir solution to avoid changing system anaconda configuration. It's on our TODO list and if you have any use for that now, we can make it higher priority. > > > > > I totally agree with the goals here, the repo command in > > > kickstart is > > > getting too long, but we need a way to handle special cases where > > > people > > > need access to more of the dnf options. > > > > > > At the same time I'm worried about the loss of information that > > > this > > > can > > > cause. Although I don't want to just dump dnf repo files into > > > kickstart > > > -- that defeats the purpose of making it (somewhat) disconnected > > > from > > > the > > > specific backends like yum vs dnf. > > > > I think you have the same even now. The default settings for Fedora > > depends on what variant are you using. Based on the environment you > > are > > using for the installation you will get the result. > > With kickstart you don't use the host environment's repos, unless you > specifically reference them (at least that's how it used to work). > eg. > you can enable the updates repo shipped on the boot.iso with 'repo > --name=updates' but if you don't do that the only repos used are the > ones in the kickstart. Yes that is true and it is still supported. Also you can set closest mirror without kickstart which will use pre-installed fedora repo files . That is basically the same as repo --name solution but from GUI. The point is that this feature depends on a stage2 environment and that is exactly what I meant. Thanks to this you are able to create KS file which don't have all the information. I'm not convinced that adding repo files more support from Anaconda will make this situation any worse. > > > > Another option may be to use %pre to write out the repo files > > > (I'm > > > not > > > sure if anaconda will currently pick those up, but it should be > > > possible > > > to fix if it doesn't). > > > > We are thinking about tweaking existing sections to be able to just > > dump a general file somewhere (could be a script which will be run > > in > > the other section or repo file). That would be better solution for > > the > > %pre sections repo dumping. It would look like: > > > > %pre --dump-file=/anaconda.repos.d/my.repo > > > > %end > > > > However, this will not solve GPG key files or certificates so we > > are > > more thinking ab
HEADS UP: Rawhide rebuild of Python packages with old bytecode version
Hello, Python packages built with Python < 3.8.0b4 have invalid bytecode version, because the version was updated in 3.8.0b4. To see why this is a problem, follow the bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1748018 We were waiting for 3.8.0rc1 to see if the version is not updated once more. It was not. After rc1 hits the f32 buildroot we will mass bump and rebuild all Python packages that still have the old bytecode. The list of packages based on data from Monday (to be updated): 2ping 5minute APLpy ATpy Cython GitPython Mayavi NLopt OpenIPMI OpenLP ProDy PyDrive PyGreSQL PyMca PyQt4 PySolFC PyX RBTools SoapySDR ViTables WALinuxAgent abrt abrt-server-info-page adapt airnef alot ampy ansible-bender ansible-lint ansible-review antimony appliance-tools apx arandr artifacts asciidoc asciinema assimp astrometry asv atomic-reactor aubio audit authselect autoarchive autojump autokey avogadro2-libs awake babeltrace bandit barman battray bcc beets binwalk blivet-gui blueman bodhi boom-boot boost borgmatic botan botan2 bpython brotli btest btrfs-sxbackup buildbot bumpversion cairo-dock-plug-ins calamares cantoolz capstone caribou ccsm cheat cinch classification-banner cloud-init clufter clustershell codespell colin commissaire-client compose-utils concordance congruity conu copr-cli copr-keygen copr-messaging copr-rpmbuild copydeps cranc csmock csound csvdiff cura cura-lulzbot custodia cxxtest d-feet datanommer-commands dbus-python ddupdate debconf deltarpm devscripts diceware diffoscope distcc distro-info dlrn dnf-plugin-diff dnf-plugin-ovl dnf-plugins-core dnfdaemon dnfdragora docker-compose doge dogtail dot2tex dput-ng dxf2gcode dynaconf electrum enjarify enki eric esptool etckeeper evemu execdb fabric fail2ban fapolicyd fedfind fedmod fedmsg fedpkg file firewalld flann flatcam flatpak-module-tools flent fmf fontdump fonts-tweak-tool freeipa freeipa-desktop-profile freeipa-healthcheck fros fusion-icon future gajim gaupol gcc gcovr gerrymander ginga git-archive-all git-pull-request git-review gitg glances gmsh gnofract4d gnome-abrt gns3-net-converter go2rpm gofer gom goobook google-api-python-client google-compute-engine-tools gpaw gpgme gphotoframe gpsd graphviz grin grpc gtimelog gtts gtts-token guake gumbo-parser gyp h5py hamlib hashid hatch heat-cfntools heketi hgsvn hivex holland hovercraft httpie httpwatcher hugin ibus-cangjie imgbased inception insight ioc-writer iotop irclog2html is-it-in-rhel jabberpy javapackages-tools jpype jrnl json_diff keycloak-httpd-client-install khal khard kicad kismon kobo koji-containerbuild koschei lammps lazygal lcm ldns lecm legofy lensfun libCombine libbatch libbytesize libcaca libcap-ng libchewing libcomps libgexiv2 libgit2-glib libgpuarray libiio libkdtree++ libkml libkolabxml liblinear liblouis libnuml liborcus libpfm libprelude libpreludedb libproxy librepo libreport libsbml libsedml libselinux libsemanage libsmbios libsoc libsolv libstoragemgmt libtaskotron libtdb libvoikko libxc libxml2 libyang libyui-bindings lightdm-gtk-greeter-settings limnoria lirc livecd-tools lnst loook lorax lttng-ust m2crypto mailman3-fedmsg-plugin manuale marisa mate-menu mathgl med meld menulibre meson mgarepo mir mirrormanager2 mlpack mnemosyne mod_wsgi modtools module-build-service-copr mpi4py msoffcrypto-tool mu mycli mysql-connector-python nest net-snmp netcdf4-python netgen-mesher netstat-monitor neuron newt nfoview nfsometer nml nmstate nodepool notmuch nototools nova-agent nvmetcli nyx oct2spec odcs odfpy ogr2osm omniORB omniORBpy onboard onionshare openbabel openmeeg openscap openscap-daemon openslide-python opentrep openwsman oraculum osbs-client osc otf2 oz pacemaker pag pagure pagure-dist-git paperwork parsero patool pcp pcp2pdf pcs pdfposter percol petsc4py pew pgzero photocollage pipenv piper pipsi pitivi pkgwat pki-core playitagainsam poetry poezio portmidi powerline prelude-correlator preprocess prewikka printrun proselint protobuf pss pssh ptpython py-bcrypt py-radix py3status py4j pyOpenSSL pyaudio pybluez pybox2d pybugz pycairo pycanberra pychess pycmd pycolumnize pycscope pydot pyee pyelftools pyephem pyflakes pyftpdlib pygame pygrib pygsl pyhoca-cli pyhoca-gui pyicu pyjokes pyke pykickstart pykka pylast pymilia pymodbus pyosmium pyowm pyp2rpm pyparted pypolicyd-spf pyppd pypykatz pyqtrailer pyscard pyserial pyshp pysnmp pysubnettree pysysbot pytest pythia8 python-AppTools python-BTrees python-Bottleneck python-CacheControl python-CommonMark python-ECPy python-IPy python-Lektor python-Levenshtein python-Mastodon python-ModulemdTranslationHelpers python-MultipartPostHandler2 python-Naked python-OWSLib python-PyGithub python-PyLEMS python-PyLink python-PyMySQL python-PyPDF2 python-PyRSS2Gen python-QtAwesome python-QtPy python-Rtree python-SALib python-SecretStorage python-Traits python-XStatic python-XStatic-Angular python-XStatic-Angular-Bootstrap python-XStatic-Angular-FileUpload python-XStatic-Angular-Gettext python-XStatic-Angular-Mock python-XSt
Re: Defining the future of the packager workflow in Fedora
Am 01.10.19 um 16:55 schrieb Stephen John Smoogen: Then there are problems with budgets and figuring out what exactly it would cost. We fall outside of many of the 'caveats' that would allow us to get free. IIRC at the time when Fedora evaluated its options the open source version of Gitlab was more limited than today. AFAIK Debian + FreeDesktop developers worked with Gitlab Inc. and finally succeeded in getting necessary features included in the open source version. If the evaluation was done today and there were no Pagure I suspect Fedora would use gitlab as well. (I'm also wondering if Fedora writes too much custom infrastructure when there are "open core" offerings which might provide more features - e.g. Gitlab instead of Pagure, sentry instead of abrt. But I'm aware of limited ressources and I trust my fellow Fedorians with their judgement.) Felix ___ 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
