[Bug 1922560] New: perl-Geo-Distance-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1922560 Bug ID: 1922560 Summary: perl-Geo-Distance-0.25 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Geo-Distance Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 0.25 Current version/release in rawhide: 0.24-6.fc33 URL: http://search.cpan.org/dist/Geo-Distance/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/12407/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[389-devel] 389 DS nightly 2021-01-30 - 95% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2021/01/30/report-389-ds-base-2.0.2-20210130git95201aa83.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
VTK 9 update coming shortly
I'm going to be starting to build vtk 9 and its dependents in f34-build-side-36621 shortly. Bugs have already been filed against packages that fail to build with it, but overall we're in pretty good shape. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: Boost 1.75.0 in rawhide, with soname change
On Fri, Jan 29, 2021 at 10:32 AM Jonathan Wakely wrote: > On 29/01/21 10:06 -0600, Richard Shaw wrote: > >I'm having an issue with OpenImageIO I don't understand. > > > >The build is failing with a ton of errors like these: > > > >/usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to > >`Field3D::v1_7::SparseFile::Reference > >::openFile()' > >/usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to > >`Field3D::v1_7::FieldCache >::ms_creationMutex' > >/usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to > >`Field3D::v1_7::SparseFile::Reference > >::openFile()' > >/usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to > >`Field3D::v1_7::Field >::Vec > >Field3D::v1_7::Field3DInputFile::readLayers > >>(std::__cxx11::basic_string, > >std::allocator > const&) const' > >/usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to > >`Field3D::v1_7::SparseFile::Reference >::openFile()' > >/usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to > > >`Field3D::v1_7::MatrixFieldMapping::setLocalToWorld(Imath_2_5::Matrix44 > >const&)' > > > >But libOpenImageIO.so is being linked with Field3D so I assume it's some > >interaction with openexr (the Imath_2_5 stuff). But when I look at the > >build for Field3D and OpenImageIO they both are building against the new > >openexr... > > > >Is this even Boost related? It doesn't look like it, but it built > >previously with the new openexr and the same version of Field3D before the > >boost change AFAICT. > > Yeah I looked at this one and decided it didn't look Boost related. I > don't know what did cause it though. Field3D was rebuild with the new > Boost. > Turns out I needed to rebuild Field3D with openexr. It was disabled due to an issue at some point and just needed to be reenabled. 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
[Bug 1922014] perlbrew-0.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1922014 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- FEDORA-2021-8bdc43d5fc has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8bdc43d5fc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8bdc43d5fc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
Michael Catanzaro wrote: > Alternative: use automated reverts instead of force pushes, and don't > worry about maintaining a clean history. Sure, it is possible to make an implementation with lower quality of implementation with possibly less work, by omitting the force pushes and the smart "fedpkg build" behavior. That said, I think you will find that reverts are actually more work to get right in complex cases such as multi-commit pushes, possibly even with merge commits, than a simple: git reset --hard $last_successful_build git push -f which only needs the CI to be exempted from the git hook banning force pushes. 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
[Bug 1922518] New: perl-URI-5.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1922518 Bug ID: 1922518 Summary: perl-URI-5.07 is available Product: Fedora Version: rawhide Status: NEW Component: perl-URI Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jples...@redhat.com, ka...@ucw.cz, p...@city-fan.org, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 5.07 Current version/release in rawhide: 5.06-1.fc34 URL: http://search.cpan.org/dist/URI/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3485/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Should opencv require scala on runtime?
Miro Hrončok wrote: > [~]$ repoquery --installed --whatrequires coin-or-Cbc > coin-or-Clp-0:1.17.6-2.fc33.x86_64 Why does Clp require Cbc? As far as I know, Cbc uses Clp, not the opposite. I see coin-or-Cbc goes through great lengths to bootstrap the circular dependency on Cbc, to manually set COIN_HAS_CBC, and to manually link -lCbc, which is not even supported by the upstream autotools setup. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora rawhide compose report: 20210129.n.0 changes
On Fri, Jan 29, 2021 at 2:49 PM Fedora Rawhide Report wrote: > (snip) > > Package: golang-torproject-pluggable-transports-goptlib-1.1.0-6.fc34 > Old package: golang-torproject-pluggable-transports-goptlib-1.1.0-5.fc33 > Summary: Library for writing Tor pluggable transports in Go > RPMs: golang-torproject-pluggable-transports-goptlib-devel > Size: 37.12 KiB > Size change: 129 B > Changelog: > * Tue Jan 26 2021 Fedora Release Engineering - > 1.1.0-6 > - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild What's going on here? This is one of a lot of packages that only have the mass rebuild changelog entry but no other changes, and have not been built by releng, but by other packagers, according to koji. Did people resubmit failed mass rebuild builds themselves (and not for f34-build)? I thought there's going to be an official second round of builds to weed out transient issues? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On Fri, Jan 29, 2021 at 4:11 PM Fabio Valentini wrote:
> I seem to remember that there is a mock config option for this. But
> looking at the current configs (e.g. fedora-rawhide-x86_64) I only see
> an option to enable and install additional *modules*, not *packages*.
> I'm pretty sure there's a way to add something to the packages that is
> installed with the @buildsys group, but I can't find it right now. :(
It's probably this (from /etc/mock/templates/fedora-rawhide.tmpl):
config_opts['chroot_setup_cmd'] = 'install @{% if mirrored
%}buildsys-{% endif %}build'
I imagine you would want to add more names to that install command. I
have not actually tried it, however.
--
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: Proposal to deprecated `fedpkg local`
On Sat, Jan 30, 2021 at 12:04 AM Richard Shaw wrote: > (snip) > Is there an easy way to override/add things to the buildroot locally without > making it a global change for the whole distro? I seem to remember that there is a mock config option for this. But looking at the current configs (e.g. fedora-rawhide-x86_64) I only see an option to enable and install additional *modules*, not *packages*. I'm pretty sure there's a way to add something to the packages that is installed with the @buildsys group, but I can't find it right now. :( Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On Fri, Jan 29, 2021 at 5:02 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Vít Ondruch wrote: > > While I typically tend to use editor from my host (I quite often use > > GVim or GEdit, which are both GUI editors), I stumble upon the missing > > `less` quite often. If there was way to somehow `mount` the editor from > > host into the buildroot, but I can't think of any feasible way :( > > The obvious answer would be to just add `less` to the minimal buildroot. > The > cost would be minimal considering the buildroot cache. But instead, a lot > of > time is actually spent (IMHO wasted) to kick useful stuff out of the > minimal > buildroot even if it means breaking thousands of specfiles in Fedora and > at > third parties (e.g., make). > Is there an easy way to override/add things to the buildroot locally without making it a global change for the whole distro? 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: Proposal to deprecated `fedpkg local`
Vít Ondruch wrote: > While I typically tend to use editor from my host (I quite often use > GVim or GEdit, which are both GUI editors), I stumble upon the missing > `less` quite often. If there was way to somehow `mount` the editor from > host into the buildroot, but I can't think of any feasible way :( The obvious answer would be to just add `less` to the minimal buildroot. The cost would be minimal considering the buildroot cache. But instead, a lot of time is actually spent (IMHO wasted) to kick useful stuff out of the minimal buildroot even if it means breaking thousands of specfiles in Fedora and at third parties (e.g., make). 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: dropping selinux-policy strict version requirement
Thanks Vit!
That clears it up. It sounds like if we want to support multiple RHEL
minor releases *and* CentOS Stream, we're going to have to compile in
a buildroot that has the oldest version of selinux-policy that we want
to support.
- Ken
On Thu, Jan 28, 2021 at 2:00 AM Vit Mojzis wrote:
>
> Hi,
>
> the exact version requirement is in place to avoid incompatibility
> between the policy on the target system (system you want to install the
> module on) and the custom policy module.
>
> Lets call the policy used to compile your module "A", policy on the
> target system "B" and your custom module "C".
>
> C can be incompatible with B if A contains a new definition (object
> class, permission, type or boolean) that is not present in B and the
> newly defined name is used in your module (e.g. because of an interface
> used in your module). The incompatibility will prevent installation of
> your module ("semodule -i" will fail).
>
> Please see [1] to get an idea of when you can expect new definitions to
> appear in RHEL policy.
>
> Depending on an unversioned selinux-policy-base can therefore cause
> problems not only when installing policy compiled on RHEL to a CentOS
> system, but also when installing it on the same version of RHEL, with
> outdated system policy.
>
> I would at least suggest using dependency on some reasonably recent
> fixed version of selinux-policy-base, and testing each new build of your
> module on a system with that fixed version of selinux-policy-base.
>
> However, it would be best to avoid cross-sytem installations.
>
> Hope this helps.
>
>
> Vit
>
>
> [1] - https://access.redhat.com/articles/4854201
>
> On 1/27/21 6:30 PM, Ken Dreyer wrote:
> > Hi folks,
> >
> > Many applications ship their own "-selinux" sub-package. These
> > subpackages usually set a minimal dependency on the exact
> > selinux-policy version in the buildroot.
> >
> > In Ceph's case, we have:
> >
> >Requires(post): selinux-policy-base >= %{_selinux_policy_version}
> >
> > This version requirement causes problems in two scenarios:
> >
> > 1. If we build Ceph on CentOS Stream, the ceph-selinux package will be
> > uninstallable on RHEL.
> >
> > 2. If we build Ceph on the latest RHEL 8, the ceph-selinux package
> > package will be uninstallable on RHEL 8 EUS.
> >
> > Is it safe to drop the exact version requirement here and just depend
> > on an unversioned "selinux-policy-base"?
> >
> > I can't find any official Fedora Packaging Guideline on this. I opened
> > https://tracker.ceph.com/issues/49034 to track this in Ceph upstream.
> >
> > - Ken
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL9 - thoughts and timings
On Fri, Jan 29, 2021 at 2:29 AM Petr Pisar wrote: > > On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote: > > I think that could be workable, but I'll toss out another proposal: > > > > As soon as centos 9 stream exists, we create epel9-playground and allow > > people to branch/add packages to it. Once rhel9 is GA, we setup epel9 as > > usual and epel9-next and point epel9-next to build against stream and > > playground to build against rhel9. > > > Do you know what CentOS 9 Stream will look like between its first availability > and RHEL 9 GA? I worry that there will surface RHEL 9.1 changes. Then > switching epel9-playground from CentOS 9 Stream to RHEL 9 could manifest > incompatibilities as the build root would regress. > Very good question Petr, and thanks for asking it. I asked internally about this. There will be a set time [1] when RHEL 9.0.0 release will be branched, and all the final stabilizing stuff will happen internally. At that point, CentOS 9 Stream will be on the 9.1.0 release, and any changes to it will not be in the 9.0.0 GA. I don't know when that point in time is, I haven't figured it out yet. But my educated guess is 3 months before GA, if I'm wrong, then I don't think more than 6 months before GA. So, that gives us something to consider. Do we think that 3 to 6 months of possible changes will affect us too much? Troy [1] - I wasn't given a date, just X weeks into the schedule. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
Robbie Harwood wrote: > Vít Ondruch writes: >> Just FTR, mock supports `--arch=ARCH` which will use emulation to >> allow you build whatever architecture localy. I have never used it >> myself, but I wanted to mention this. > > I recommend you try. Prepare to be underwhelmed by speed :) Expect a factor 50 slowdown with QEMU software emulation. (At least that was the factor when I did 64-bit builds in qemu-system-x86_64 on a 32-bit x86 CPU back in the day. Usermode emulation, which was not available for emulating x86_64 at the time, might be marginally faster.) 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: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
On Fri, Jan 29, 2021 at 6:52 pm, Kevin Kofler via devel wrote: 6. if the CI build fails, the branch "rawhide" or "fn" is automatically force-pushed back to the last commit that successfully built, and an e-mail notification is sent. Force-pushing is safe in that case because there was by definition no successful build, hence nothing that shipped in any repos. Rewinding to the last successful build should work even if multiple broken commits by multiple maintainers have been pushed since. Alternative: use automated reverts instead of force pushes, and don't worry about maintaining a clean history. ___ 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 deprecated `fedpkg local`
Otto Urpelainen wrote: > The other option of not using 'git add .' can also be described as > mentally filtering out all the irrelevant unstaged changes to find the > ones that should actually be added. That adds cognitive burden, slows > things down and leads to mistakes every now and then. It does not help > to say "do not make mistakes" if the task is inherently error-prone. > Such filtering is something a computer should do, which leads us back to > .gitignore. I find it very helpful to use a Git GUI instead of the CLI. I use Git Cola for everything (which also means that I don't use those fedpkg commands that are just wrapper around git commands, because Git Cola uses git directly). Git Cola nicely shows me which files are new or modified. I can choose for each file to stage it for commit (i.e., "add" them), add it to .gitignore, or just do nothing and leave it there. And how do I run fedpkg build? I have Git Cola configured to use QGit as the history viewer. QGit has customizable actions which can run CLI commands. You can nicely set them up through the GUI. So I just do "view history" in Git Cola to fire up QGit and "Build in Koji" (custom action) in QGit. And for things such as "fedpkg new-sources", I have wrapper scripts (which I also added as custom QGit actions) using KDialog so I can select the files with a nice GUI file dialog. I guess I should upload my configs and scripts somewhere for people who prefer GUI tools to CLI tools. (The only annoyance I have is the requirement to run Kerberos kinit that was introduced a few years ago. There does not seem to be a decent KDE frontend for Kerberos with auto-login with a password from KWallet, the only one I have found dates back to KDE 3 and IIRC had issues that made it not worth attempting to package.) 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: Boost 1.75.0 in rawhide, with soname change
On Mon, 2021-01-25 at 10:00 +, Jonathan Wakely wrote: > Tom Rodgers completed the Boost 1.75.0 build for the change > https://fedoraproject.org/wiki/Changes/F34Boost175 > and I've rebuilt most of the packages that depend on it. > Some of the packages depending on Folly didn't get rebuilt, but that's fine, I've done an update that got all of them. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git
Matthew Miller wrote: > Yeah, honestly, this is also a pretty serious hardship for the long tail > of people maintaining a handful of infrequently updated packages. I'm > hugely in favor of not checking in work in progress on the main or release > branches, but let's not make more steps. I still think that the best way to do CI would be what I already suggested at least once: 1. maintainer pushes the commit to the branch "rawhide" or "fn" 2. a quick synchronous commit hook validates obvious things such as the presence of source files and patches If this fails, the push fails and we stop here. Otherwise: 3. another commit hook asynchronously triggers a CI build 4. the push succeeds (without waiting for the CI build to complete) 5. the asynchronous CI attempts to build the package 6. if the CI build fails, the branch "rawhide" or "fn" is automatically force-pushed back to the last commit that successfully built, and an e-mail notification is sent. Force-pushing is safe in that case because there was by definition no successful build, hence nothing that shipped in any repos. Rewinding to the last successful build should work even if multiple broken commits by multiple maintainers have been pushed since. 7. by default, CI builds are treated as scratch builds, but in order to conserve resources, it should be possible for the maintainer to mark a CI build as a production build either during the build or within a reasonable time after completion. Ideally, fedpkg build should automatically do that instead of triggering another, redundant build if it finds a suitable CI build to retain. If fully implemented (including the "ideally" part), this achieves the goal that maintainers need not adjust their workflow at all. They just push their changes and run "fedpkg build", the CI happens behind the scenes, "fedpkg build" automatically sets the CI flag to retain the build if successful, and watches the CI build unless --nowait is used. And if the build fails, they can just commit a fix locally and redo a new push, which will also push the previous failed commit back (but the CI will not attempt to build it again because there is now a newer commit on top which will be built instead – and if that, too, fails, the CI will rewind the whole thing). At the same time, broken commits never persist in dist-git once they are known not to build, the history remains clean (because everything broken gets force-pushed out of the way), and, thanks to the automatic force-pushed rewind, maintainers can, if they wish, opt to push an amended commit (clean history!) instead of the "the last commit was broken, fix it" commit they have to do now (but they can still do the latter if they wish, as explained above). In contrast, any kind of pull-request workflow, even an automatic one, makes the history even less clean than it is now. 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
Fedora-Rawhide-20210129.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 6 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 45/123 (aarch64), 30/181 (x86_64) New failures (same test not failed in Fedora-Rawhide-20210128.n.0): ID: 764865 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/764865 ID: 764866 Test: aarch64 Minimal-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/764866 ID: 764867 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/764867 ID: 764868 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/764868 ID: 764873 Test: aarch64 Server-dvd-iso support_server@uefi URL: https://openqa.fedoraproject.org/tests/764873 ID: 764875 Test: aarch64 Server-dvd-iso install_repository_nfs_graphical@uefi URL: https://openqa.fedoraproject.org/tests/764875 ID: 764885 Test: aarch64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/764885 ID: 764886 Test: aarch64 Server-dvd-iso install_repository_nfs_variation@uefi URL: https://openqa.fedoraproject.org/tests/764886 ID: 764914 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/764914 ID: 764915 Test: aarch64 Server-raw_xz-raw.xz base_selinux@uefi URL: https://openqa.fedoraproject.org/tests/764915 ID: 764916 Test: aarch64 Server-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/764916 ID: 764917 Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/764917 ID: 765016 Test: aarch64 universal install_repository_http_variation@uefi URL: https://openqa.fedoraproject.org/tests/765016 ID: 765093 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/765093 Old failures (same test failed in Fedora-Rawhide-20210128.n.0): ID: 764770 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/764770 ID: 764775 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/764775 ID: 764787 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/764787 ID: 764788 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/764788 ID: 764791 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/764791 ID: 764797 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/764797 ID: 764798 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/764798 ID: 764799 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/764799 ID: 764801 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/764801 ID: 764810 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/764810 ID: 764813 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/764813 ID: 764824 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/764824 ID: 764874 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/764874 ID: 764877 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi URL: https://openqa.fedoraproject.org/tests/764877 ID: 764881 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/764881 ID: 764889 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/764889 ID: 764896 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/764896 ID: 764900 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/764900 ID: 764904 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/764904 ID: 764906 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/764906 ID: 764908 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/764908 ID: 764937 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/764937 ID: 764942
[Bug 1858048] rt-5.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858048 --- Comment #5 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of rt-5.0.1-1.fc32.src.rpm for rawhide failed http://koji.fedoraproject.org/koji/taskinfo?taskID=60832022 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1858048] rt-5.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858048 --- Comment #4 from Upstream Release Monitoring --- Created attachment 1752125 --> https://bugzilla.redhat.com/attachment.cgi?id=1752125=edit [patch] Update to 5.0.1 (#1858048) -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1858048] rt-5.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1858048 Upstream Release Monitoring changed: What|Removed |Added Summary|rt-5.0.0 is available |rt-5.0.1 is available --- Comment #3 from Upstream Release Monitoring --- Latest upstream release: 5.0.1 Current version/release in rawhide: 4.4.4-7.fc33 URL: http://bestpractical.com/request-tracker/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7292/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On Thu, 2021-01-28 at 10:09 +0100, Petr Pisar wrote: > On Wed, Jan 27, 2021 at 06:58:05PM +0100, Vít Ondruch wrote: > > Dne 27. 01. 21 v 18:53 Petr Menšík napsal(a): > > > This would describe my usual workflow as well. fedpkg local is > > > great for > > > checking soname did not change, patches apply, to debugging why > > > my test > > > suites fail and how they behave. mock usual does not have even > > > vim > > > > You have vim on your host with your configuration, why would you > > need it in > > mock? > > > $ fedpkg local > failed. > $ cd foo-1.2.3/ > $ make test > t/foo failed. > $ vim t/foo > make some changes > $ make test > here is you debugging output > > I find > > $ vim > /var/lib/mock/SOME_GIBBERISH_I_NEVER_REMEMBER_AND_I_DONT_KNOW_WHICH_I > S_THE_RIGHT_ONE/root/builddir/build/BUILD/foo-1.2.3/t/foo > > less useable. This is easy to fix with a symlink ln -s /var/lib/mock/fedora-33-x86_64/root/builddir/build/ f33-buildir -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)
Panu Matilainen wrote: > On my F33 laptop, there are 331284 rpm-installed files. The IMA > signature as proposed is apparently 162 bytes per file in the > hex-encoded format, this makes for approximately 51 megabytes of data. > My rpmdb is about 115 megabytes. That'd be almost 45% increase in size! > And this would be on EVERYBODY's database whether you use the feature or > not, also slowing down every single rpm query somewhat as a whole lot > more data has to be pulled from disk, and there's no way to get rid of > the weight once its there. The height of the insult is that the data is > essentially useless in the rpmdb, it's only relevant during > installation, for the (presumably few) people who actually enable the > feature. And of course that extra weight in every single package is > carried around in mirrors and each and every package download too, again > whether you use the feature or not. > > What the IMA feature really needs is a redesign to avoid inflicting this > cost on everybody whether you use the feature or not, but the > low-hanging fruit is the encoding: the hex encoding is just about the > most stupid format there is for such a purpose, when base64 encoded the > same data is ~38% of the size of the hex encoding, which brings down the > IMA data size in the above figures to ~19 megabytes and ~17% increase in > rpmdb size, which is a lot of data still but a lot less anyhow. IMHO, this overhead is entirely unacceptable. Even using base64 would still be too expensive. This Change should just be permanently rejected (not just for F34 as it already was). I disagree that centrally signed individual files are a desirable feature at all. It is already clear that the vast majority of users will have no use for this feature and will not have it enabled. Hence, I do not see why we should be paying for it with any kind of overhead. Not even if it were only the overhead of infrastructure having to sign all those files and mirrors having to carry an external database. 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: Boost 1.75.0 in rawhide, with soname change
On 29/01/21 10:06 -0600, Richard Shaw wrote: I'm having an issue with OpenImageIO I don't understand. The build is failing with a ton of errors like these: /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::SparseFile::Reference >::openFile()' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::FieldCache >::ms_creationMutex' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::SparseFile::Reference >::openFile()' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::Field >::Vec Field3D::v1_7::Field3DInputFile::readLayers (std::__cxx11::basic_string, std::allocator > const&) const' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::SparseFile::Reference >::openFile()' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::MatrixFieldMapping::setLocalToWorld(Imath_2_5::Matrix44 const&)' But libOpenImageIO.so is being linked with Field3D so I assume it's some interaction with openexr (the Imath_2_5 stuff). But when I look at the build for Field3D and OpenImageIO they both are building against the new openexr... Is this even Boost related? It doesn't look like it, but it built previously with the new openexr and the same version of Field3D before the boost change AFAICT. Yeah I looked at this one and decided it didn't look Boost related. I don't know what did cause it though. Field3D was rebuild with the new Boost. To debug this it might help to add -Wl,--no-demangle to the gcc options used for linking so that you get the mangled names of the missing symbols. Then you can look at the Field3D libs and see if they're providing those symbols, or if they have different names. You can do that by looking at the demangled names in the errors above, but it's sometimes easier to compare the real symbol names. ___ 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: Boost 1.75.0 in rawhide, with soname change
On 29. 01. 21 17:20, Jonathan Wakely wrote: The unannounced C++14 requirement was unfortunate, if it had been listed at https://www.boost.org/users/history/version_1_75_0.html we would have put it in the change proposal (it's there now). Thank You! -- 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: Proposal to deprecated `fedpkg local`
On 29/01/21 17:04 +0100, Miro Hrončok wrote: On 29. 01. 21 16:03, Jonathan Wakely wrote: So if fedpkg clone just added things to .git/info/exclude there would be no need to modify every .gitignore file in every repo on every active branch. That is already the case \o/ https://docs.pagure.org/fedpkg/releases/1.37.html#ignore-files-in-a-cloned-repository Nice! But making 'fedpkg local' unpack into ./build and then build in there still seems sensible, so the excluded patterns would change for that (I don't care about that as I don't use 'fedpkg local', but it seems like a good suggestion). $ fedpkg clone ... $ cat .../.git/info/exclude # git ls-files --others --exclude-from=.git/info/exclude # Lines that start with '#' are comments. # For a project mostly in C, the following would be a good set of # exclude patterns (uncomment them if you want to use them): # *.[oa] # *~ i386/ i686/ x86_64/ ppc/ ppc64/ ia64/ mips/ arm/ noarch/ /*.src.rpm /build*.log /.build-*.log results_*/ clog ___ 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: Boost 1.75.0 in rawhide, with soname change
On 29/01/21 16:00 +, Tom Hughes via devel wrote: On 29/01/2021 15:53, Jonathan Wakely wrote: On 29/01/21 16:47 +0100, Miro Hrončok wrote: On 25. 01. 21 11:00, Jonathan Wakely wrote: Tom Rodgers completed the Boost 1.75.0 build for the change https://fedoraproject.org/wiki/Changes/F34Boost175 and I've rebuilt most of the packages that depend on it... Hello. I now see a strange build failure on a package that is not listed here, because it doe snot require boost on runtime, only build time. python-pynest2d FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=1922297 I see deprecation warnings like: CAUTION: Boost.Geometry in Boost 1.73 deprecates support for C++03 and will require C++14 from Boost 1.75 onwards. And than I see a lot of errors. Is it possible that the errors are relevant to that deprecation? The line is suspiciously in future tense, but this laready is Boost 1.75, right? Yes, Boost.Geometry in 1.75.0 requires C++14, the warning is ... broken. In more than one way. Just changing the compile flags will likely fix it - it did for wagyu which failed with the same error in the mass rebuild. I notice that it didn't get picked up in the boost update because it looks like wagyu didn't get rebuild - presumably because it's a header only library and you only rebuilt the things that wind up with an soname dependency? Right. If I understand correctly, that's all that's (strictly) needed when changing a package soname. Packages already built against the older headers will continue to work. And this time round there was going to be a mass rebuild as soon as the boost builds finished anyway. The unannounced C++14 requirement was unfortunate, if it had been listed at https://www.boost.org/users/history/version_1_75_0.html we would have put it in the change proposal (it's there now). ___ 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: Boost 1.75.0 in rawhide, with soname change
I'm having an issue with OpenImageIO I don't understand. The build is failing with a ton of errors like these: /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::SparseFile::Reference >::openFile()' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::FieldCache >::ms_creationMutex' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::SparseFile::Reference >::openFile()' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::Field >::Vec Field3D::v1_7::Field3DInputFile::readLayers >(std::__cxx11::basic_string, std::allocator > const&) const' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::SparseFile::Reference >::openFile()' /usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to `Field3D::v1_7::MatrixFieldMapping::setLocalToWorld(Imath_2_5::Matrix44 const&)' But libOpenImageIO.so is being linked with Field3D so I assume it's some interaction with openexr (the Imath_2_5 stuff). But when I look at the build for Field3D and OpenImageIO they both are building against the new openexr... Is this even Boost related? It doesn't look like it, but it built previously with the new openexr and the same version of Field3D before the boost change AFAICT. 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: Boost 1.75.0 in rawhide, with soname change
On 29. 01. 21 17:00, Tom Hughes via devel wrote: I notice that it didn't get picked up in the boost update because it looks like wagyu didn't get rebuild - presumably because it's a header only library and you only rebuilt the things that wind up with an soname dependency? Yes. -- 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: Proposal to deprecated `fedpkg local`
On 29. 01. 21 16:03, Jonathan Wakely wrote: So if fedpkg clone just added things to .git/info/exclude there would be no need to modify every .gitignore file in every repo on every active branch. That is already the case \o/ https://docs.pagure.org/fedpkg/releases/1.37.html#ignore-files-in-a-cloned-repository $ fedpkg clone ... $ cat .../.git/info/exclude # git ls-files --others --exclude-from=.git/info/exclude # Lines that start with '#' are comments. # For a project mostly in C, the following would be a good set of # exclude patterns (uncomment them if you want to use them): # *.[oa] # *~ i386/ i686/ x86_64/ ppc/ ppc64/ ia64/ mips/ arm/ noarch/ /*.src.rpm /build*.log /.build-*.log results_*/ clog -- 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: Boost 1.75.0 in rawhide, with soname change
On 29/01/2021 15:53, Jonathan Wakely wrote: On 29/01/21 16:47 +0100, Miro Hrončok wrote: On 25. 01. 21 11:00, Jonathan Wakely wrote: Tom Rodgers completed the Boost 1.75.0 build for the change https://fedoraproject.org/wiki/Changes/F34Boost175 and I've rebuilt most of the packages that depend on it... Hello. I now see a strange build failure on a package that is not listed here, because it doe snot require boost on runtime, only build time. python-pynest2d FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=1922297 I see deprecation warnings like: CAUTION: Boost.Geometry in Boost 1.73 deprecates support for C++03 and will require C++14 from Boost 1.75 onwards. And than I see a lot of errors. Is it possible that the errors are relevant to that deprecation? The line is suspiciously in future tense, but this laready is Boost 1.75, right? Yes, Boost.Geometry in 1.75.0 requires C++14, the warning is ... broken. In more than one way. Just changing the compile flags will likely fix it - it did for wagyu which failed with the same error in the mass rebuild. I notice that it didn't get picked up in the boost update because it looks like wagyu didn't get rebuild - presumably because it's a header only library and you only rebuilt the things that wind up with an soname dependency? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-34-20210129.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 4/16 (x86_64), 8/15 (aarch64) New failures (same test not failed in Fedora-IoT-34-20210128.0): ID: 765110 Test: x86_64 IoT-dvd_ostree-iso podman URL: https://openqa.fedoraproject.org/tests/765110 ID: 765113 Test: x86_64 IoT-dvd_ostree-iso podman_client URL: https://openqa.fedoraproject.org/tests/765113 ID: 765124 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/765124 ID: 765135 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/765135 Old failures (same test failed in Fedora-IoT-34-20210128.0): ID: 765114 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/765114 ID: 765118 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/765118 ID: 765122 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/765122 ID: 765125 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/765125 ID: 765128 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/765128 ID: 765129 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/765129 ID: 765133 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/765133 ID: 765134 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/765134 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210128.0): ID: 765106 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/765106 Passed openQA tests: 11/16 (x86_64), 7/15 (aarch64) New passes (same test not passed in Fedora-IoT-34-20210128.0): ID: 765120 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/765120 ID: 765131 Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/765131 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Mount /run contents changed to 72.75675676% of previous size Mount /boot contents changed to 133.1141719% of previous size Used mem changed from 162 MiB to 275 MiB System load changed from 0.37 to 0.68 Previous test data: https://openqa.fedoraproject.org/tests/763609#downloads Current test data: https://openqa.fedoraproject.org/tests/765107#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Mount /run contents changed to 72.72400144% of previous size Mount /boot contents changed to 130.9875601% of previous size Used mem changed from 161 MiB to 271 MiB System load changed from 0.23 to 0.44 Previous test data: https://openqa.fedoraproject.org/tests/763610#downloads Current test data: https://openqa.fedoraproject.org/tests/765108#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.62 to 0.78 Previous test data: https://openqa.fedoraproject.org/tests/763625#downloads Current test data: https://openqa.fedoraproject.org/tests/765123#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Boost 1.75.0 in rawhide, with soname change
On 29/01/21 16:47 +0100, Miro Hrončok wrote: On 25. 01. 21 11:00, Jonathan Wakely wrote: Tom Rodgers completed the Boost 1.75.0 build for the change https://fedoraproject.org/wiki/Changes/F34Boost175 and I've rebuilt most of the packages that depend on it... Hello. I now see a strange build failure on a package that is not listed here, because it doe snot require boost on runtime, only build time. python-pynest2d FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=1922297 I see deprecation warnings like: CAUTION: Boost.Geometry in Boost 1.73 deprecates support for C++03 and will require C++14 from Boost 1.75 onwards. And than I see a lot of errors. Is it possible that the errors are relevant to that deprecation? The line is suspiciously in future tense, but this laready is Boost 1.75, right? Yes, Boost.Geometry in 1.75.0 requires C++14, the warning is ... broken. In more than one way. I already got them to update the release notes, because they didn't originally announce this changed requirement! ___ 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: cxxtools-2.2.1 fails to compile on rawhide with gcc11 with /usr/include/c++/11/string_view:98:21: error: static assertion failed
On 29/01/21 09:16 -, Martin Gansser wrote:
Hi,
i am trying to compile cxxtools 2.2.1 [1] on Fedora 34 with gcc11 but this
fails with following error messages [2]
on Fedora build server.
make[2]: Entering directory '/builddir/build/BUILD/cxxtools-2.2.1/src'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../src
-I../include -I../include -Wno-long-long -Wall -pedantic -O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c -o
settingswriter.lo settingswriter.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../src -I../include -I../include
-Wno-long-long -Wall -pedantic -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c
settingswriter.cpp -fPIC -DPIC -o .libs/settingswriter.o
In file included from settingswriter.h:31,
from settingswriter.cpp:28:
../include/cxxtools/char.h: In static member function 'static
std::char_traits::char_type*
std::char_traits::move(std::char_traits::char_type*, const
char_type*, std::char_traits::int_type)':
../include/cxxtools/char.h:337:80: warning: 'void* memmove(void*, const void*,
size_t)' writing to an object of type
'std::char_traits::char_type' {aka 'class cxxtools::Char'} with
no trivial copy-assignment; use copy-assignment or copy-initialization instead
[-Wclass-memaccess]
337 | return (cxxtools::Char*)std::memmove(s1, s2, n *
sizeof(cxxtools::Char));
|
^
In file included from settingswriter.h:31,
from settingswriter.cpp:28:
../include/cxxtools/char.h:65:11: note:
'std::char_traits::char_type' {aka 'class cxxtools::Char'}
declared here
65 | class Char
| ^~~~
In file included from settingswriter.h:31,
from settingswriter.cpp:28:
../include/cxxtools/char.h: In static member function 'static
std::char_traits::char_type*
std::char_traits::copy(std::char_traits::char_type*,
const char_type*, std::size_t)':
../include/cxxtools/char.h:344:79: warning: 'void* memcpy(void*, const void*,
size_t)' writing to an object of type
'std::char_traits::char_type' {aka 'class cxxtools::Char'} with
no trivial copy-assignment; use copy-assignment or copy-initialization instead
[-Wclass-memaccess]
344 | return (cxxtools::Char*)std::memcpy(s1, s2, n *
sizeof(cxxtools::Char));
|
^
This warning is surprising. The type should have a trivial copy
assignment operator.
In file included from settingswriter.h:31,
from settingswriter.cpp:28:
../include/cxxtools/char.h:65:11: note:
'std::char_traits::char_type' {aka 'class cxxtools::Char'}
declared here
65 | class Char
| ^~~~
In file included from /usr/include/c++/11/bits/basic_string.h:48,
from /usr/include/c++/11/string:55,
from ../include/cxxtools/char.h:32,
from settingswriter.h:31,
from settingswriter.cpp:28:
/usr/include/c++/11/string_view: In instantiation of 'class
std::basic_string_view >':
settingswriter.cpp:42:26: required from here
/usr/include/c++/11/string_view:98:21: error: static assertion failed
98 | static_assert(is_trivial_v<_CharT> &&
is_standard_layout_v<_CharT>);
| ^~~~
/usr/include/c++/11/string_view:98:21: note:
'std::is_trivial_v' evaluates to false
With the patch below the class should be trivial. However, if it has a
non-trivial copy assignment operator, that would explain why it's not
trivial.
Why is the copy assignment operator not trivial? That's what you need
to check.
make[2]: *** [Makefile:740: settingswriter.lo] Error 1
[1]
https://martinkg.fedorapeople.org/ErrorReports/cxxtools-2.2.1-25.fc33.src.rpm
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=60804463
I use the following patch for gcc11:
--- include/cxxtools/char.h.orig2021-01-28 10:15:36.017763265 +0100
+++ include/cxxtools/char.h 2021-01-28 10:16:14.833762026 +0100
@@ -68,9 +68,7 @@
typedef int32_t value_type;
//! Constructs a character with a value of 0.
-Char()
-: _value(0)
-{}
+Char() = default;
//! Constructs a character using the given char as base for
Re: Boost 1.75.0 in rawhide, with soname change
On 25. 01. 21 11:00, Jonathan Wakely wrote: Tom Rodgers completed the Boost 1.75.0 build for the change https://fedoraproject.org/wiki/Changes/F34Boost175 and I've rebuilt most of the packages that depend on it... Hello. I now see a strange build failure on a package that is not listed here, because it doe snot require boost on runtime, only build time. python-pynest2d FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=1922297 I see deprecation warnings like: CAUTION: Boost.Geometry in Boost 1.73 deprecates support for C++03 and will require C++14 from Boost 1.75 onwards. And than I see a lot of errors. Is it possible that the errors are relevant to that deprecation? The line is suspiciously in future tense, but this laready is Boost 1.75, right? -- 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
Test timeouts in Fedora Copr emulated envs
When we attempt to build libvirt in Copr, the test suite times out on s390 builds. IIUC, this is because s390 in Copr is using a QEMU emulated system, not native hardware, and thus is massively slower to execute. We don't want to bump up the default test suite timeout unconditonally, as that makes it slower to diagnose problems for the common case where the build env is not emulated. Is there a good way to detect that the build is in an emulated copr env rather than native. Does Copr / mock set any env variable to show that you're emulated ? I'm thinking this is not really a libvirt specific problem - any app using Meson is liable to hit the default test suite time limit if running in an emulated chroot, and thus will need to set --timeout-multiplier=10. So perhaps RPM's %meson_test macro should automatically include --timeout-multiplier=10 when running in an emulated world ? Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 34 Change: PostgreSQL 13 (Self-Contained Change)
> > Hmm, this sounds rather complicated and risky. > Do I get this right that postgresql will bundle a copy of libpq, > and a separate unbundled libpq will be provided? > > Why not just include a specific Requires on a specific version of > libpq? (Maybe something like > Requires:libpq(%_isa)>=x.y.z and libpq(%_isa) or whatever the best syntax is). > > There are plenty of packages which require some specific version of a > separately-packages library. We don't normally use bundling in such > cases. Since both packages are under the same maintainership, it > should be easy enough to keep them in sync. > The libpq library is part of the postgresql codebase. We have previously decided to separate it downstream and package it as a separate component. This means that different versions of postgresql are built modularly against a single non-modular libpq library. Upstream releases minor updates for all supported major version at once like this: 13.0 -> 13.1 12.4 -> 12.5 11.9 -> 11.10 10.14 -> 10.15 9.6.19 -> 9.6.20 9.5.23 -> 9.5.24 This means that to be able to rebase all postgresql streams (13,12,11,10,9.6) to their latest minor release versions, first we need to rebase the libpq library to the (in this case) 13.1 version. In that scenario, all streams except postgresql:13 are being built against different version of libpq, even though there is the correct libpq version in each postgresql source tarball for each stream, as libpq is part of its codebase. Historically, this way of packaging postgresql with separated libpq worked. However, upstream stated that they do not guarantee such compatibility, and postgresql was never intended to be built against external libpq. With the release version 13.1, we encountered some (thankfully) minor incompatibilities, causing us to patch downstream all streams up to postgresql:13. This new solution is not a classic bundle. It's a return to how postgresql is supposed to be built, while keeping a separate libpq package for users. Those bugs have a lot of detail... It seems that the only real solution > is to retroactively bump the so version. I couldn't figure out if that > is what happened upstream. > The only change here is the symbol version, as they are versioned downstream, and a mistake happened regarding that patch on rebase to the version 12.x. There is no upstream change, nor are any symbols actually being changed. -- Patrik Novotný Associate Software Engineer Red Hat panov...@redhat.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
Re: What is the most time consuming task for you as packager?
On Wed, 2020-12-30 at 14:41 -0800, Michel Alexandre Salim wrote:
> Howdy,
>
> On Sat, 2020-12-26 at 20:39 +, Sérgio Basto wrote:
> > Hi,
> > For me the most time consuming is monkey updates packages like kde
> > apps
> > , which every month or two we have a new release ( kde app 20.04.1
> > 20.04.2 20.08.0 , 20.12.00 etc )
> >
> > I did some scripts to automate my builds , we got some software
> > like
> > https://github.com/fedora-infra/the-new-hotness/
> > but the more I do, I always some variables that are different from
> > project to project , we need to know the version number, we may
> > need
> > to
> > download more than one source, we may need drop patches that we
> > know
> > that are already upstreamed, not all the package are build in same
> > branches so we need to know what branches we want update , we may
> > have
> > to add buildroot-overrides, we need add build to bodhi and fill
> > some
> > information , we need close bugs create made by hotness or other
> > users
> > etc
> >
> > Examples of my scripts are usually in packages sources like
> >
> > https://src.fedoraproject.org/rpms/virtualbox-guest-additions/blob/master/f/update_vbox.sh
> >
> >
> > or (in attachment) scripts in very quick-and-dirty style
> >
> > So, combine tools like rpmdevtools , the-new-hotness , bodhi-client
> > etc
> > we improve building automation .
> >
> My use case is similar: I comaintain a list of packages that Facebook
> open-sources that need to be rebuilt in step (since sadly ABI
> stability
> is not currently promised).
>
> I've cleaned-up my scripts:
> https://pagure.io/michel-slm/bulk-rebuild
>
> and blogged about them:
> https://michel-slm.name/posts/2020-12-30-fedora-bulk-rebuild/
>
> They mostly wrap around rpmdev-bumpspec, fedpkg, and bodhi right now.
>
> Curious to see how much can be factored out and shared among
> different
> packagers that perform similar tasks. e.g. I see the GNOME packagers
> doing bulk updates too.
>
> One observation (also in the post):
>
> The CLIs for fedpkg and koji is currently meant for human, not
> machine,
> consumptions. Invoking them from Bash scripts and trying to use the
> output (e.g. getting the name of that side tag) involves some brittle
> parsing. I plan to rewrite this in Python anyway, but it might be
> useful to add an output formatter to some commands where it makes
> sense
> (e.g. request-side-tag or chain-build).
I was looking at your scripts and I saw a reference to bodhi-cli,
yesterday I found out that fedpkg also has this option.
fedpkg update --help
usage: fedpkg update [-h] [--type
{bugfix,security,enhancement,newpackage}] [--request {testing,stable}]
[--bugs BUGS [BUGS ...]] [--notes NOTES]
[--disable-autokarma] [--stable-karma KARMA] [
--unstable-karma KARMA] [--not-close-bugs] [--suggest-reboot] [--no-
require-bugs]
[--no-require-testcases]
This will create a bodhi update request for the current package n-v-r.
There are two ways to specify update details. Without any argument from
command
line, either update type or notes is omitted, a template editor will be
shown
and let you edit the detail information interactively.
Alternatively, you could specify argument from command line to create
an update
directly, for example:
fedpkg update --type bugfix --notes 'Rebuilt' --bugs 1000 1002
When all lines in template editor are commented out or deleted, the
creation
process is aborted. If the template keeps unchanged, fedpkg continues
on creating
update. That gives user a chance to confirm the auto-generated notes
from
change log if option --notes is omitted.
optional arguments:
-h, --helpshow this help message and exit
--type {bugfix,security,enhancement,newpackage}
Update type. Template editor will be shown if
type is omitted.
--request {testing,stable}
Requested repository.
--bugs BUGS [BUGS ...]
Bug numbers. If omitted, bug numbers will be
extracted from change logs.
--notes NOTES Update description. Multiple lines of notes
could be specified. If omitted, template editor will be shown.
--disable-autokarma Karma automatism is enabled by default. Use
this option to disable that.
--stable-karma KARMA Stable karma. Default is 3.
--unstable-karma KARMA
Unstable karma. Default is -3.
--not-close-bugs By default, update will be created by enabling
to close bugs automatically. If this is what you do not want, use this
option to disable
the default behavior.
--suggest-reboot Suggest user to reboot after update. Default is
False.
--no-require-bugs Disables the requirement that all of the bugs
in your update have been confirmed by testers. Default is True.
--no-require-testcases
Disables the requirement that this update
passes all test cases before reaching stable. Default is True.
Re: Proposal to deprecated `fedpkg local`
On 29/01/21 14:56 +, Jonathan Wakely wrote: On 27/01/21 14:13 -0800, Josh Stone wrote: On 1/27/21 2:04 PM, Otto Urpelainen wrote: The other option of not using 'git add .' can also be described as mentally filtering out all the irrelevant unstaged changes to find the ones that should actually be added. That adds cognitive burden, slows things down and leads to mistakes every now and then. It does not help to say "do not make mistakes" if the task is inherently error-prone. Such filtering is something a computer should do, which leads us back to .gitignore. FWIW, 'git add -u' (--update) will limit you to files that are already part of the repo. You still need to pay attention if there really are new files though, like a new patch. 'git add .' is almost never right. Even if you don't use 'fedpkg local' you can still have unwanted files from other fedpkg commands like prep and mockbuild. Anybody who uses Git without modifying their shell prompt to display the status of the working tree when in a Git repo is either foolish or very brave (or just smart enough to run 'git status' *all* *the* *time*). It's not necessary to modify the .gitignore for every repo in dist-git, the 'fedpkg clone' command could be made to add the patterns to .git/info/exclude instead. That has the same effect as adding them to .gitignore but isn't committed to dist-git. One advantage of using .git/info/exclude is that the files are ignored on all branches, including historical ones. Adding new patterns to .gitignore will only have effect on the branches where you make those additions, and only from the point where they're added. Using .git/info/exclude means they're ignored if you check out an old branch like f31 or check out old commits for bisection. So if fedpkg clone just added things to .git/info/exclude there would be no need to modify every .gitignore file in every repo on every active branch. There could also be a 'fedpkg refresh' command that makes those .git/info/exclude changes to an existing clone. That refresh command could also add the local git pre-push hook being talked about in another thread. ___ 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 deprecated `fedpkg local`
On 27/01/21 14:13 -0800, Josh Stone wrote: On 1/27/21 2:04 PM, Otto Urpelainen wrote: The other option of not using 'git add .' can also be described as mentally filtering out all the irrelevant unstaged changes to find the ones that should actually be added. That adds cognitive burden, slows things down and leads to mistakes every now and then. It does not help to say "do not make mistakes" if the task is inherently error-prone. Such filtering is something a computer should do, which leads us back to .gitignore. FWIW, 'git add -u' (--update) will limit you to files that are already part of the repo. You still need to pay attention if there really are new files though, like a new patch. 'git add .' is almost never right. Even if you don't use 'fedpkg local' you can still have unwanted files from other fedpkg commands like prep and mockbuild. Anybody who uses Git without modifying their shell prompt to display the status of the working tree when in a Git repo is either foolish or very brave (or just smart enough to run 'git status' *all* *the* *time*). It's not necessary to modify the .gitignore for every repo in dist-git, the 'fedpkg clone' command could be made to add the patterns to .git/info/exclude instead. That has the same effect as adding them to .gitignore but isn't committed to dist-git. ___ 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: bootstrapping without .spec modification
On 29. 01. 21 15:02, Richard W.M. Jones wrote: On Fri, Jan 29, 2021 at 12:44:58PM +0100, Miro Hrončok wrote: For Koji, you cannot install arbitrary packages. What if instead, Koji allowed to set arbitrary macros on builds (and it keeps their definition for further reference). That way, you will be able to do: $ fedpkg build --with bootstrap $ koji wait-repo ... $ fedpkg build From the same commit. No package installation required. How would it "keep their definition"? It sounds like it could be a trap making it hard to understand how to reproduce a build issue / reproduce a build at all. Having said that, it's something I've wanted in the past and it'd be a nice feature. Currently a Koji task says: Source: git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b Build Target: f34-rebuild Options: fail_fast = True wait_builds = Example taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=60654655 With this feature, it would say: Source: git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b Build Target: f34-rebuild Options: fail_fast = True wait_builds = Macro overrides: _with_bootstrap: 1 And when reproducing, you'd just run the same command, e.g. $ koji build f34-rebuild --fail-fast --macro '_with_bootstrap 1' 'git+https://src.fedoraproject.org/rpms/python3.9.git#563b4f4b59a9f81095acfe30899fdc4b040c1b9b' The Koji web interface could even display the command. That's very much as reproduce as now. -- 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
[Bug 1922266] New: Please package perl-Moo for EL7
https://bugzilla.redhat.com/show_bug.cgi?id=1922266 Bug ID: 1922266 Summary: Please package perl-Moo for EL7 Product: Fedora EPEL Version: epel7 Status: NEW Component: perl-Moo Assignee: emman...@seyman.fr Reporter: clem.ou...@gmail.com QA Contact: extras...@fedoraproject.org CC: emman...@seyman.fr, iarn...@gmail.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Package perl-Moo is available for EL8 but is missing for EL7 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: bootstrapping without .spec modification
On Fri, Jan 29, 2021 at 7:33 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> Hello fellow packagers!
>
> The subject of bootstrapping came up on fedora-devel recently.
> I had the following idea, about which I would love to hear some feedback:
>
> == Problem:
> building packages with bootstrap currently involves doing *two*
> patches to the spec file: first to add '%global _without_bootstrap 1',
> then comes a rebuild, second to remove the macro, and then comes
> another rebuild.
>
> == Partial solution
> Let's have an rpm that provides a single file that sets the macro for us:
> $ rpm -qpl noarch/rpm-with-bootstrap-0-1.fc34.noarch.rpm
> /usr/lib/rpm/macros.d/macros.rpm-with-bootstrap
> $ cat rpm-macros-bootstrap/macros.rpm-with-bootstrap
> # Enable %%with_bootstrap for all builds
> %_with_bootstrap 1
For my experience, a boolean bootstrap macro is not enough
for bootstrapping the whole Feodra distribution. Especially for
cross-bootstrapping Fedora to a new architecture.
We may need a few bootstrap stages.
For each stage we can define different value for an rpm macro.
For example:
%define _bootstrap_stage 1
%define _bootstrap_stage 2
And the %_bootstrap or %bootstrap macro may have been used
by different packages for different semantics.
It is better to use a brand new macro for distribution bootstrap.
-robin
>
> Then we can do the following:
> $ rpmdev-bumpspec 'Do rebuild w/ bootstrap'
> $ mock -i rpm-with-bootstrap
> $ fedpkg mockbuild
> $ rpmdev-bumpspec 'Do rebuild w/o bootstrap'
> $ mock -i rpm-without-bootstrap [3]
> $ fedpkg mockbuild
> Voilà!
>
> The same pattern should work with side-tags in koji.
>
> I prepared a poc implementation in [1] which builds
> rpm-{with,without}-{bootstrap,tests,lto}, and a test package [2] which
> prints the values of %with_bootstrap, %with_tests, %with_lto.
>
> == Full solution
> If we have automatic version bumps, this would become even simpler:
> $ mock -i rpm-with-bootstrap
> $ fedpkg mockbuild
> $ mock --dnf-cmd remove rpm-with-bootstrap
> $ fedpkg mockbuild
>
> My idea would be to submit [1] for package-review so that it's
> generally available.
>
> Note that this works if the package we're building uses
> %bcond_with bootstrap
> or
> %bcond_without bootstrap
> I picked %{with bootstrap}, %{with lto}, %{with tests} as
> generally-useful settings. I think it is worth standarizing the names
> like this, and at least %{with bootstrap} and %{with tests} could be
> added to packaging guidelines.
>
> [1] https://pagure.io/rpm-macros-bootstrap
> [2] https://pagure.io/rpm-macros-test
> [3] rpm-without-bootstrap has Conflicts:rpm-with-bootstrap, so installing
> one forces the other out. Alternatively, rpm-with-bootstrap may just
> be uninstalled.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: bootstrapping without .spec modification
Dne 29. 01. 21 v 13:44 Miro Hrončok napsal(a): I'm confused. How is this different than: $ mock --with bootstrap ? mock --with bootstrap simply define bootstrap macro and build With the new option we can try to build **without* that macro, if the build fails then again **with* macro, and if it succeed then again **without** that macro. I guess it may be more useful together with --chain. -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bootstrapping without .spec modification
On Fri, Jan 29, 2021 at 12:44:58PM +0100, Miro Hrončok wrote: > For Koji, you cannot install arbitrary packages. > > What if instead, Koji allowed to set arbitrary macros on builds (and > it keeps their definition for further reference). That way, you will > be able to do: > > $ fedpkg build --with bootstrap > $ koji wait-repo ... > $ fedpkg build > > From the same commit. No package installation required. How would it "keep their definition"? It sounds like it could be a trap making it hard to understand how to reproduce a build issue / reproduce a build at all. Having said that, it's something I've wanted in the past and it'd be a nice feature. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: bootstrapping without .spec modification
On Fri, Jan 29, 2021 at 01:42:43PM +0100, Miro Hrončok wrote: > On 29. 01. 21 13:32, Zbigniew Jędrzejewski-Szmek wrote: > >On Fri, Jan 29, 2021 at 12:44:58PM +0100, Miro Hrončok wrote: > >>For Koji, you cannot install arbitrary packages. > >I thought we can tag packages into a side-tag? If the > >rpm-with-bootstrap was available as a normal package, it should > >be possible to tag the built rpms into the side-tag. > > Yes, but tagging makes them available, not installed. That kills my idea ;( Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20210129.n.0 changes
OLD: Fedora-Rawhide-20210128.n.0 NEW: Fedora-Rawhide-20210129.n.0 = SUMMARY = Added images:2 Dropped images: 1 Added packages: 1 Dropped packages:2 Upgraded packages: 160 Downgraded packages: 0 Size of added packages: 12.51 MiB Size of dropped packages:2.24 MiB Size of upgraded packages: 4.91 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -106.33 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20210129.n.0.iso Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20210129.n.0.iso = DROPPED IMAGES = Image: KDE_Appliance raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20210128.n.0-sda.raw.xz = ADDED PACKAGES = Package: golang-nanomsg-mangos-3-3.1.3-2.fc34 Summary: Golang implementation of nanomsg's "Scalablilty Protocols" RPMs:golang-nanomsg-mangos-3 golang-nanomsg-mangos-3-devel Size:12.51 MiB = DROPPED PACKAGES = Package: mozldap-6.0.5-28.fc33 Summary: Mozilla LDAP C SDK RPMs:mozldap mozldap-devel mozldap-tools Size:1.52 MiB Package: perl-Mozilla-LDAP-1.5.3-35.fc33 Summary: LDAP Perl module that wraps the OpenLDAP C SDK RPMs:perl-Mozilla-LDAP Size:731.33 KiB = UPGRADED PACKAGES = Package: HdrHistogram-2.1.12-1.fc34 Old package: HdrHistogram-2.1.11-6.fc33 Summary: A High Dynamic Range (HDR) Histogram RPMs: HdrHistogram HdrHistogram-javadoc Size: 582.72 KiB Size change: 86.48 KiB Changelog: * Mon Jan 25 2021 Fedora Release Engineering - 2.1.11-7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Thu Jan 28 2021 Alex Macdonald - 2.1.12-1 - Update to 2.1.12 Package: PDAL-2.2.0-5.fc34 Old package: PDAL-2.2.0-3.fc34 Summary: Point Data Abstraction Library RPMs: PDAL PDAL-devel PDAL-doc PDAL-libs Size: 57.59 MiB Size change: -4.55 MiB Changelog: * Fri Jan 22 2021 Jonathan Wakely - 2.2.0-4 - Rebuilt for Boost 1.75 * Mon Jan 25 2021 Fedora Release Engineering - 2.2.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Thu Jan 28 2021 Markus Neteler 2.2.0-6 - fix build with sphinxcontrib-bibtex 2.0 (RHBZ #1921498) Package: VirtualGL-2.6.5-1.fc34 Old package: VirtualGL-2.6.3-1.fc34 Summary: A toolkit for displaying OpenGL applications to thin clients RPMs: VirtualGL VirtualGL-devel Size: 4.72 MiB Size change: 53.85 KiB Changelog: * Mon Jan 25 2021 Fedora Release Engineering - 2.6.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Thu Jan 28 2021 Gary Gatling - 2.6.5-1 - Update to 2.6.5 Package: anaconda-34.21-1.fc34 Old package: anaconda-34.20-1.fc34 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 21.73 MiB Size change: -1.38 MiB Changelog: * Thu Jan 28 2021 Martin Kolman - 34.21-1 - Allow to disable the Security module (vponcova) - Add important files for container build to rebuild check (jkonecny) - Avoid using DockerHub because of limits (jkonecny) - anaconda should add only s390utils-core (dan) - Fix root password and LUKS passphrase visibility toggle (#1911360) (mkolman) - Fix the should_run methods of the network spoke (vponcova) - Prevent shell injection from a /kickstart-test comment (jkonecny) - network: validate bond options on our side after change in NM (#1918744) (rvykydal) - network: fix bond confiuration for empty bond options (#1918744) (rvykydal) - Allow to disable the Services module (vponcova) Package: awscli-1.18.221-1.fc34 Old package: awscli-1.18.220-1.fc34 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.95 MiB Size change: 305 B Changelog: * Thu Jan 28 2021 Gwyn Ciesla - 1.18.221-1 - 1.18.221 Package: bacula-11.0.0-4.fc34 Old package: bacula-11.0.0-2.fc34 Summary: Cross platform network backup for Linux, Unix, Mac and Windows RPMs: bacula-client bacula-common bacula-console bacula-console-bat bacula-devel bacula-director bacula-libs bacula-libs-sql bacula-logwatch bacula-storage bacula-traymonitor nagios-plugins-bacula Size: 26.89 MiB Size change: 13.93 KiB Changelog: * Tue Jan 26 2021 Fedora Release Engineering - 11.0.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Thu Jan 28 2021 Simone Caronni - 11.0.0-4 - Remove leftover ImageMagick build requirement. Package: bamf-0.5.5-1.fc34 Old package: bamf-0.5.4-5.fc33 Summary: Application matching framework RPMs: bamf bamf-daemon bamf-devel Size: 1.52 MiB Size change: -20.22 KiB Changelog: * Tue Jan 26 2
Re: Proposal to deprecated `fedpkg local`
Hi, please don't force me to change my workflow which I'm using regularly without having any benefit from it. -- Jan Horak On 1/27/21 5:17 PM, Vít Ondruch wrote: Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ 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 deprecated `fedpkg local`
Please no, I use that regularly. Martin On 1/27/21 5:17 PM, Vít Ondruch wrote: Hi, I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg local` command. I don't think it should be used. Mock should be the preferred way. Would there be anybody really missing this functionality? Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Martin Stransky Software Engineer / 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
Re: bootstrapping without .spec modification
On 29. 01. 21 13:32, Miroslav Suchý wrote: Dne 29. 01. 21 v 12:25 Zbigniew Jędrzejewski-Szmek napsal(a): $ mock -i rpm-with-bootstrap $ fedpkg mockbuild $ rpmdev-bumpspec 'Do rebuild w/o bootstrap' $ mock -i rpm-without-bootstrap [3] Or we can implement mock --try-bootstrap-macro I'm confused. How is this different than: $ mock --with bootstrap ? Which can set the bootstrap macro - that is much easier than having package which provides this macro. In fact it is already doable with -D option. When it will toggled using config_opts[] koji then can decide whether to use it or not. The only question is: how to call this config/cmdline option? Because we already use the term "bootstrap chroot" which can be confusing. -- 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: bootstrapping without .spec modification
On 29. 01. 21 13:33, Vít Ondruch wrote: And please also note, that you can use this for modules, where you can specify macros for specific module in modulemd file But that is in fact a "trick" because MSB creates a package and installs it into the buildroot. Koji has no knowledge about the macros. -- 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: bootstrapping without .spec modification
On 29. 01. 21 13:32, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Jan 29, 2021 at 12:44:58PM +0100, Miro Hrončok wrote: For Koji, you cannot install arbitrary packages. I thought we can tag packages into a side-tag? If the rpm-with-bootstrap was available as a normal package, it should be possible to tag the built rpms into the side-tag. Yes, but tagging makes them available, not installed. -- 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: bootstrapping without .spec modification
On 29. 01. 21 13:38, Daniel Mach wrote: * don't forget that NVR has to be unique in koji so you can't build the same build twice. Having an ability to set %dist via koji might be nice for bootstrapping. A bootstrap %bcond already amends dist to be .fc34~bootstrap when enabled. (The %bcond needs to be defined before Release: to have a different NEVR). -- 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: bootstrapping without .spec modification
On 1/29/21 12:44 PM, Miro Hrončok wrote:
On 29. 01. 21 12:25, Zbigniew Jędrzejewski-Szmek wrote:
Hello fellow packagers!
The subject of bootstrapping came up on fedora-devel recently.
I had the following idea, about which I would love to hear some feedback:
== Problem:
building packages with bootstrap currently involves doing *two*
patches to the spec file: first to add '%global _without_bootstrap 1',
then comes a rebuild, second to remove the macro, and then comes
another rebuild.
== Partial solution
Let's have an rpm that provides a single file that sets the macro for us:
$ rpm -qpl noarch/rpm-with-bootstrap-0-1.fc34.noarch.rpm
/usr/lib/rpm/macros.d/macros.rpm-with-bootstrap
$ cat rpm-macros-bootstrap/macros.rpm-with-bootstrap
# Enable %%with_bootstrap for all builds
%_with_bootstrap 1
Then we can do the following:
$ rpmdev-bumpspec 'Do rebuild w/ bootstrap'
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ rpmdev-bumpspec 'Do rebuild w/o bootstrap'
$ mock -i rpm-without-bootstrap [3]
$ fedpkg mockbuild
Voilà!
The same pattern should work with side-tags in koji.
I prepared a poc implementation in [1] which builds
rpm-{with,without}-{bootstrap,tests,lto}, and a test package [2] which
prints the values of %with_bootstrap, %with_tests, %with_lto.
== Full solution
If we have automatic version bumps, this would become even simpler:
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ mock --dnf-cmd remove rpm-with-bootstrap
$ fedpkg mockbuild
A more general note: Your examples involve mock, not Koji.
For mock, you can already do:
$ fedpkg mockbuild --with bootstrap
$ mock --install
$ fedpkg mockbuild
For Koji, you cannot install arbitrary packages.
What if instead, Koji allowed to set arbitrary macros on builds (and it
keeps their definition for further reference). That way, you will be
able to do:
$ fedpkg build --with bootstrap
$ koji wait-repo ...
$ fedpkg build
From the same commit. No package installation required.
Yes, defining rpm macros in koji would solve that for the build system.
I'd love to have the following features:
* general macros that are not package or arch specific (probably most of
them)
* per-(package,arch) macro overrides
* macro inheritance across koji tags
* don't forget that NVR has to be unique in koji so you can't build the
same build twice. Having an ability to set %dist via koji might be nice
for bootstrapping.
The downside is that anyone that is not using koji would have to
retrieve the macros from somewhere (export macros into a RPM file and
ship it as part of the release?). But that's only if the macros are used
for building production RPMs that land in Fedora repos. RPMs used for
bootstrapping don't have to be rebuildable outside the build system.
It seems to be related to this:
RFC: Feature macros (aka USE flags)
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4DWDPKYBOXTCGKXJTOIVPO34A5BTOE3T/
And it's also not far from defining build macros in modules:
https://docs.fedoraproject.org/en-US/modularity/building-modules/fedora/defining-modules/#_build_macros_optional
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1892743] Upgrade perl-Type-Tiny to 1.012001
https://bugzilla.redhat.com/show_bug.cgi?id=1892743 Jitka Plesnikova changed: What|Removed |Added Summary|Upgrade perl-Type-Tiny to |Upgrade perl-Type-Tiny to |1.012000|1.012001 --- Comment #1 from Jitka Plesnikova --- Latest Fedora delivers 1.010006 version. Upstream released 1.012001. When you have free time, please upgrade it. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: bootstrapping without .spec modification
Dne 29. 01. 21 v 12:44 Miro Hrončok napsal(a):
On 29. 01. 21 12:25, Zbigniew Jędrzejewski-Szmek wrote:
Hello fellow packagers!
The subject of bootstrapping came up on fedora-devel recently.
I had the following idea, about which I would love to hear some
feedback:
== Problem:
building packages with bootstrap currently involves doing *two*
patches to the spec file: first to add '%global _without_bootstrap 1',
then comes a rebuild, second to remove the macro, and then comes
another rebuild.
== Partial solution
Let's have an rpm that provides a single file that sets the macro for
us:
$ rpm -qpl noarch/rpm-with-bootstrap-0-1.fc34.noarch.rpm
/usr/lib/rpm/macros.d/macros.rpm-with-bootstrap
$ cat rpm-macros-bootstrap/macros.rpm-with-bootstrap
# Enable %%with_bootstrap for all builds
%_with_bootstrap 1
Then we can do the following:
$ rpmdev-bumpspec 'Do rebuild w/ bootstrap'
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ rpmdev-bumpspec 'Do rebuild w/o bootstrap'
$ mock -i rpm-without-bootstrap [3]
$ fedpkg mockbuild
Voilà!
The same pattern should work with side-tags in koji.
I prepared a poc implementation in [1] which builds
rpm-{with,without}-{bootstrap,tests,lto}, and a test package [2] which
prints the values of %with_bootstrap, %with_tests, %with_lto.
== Full solution
If we have automatic version bumps, this would become even simpler:
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ mock --dnf-cmd remove rpm-with-bootstrap
$ fedpkg mockbuild
A more general note: Your examples involve mock, not Koji.
For mock, you can already do:
$ fedpkg mockbuild --with bootstrap
$ mock --install
$ fedpkg mockbuild
For Koji, you cannot install arbitrary packages.
What if instead, Koji allowed to set arbitrary macros on builds (and
it keeps their definition for further reference).
https://pagure.io/koji/issue/416
https://pagure.io/koji/pull-request/898
And please also note, that you can use this for modules, where you can
specify macros for specific module in modulemd file.
Vít
That way, you will be able to do:
$ fedpkg build --with bootstrap
$ koji wait-repo ...
$ fedpkg build
From the same commit. No package installation required.
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bootstrapping without .spec modification
On Fri, Jan 29, 2021 at 12:44:58PM +0100, Miro Hrončok wrote: > For Koji, you cannot install arbitrary packages. I thought we can tag packages into a side-tag? If the rpm-with-bootstrap was available as a normal package, it should be possible to tag the built rpms into the side-tag. > What if instead, Koji allowed to set arbitrary macros on builds (and > it keeps their definition for further reference). That way, you will > be able to do: > > $ fedpkg build --with bootstrap > $ koji wait-repo ... > $ fedpkg build > > From the same commit. No package installation required. OK, that's be nicer then my idea. But it needs support from koji. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bootstrapping without .spec modification
Dne 29. 01. 21 v 12:25 Zbigniew Jędrzejewski-Szmek napsal(a): $ mock -i rpm-with-bootstrap $ fedpkg mockbuild $ rpmdev-bumpspec 'Do rebuild w/o bootstrap' $ mock -i rpm-without-bootstrap [3] Or we can implement mock --try-bootstrap-macro Which can set the bootstrap macro - that is much easier than having package which provides this macro. In fact it is already doable with -D option. When it will toggled using config_opts[] koji then can decide whether to use it or not. The only question is: how to call this config/cmdline option? Because we already use the term "bootstrap chroot" which can be confusing. -- Miroslav Suchy, RHCA Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: %bcond_with/%bcond_without
On 03. 04. 20 22:36, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 03, 2020 at 02:23:12PM -0400, Stephen Gallagher wrote:
Fabio Valenti made this comment in the FESCo ticket[1].
"Side note: I think more people would be amenable to including
"conditionals" into their packages if they weren't only shown off as
`%if eln this else that`. I think there's more value in doing "feature
flags" rather than conditionalize everything based on the `dist` tag,
for example something like this might even be useful in fedora
branches (e.g. for bootstrapping):
```spec
# at the top of the .spec file, where it's easily visible
%if 0%{?eln}
%bcond_with docs
%else
%bconf_without docs
%endif
# ...
%if %{with docs}
# do something
%endif
```
This makes conditionals (when they are necessary) much easier to
maintain (and understand), in my experience."
This is a side topic, and I didn't want to clutter the FESCo ticket
with that. But here we have threads, so I hope that you'll forgive me ;)
If find the %bcond_with/%bcond_without pattern abhorrent.
1. The logic is reversed: when I see "with" I think something is enabled,
when I see "without" I think something is disabled. But it's actually
the other way around here, which I find very confusing and often get
the condition reversed on the first try.
2. The value ('0%{?eln}') in this example is expressed before the name
('docs'), which is like saying 'value =: name'.
3. It takes five (!) lines to express the something that should be one
line.
So... could we please get a way to express this in rpm with a sane syntax:
%define_cond docs 0%{?fedora} > 0
(Naming and details of syntax are just examples, but the important
parts are: one line, name before value, positive logic).
A followup:
https://github.com/rpm-software-management/rpm/pull/1520
--
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
[Bug 1922014] perlbrew-0.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1922014 --- Comment #1 from Fedora Update System --- FEDORA-2021-8bdc43d5fc has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8bdc43d5fc -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1922014] perlbrew-0.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1922014 Jitka Plesnikova changed: What|Removed |Added Status|CLOSED |MODIFIED Resolution|RAWHIDE |--- Keywords||Reopened -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1922014] perlbrew-0.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1922014 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC|iarn...@gmail.com | Fixed In Version||perlbrew-0.90-1.fc34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2021-01-29 11:50:52 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: bootstrapping without .spec modification
On 29. 01. 21 12:25, Zbigniew Jędrzejewski-Szmek wrote:
Hello fellow packagers!
The subject of bootstrapping came up on fedora-devel recently.
I had the following idea, about which I would love to hear some feedback:
== Problem:
building packages with bootstrap currently involves doing *two*
patches to the spec file: first to add '%global _without_bootstrap 1',
then comes a rebuild, second to remove the macro, and then comes
another rebuild.
== Partial solution
Let's have an rpm that provides a single file that sets the macro for us:
$ rpm -qpl noarch/rpm-with-bootstrap-0-1.fc34.noarch.rpm
/usr/lib/rpm/macros.d/macros.rpm-with-bootstrap
$ cat rpm-macros-bootstrap/macros.rpm-with-bootstrap
# Enable %%with_bootstrap for all builds
%_with_bootstrap 1
Then we can do the following:
$ rpmdev-bumpspec 'Do rebuild w/ bootstrap'
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ rpmdev-bumpspec 'Do rebuild w/o bootstrap'
$ mock -i rpm-without-bootstrap [3]
$ fedpkg mockbuild
Voilà!
The same pattern should work with side-tags in koji.
I prepared a poc implementation in [1] which builds
rpm-{with,without}-{bootstrap,tests,lto}, and a test package [2] which
prints the values of %with_bootstrap, %with_tests, %with_lto.
== Full solution
If we have automatic version bumps, this would become even simpler:
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ mock --dnf-cmd remove rpm-with-bootstrap
$ fedpkg mockbuild
A more general note: Your examples involve mock, not Koji.
For mock, you can already do:
$ fedpkg mockbuild --with bootstrap
$ mock --install
$ fedpkg mockbuild
For Koji, you cannot install arbitrary packages.
What if instead, Koji allowed to set arbitrary macros on builds (and it keeps
their definition for further reference). That way, you will be able to do:
$ fedpkg build --with bootstrap
$ koji wait-repo ...
$ fedpkg build
From the same commit. No package installation required.
--
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: bootstrapping without .spec modification
On 29. 01. 21 12:25, Zbigniew Jędrzejewski-Szmek wrote:
Hello fellow packagers!
The subject of bootstrapping came up on fedora-devel recently.
I had the following idea, about which I would love to hear some feedback:
== Problem:
building packages with bootstrap currently involves doing *two*
patches to the spec file: first to add '%global _without_bootstrap 1',
then comes a rebuild, second to remove the macro, and then comes
another rebuild.
== Partial solution
Let's have an rpm that provides a single file that sets the macro for us:
$ rpm -qpl noarch/rpm-with-bootstrap-0-1.fc34.noarch.rpm
/usr/lib/rpm/macros.d/macros.rpm-with-bootstrap
$ cat rpm-macros-bootstrap/macros.rpm-with-bootstrap
# Enable %%with_bootstrap for all builds
%_with_bootstrap 1
Then we can do the following:
$ rpmdev-bumpspec 'Do rebuild w/ bootstrap'
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ rpmdev-bumpspec 'Do rebuild w/o bootstrap'
$ mock -i rpm-without-bootstrap [3]
$ fedpkg mockbuild
Voilà!
The same pattern should work with side-tags in koji.
I prepared a poc implementation in [1] which builds
rpm-{with,without}-{bootstrap,tests,lto}, and a test package [2] which
prints the values of %with_bootstrap, %with_tests, %with_lto.
Honestly, this feels very magical to me. Useful maybe, but I prefer to be
explicit in the spec.
OTOH if you disable tests like this, koschei will still build with tests, so
this is excellent for temporary tests disablement :)
== Full solution
If we have automatic version bumps, this would become even simpler:
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ mock --dnf-cmd remove rpm-with-bootstrap
$ fedpkg mockbuild
Not that %{with bootstrap} also mangles the dist tag (if defined before the
Release tag), so no bump needed already \o/
My idea would be to submit [1] for package-review so that it's
generally available.
Note that this works if the package we're building uses
%bcond_with bootstrap
or
%bcond_without bootstrap
I picked %{with bootstrap}, %{with lto}, %{with tests} as
generally-useful settings. I think it is worth standarizing the names
like this, and at least %{with bootstrap} and %{with tests} could be
added to packaging guidelines.
We have recently tried to standardize %{with tests} but there was some pushback.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/443LZIX4XLZL6NMF3M7HAGHKPNA4TRYN/
--
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
bootstrapping without .spec modification
Hello fellow packagers!
The subject of bootstrapping came up on fedora-devel recently.
I had the following idea, about which I would love to hear some feedback:
== Problem:
building packages with bootstrap currently involves doing *two*
patches to the spec file: first to add '%global _without_bootstrap 1',
then comes a rebuild, second to remove the macro, and then comes
another rebuild.
== Partial solution
Let's have an rpm that provides a single file that sets the macro for us:
$ rpm -qpl noarch/rpm-with-bootstrap-0-1.fc34.noarch.rpm
/usr/lib/rpm/macros.d/macros.rpm-with-bootstrap
$ cat rpm-macros-bootstrap/macros.rpm-with-bootstrap
# Enable %%with_bootstrap for all builds
%_with_bootstrap 1
Then we can do the following:
$ rpmdev-bumpspec 'Do rebuild w/ bootstrap'
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ rpmdev-bumpspec 'Do rebuild w/o bootstrap'
$ mock -i rpm-without-bootstrap [3]
$ fedpkg mockbuild
Voilà!
The same pattern should work with side-tags in koji.
I prepared a poc implementation in [1] which builds
rpm-{with,without}-{bootstrap,tests,lto}, and a test package [2] which
prints the values of %with_bootstrap, %with_tests, %with_lto.
== Full solution
If we have automatic version bumps, this would become even simpler:
$ mock -i rpm-with-bootstrap
$ fedpkg mockbuild
$ mock --dnf-cmd remove rpm-with-bootstrap
$ fedpkg mockbuild
My idea would be to submit [1] for package-review so that it's
generally available.
Note that this works if the package we're building uses
%bcond_with bootstrap
or
%bcond_without bootstrap
I picked %{with bootstrap}, %{with lto}, %{with tests} as
generally-useful settings. I think it is worth standarizing the names
like this, and at least %{with bootstrap} and %{with tests} could be
added to packaging guidelines.
[1] https://pagure.io/rpm-macros-bootstrap
[2] https://pagure.io/rpm-macros-test
[3] rpm-without-bootstrap has Conflicts:rpm-with-bootstrap, so installing
one forces the other out. Alternatively, rpm-with-bootstrap may just
be uninstalled.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: EPEL9 - thoughts and timings
On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote: > I think that could be workable, but I'll toss out another proposal: > > As soon as centos 9 stream exists, we create epel9-playground and allow > people to branch/add packages to it. Once rhel9 is GA, we setup epel9 as > usual and epel9-next and point epel9-next to build against stream and > playground to build against rhel9. > Do you know what CentOS 9 Stream will look like between its first availability and RHEL 9 GA? I worry that there will surface RHEL 9.1 changes. Then switching epel9-playground from CentOS 9 Stream to RHEL 9 could manifest incompatibilities as the build root would regress. -- Petr signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[Bug 1921785] perl-PPIx-Regexp-0.078 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1921785 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-PPIx-Regexp-0.078-1.fc ||34 Resolution|--- |RAWHIDE Last Closed||2021-01-29 10:05:42 --- Comment #1 from Petr Pisar --- An enhancement release suitable for Fedora ≥ 34. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
On Thu, Jan 28, 2021 at 02:20:09PM -0700, Chris Murphy wrote: > On Thu, Jan 28, 2021 at 2:08 PM Adam Williamson > wrote: > > > > On Thu, 2021-01-28 at 13:46 -0700, Chris Murphy wrote: > > > > > > OK I'm seeing this problem in a VM with > > > Fedora-Workstation-Live-x86_64-Rawhide-20210128.n.0.iso but I'm not > > > sure how consistent it is yet. MemTotal is ~3G for a VM that has 4G > > > allocated. Something's wrong... > > > > > > VM 5.11.0-0.rc5.20210127git2ab38c17aac1.136.fc34.x86_64 > > > [0.701792] Memory: 3016992K/4190656K available (43019K kernel > > > code, 11036K rwdata, 27184K rodata, 5036K init, 31780K bss, 1173408K > > > reserved, 0K cma-reserved) > > > > > > Baremetal 5.10.11-200.fc33.x86_64 > > > [0.125875] Memory: 12059084K/12493424K available (14345K kernel > > > code, 3465K rwdata, 9704K rodata, 2536K init, 5504K bss, 434080K > > > reserved, 0K cma-reserved) > > > > > > Why is reserved so much higher in the VM case? It clearly sees the 4G > > > but is delimiting it to 3G for some reason I don't understand. This is > > > well before the zram module is loaded, by the way. > > > > I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1921923 for > > this. zdzichu suggests https://lkml.org/lkml/2021/1/25/701 may be > > related. > > I'm not sure, because > Revert "mm: fix initialization of struct page for holes in memory layout" > landed in 5.10.11 and I wasn't have any of these memory related issues > with 5.10.10. I'm only seeing this so far with the debug kernels. Even > rc5 nodebug doesn't exhibit the problem. From https://lkml.org/lkml/2021/1/26/1215: > I ran just the revert of bde9cfa3afe4 through CI twice, on both > occasions all machines failed to boot. It seems that the revert is not enough. But it seems at this point that this is some kernel regression. I'll keep the fraxion bump in zram-generator-defaults for now. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
On Thu, Jan 28, 2021 at 08:12:58PM +0100, Kamil Dudka wrote: > I have never used `fedpkg local` myself. However, what prevents me from > doing > the following steps? > > $ fedpkg srpm > $ sudo yum builddep ... > $ rpmbuild --rebuild ... > $ sudo yum install ... fedpkg local sets the variables for rpmbuild to write artifacts to the CWD and subdirectories. rpmbuild writes to "global" directories under ~/rpmbuild, which many consider useless. > The above is my usual workflow when I debug something. Is it also going to > be > prohibited in some way? I'm sure that would never happen, even in the unlikely scenario that 'fedpkg local' was deprecated, since it's basic rpm functionality and the basis for how everything builds rpms. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
cxxtools-2.2.1 fails to compile on rawhide with gcc11 with /usr/include/c++/11/string_view:98:21: error: static assertion failed
Hi,
i am trying to compile cxxtools 2.2.1 [1] on Fedora 34 with gcc11 but this
fails with following error messages [2]
on Fedora build server.
make[2]: Entering directory '/builddir/build/BUILD/cxxtools-2.2.1/src'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../src
-I../include -I../include -Wno-long-long -Wall -pedantic -O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c -o
settingswriter.lo settingswriter.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../src -I../include -I../include
-Wno-long-long -Wall -pedantic -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -c
settingswriter.cpp -fPIC -DPIC -o .libs/settingswriter.o
In file included from settingswriter.h:31,
from settingswriter.cpp:28:
../include/cxxtools/char.h: In static member function 'static
std::char_traits::char_type*
std::char_traits::move(std::char_traits::char_type*,
const char_type*, std::char_traits::int_type)':
../include/cxxtools/char.h:337:80: warning: 'void* memmove(void*, const void*,
size_t)' writing to an object of type
'std::char_traits::char_type' {aka 'class cxxtools::Char'} with
no trivial copy-assignment; use copy-assignment or copy-initialization instead
[-Wclass-memaccess]
337 | return (cxxtools::Char*)std::memmove(s1, s2, n *
sizeof(cxxtools::Char));
|
^
In file included from settingswriter.h:31,
from settingswriter.cpp:28:
../include/cxxtools/char.h:65:11: note:
'std::char_traits::char_type' {aka 'class cxxtools::Char'}
declared here
65 | class Char
| ^~~~
In file included from settingswriter.h:31,
from settingswriter.cpp:28:
../include/cxxtools/char.h: In static member function 'static
std::char_traits::char_type*
std::char_traits::copy(std::char_traits::char_type*,
const char_type*, std::size_t)':
../include/cxxtools/char.h:344:79: warning: 'void* memcpy(void*, const void*,
size_t)' writing to an object of type
'std::char_traits::char_type' {aka 'class cxxtools::Char'} with
no trivial copy-assignment; use copy-assignment or copy-initialization instead
[-Wclass-memaccess]
344 | return (cxxtools::Char*)std::memcpy(s1, s2, n *
sizeof(cxxtools::Char));
|
^
In file included from settingswriter.h:31,
from settingswriter.cpp:28:
../include/cxxtools/char.h:65:11: note:
'std::char_traits::char_type' {aka 'class cxxtools::Char'}
declared here
65 | class Char
| ^~~~
In file included from /usr/include/c++/11/bits/basic_string.h:48,
from /usr/include/c++/11/string:55,
from ../include/cxxtools/char.h:32,
from settingswriter.h:31,
from settingswriter.cpp:28:
/usr/include/c++/11/string_view: In instantiation of 'class
std::basic_string_view >':
settingswriter.cpp:42:26: required from here
/usr/include/c++/11/string_view:98:21: error: static assertion failed
98 | static_assert(is_trivial_v<_CharT> &&
is_standard_layout_v<_CharT>);
| ^~~~
/usr/include/c++/11/string_view:98:21: note:
'std::is_trivial_v' evaluates to false
make[2]: *** [Makefile:740: settingswriter.lo] Error 1
[1]
https://martinkg.fedorapeople.org/ErrorReports/cxxtools-2.2.1-25.fc33.src.rpm
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=60804463
I use the following patch for gcc11:
--- include/cxxtools/char.h.orig2021-01-28 10:15:36.017763265 +0100
+++ include/cxxtools/char.h 2021-01-28 10:16:14.833762026 +0100
@@ -68,9 +68,7 @@
typedef int32_t value_type;
//! Constructs a character with a value of 0.
-Char()
-: _value(0)
-{}
+Char() = default;
//! Constructs a character using the given char as base for the
character value.
Char(char ch)
--- src/char.cpp.orig 2021-01-29 09:50:47.876669852 +0100
+++ src/char.cpp2021-01-29 09:51:37.747675779 +0100
@@ -140,7 +140,7 @@
cxxtools::Char ctype::do_widen(char ch) const
{
-return cxxtools::Char(ch);
+return cxxtools::Char(static_cast(ch));
}
but this patch didn't
[Bug 1921785] perl-PPIx-Regexp-0.078 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1921785 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1921955] perl-Test-Output-1.032 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1921955 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Output-1.03.2-1.f ||c34 Resolution|--- |RAWHIDE Last Closed||2021-01-29 09:06:50 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Proposal to deprecated `fedpkg local`
Dne 28. 01. 21 v 20:41 Richard Shaw napsal(a): 2/ Ambiguous build failure error message or segfault. Here I use the shell option to go into to chroot. It has some quirks as well. It drops you into the root so you have to do the whole cd builddir/build/BUILD/... or something like that (I'm at $DAYJOB right now). Could it not take you directly to the build dir? This is good point actually. I do this all the time. I have opened this upstream ticket: https://github.com/rpm-software-management/mock/issues/693 Also useful tools like vim or less need to be explicitly installed and often don't work exactly the same inside the chroot as they do outside. BUT it does allow you to interrogate/troubleshoot binaries and test, etc. While I typically tend to use editor from my host (I quite often use GVim or GEdit, which are both GUI editors), I stumble upon the missing `less` quite often. If there was way to somehow `mount` the editor from host into the buildroot, but I can't think of any feasible way :( I have already withdrew the original proposal, but that does not mean I am less concerned. I don't think it's a waste. I agree that we should encourage use of mock/fedpkg mockbuild in the documentation but we could also try to remove/reduce the reasons people use fedpkg local. Thank you Vít OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Help wanted] Setting vi/view/vim via alternatives
Hi all,
I'm currently trying to rewrite the current shell aliases for making
Vi/View/Vim use the correct compiled binary based on which Vim package
is installed. The current aliases have several downsides (don't work
with sudo, runs in subshell) so I got a recommendation for
'alternatives' which should solve all those issues.
But currently I'm stuck and I don't know how to debug - the current
patch (attached) should solve package installation, its upgrade and
removal via %post and %preun scriptlets, but whatever I do, the links
don't exist after package upgrade.
For debugging I used 'ls' in scriptlets, and the links existed at the
time the transaction was leaving the scriptlets. But the links don't
exist after the end of dnf transaction...
Would anyone mind helping me?
Thank you in advance,
Zdenek
--
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C
diff --git a/view_wrapper b/view_wrapper
new file mode 100644
index 000..f4c9b23
--- /dev/null
+++ b/view_wrapper
@@ -0,0 +1,3 @@
+#!/usr/bin/bash
+
+/usr/bin/vim -R "$@"
diff --git a/vim.csh b/vim.csh
deleted file mode 100644
index 47df221..000
--- a/vim.csh
+++ /dev/null
@@ -1,20 +0,0 @@
-# we need to use which twice - first for checking if
-# the command doesn't fail, the use it if doesn't fail
-set vim_cond = `command -v vim`
-set vi_cond = `command -v vi`
-
-switch ( $vim_cond-$vi_cond )
- case /usr/bin/vim-/usr/bin/vi:
- # apply only when founded vim and vi are in expected dirs from distro
- alias vi vim
- alias view 'vim -R'
- breaksw
- case -/usr/bin/vi:
- # apply only if founded vi is in expected dir from distro
- alias vim vi
- breaksw
-endsw
-
-# just in case
-unset vim_cond
-unset vi_cond
diff --git a/vim.fish b/vim.fish
deleted file mode 100644
index a35220d..000
--- a/vim.fish
+++ /dev/null
@@ -1,25 +0,0 @@
-# This will avoid user defined aliases and possibly stuff defined earlier in the PATH.
-# Redirecting is for the case when the binary is missing.
-set vim_cond (command -v vim)
-set vi_cond (command -v vi)
-
-switch "$vim_cond-$vi_cond"
- case /usr/bin/vim-/usr/bin/vi
- # apply only if founded vim and vi are in the expected dir from distro
- function vi
-command vim $argv
- end
-
- function view
-command vim -R $argv
- end
- case -/usr/bin/vi
- # apply only when no vim is installed and founded vi is in the expected dir from distro
- function vim
-command vi $argv
- end
-end
-
-# just in case
-set -e vim_cond
-set -e vi_cond
diff --git a/vim.sh b/vim.sh
deleted file mode 100644
index 2616693..000
--- a/vim.sh
+++ /dev/null
@@ -1,32 +0,0 @@
-__vi_internal_vim_alias()
-(
- # run vim if installed
- test -f /usr/bin/vim && exec /usr/bin/vim "$@"
-
- # run vi otherwise
- test -f /usr/bin/vi && exec /usr/bin/vi "$@"
-)
-
-__view_internal_vim_alias()
-(
- # run vim -R instead of view if vim installed
- test -f /usr/bin/vim && exec /usr/bin/vim -R "$@"
-
- # run view otherwise
- test -f /usr/bin/view && exec /usr/bin/view "$@"
-)
-
-
-if [ -n "${BASH_VERSION-}" -o -n "${KSH_VERSION-}" -o -n "${ZSH_VERSION-}" ]; then
- # This will avoid user defined aliases
- case "$(command -v vim)-$(command -v vi)" in
-"/usr/bin/vim-/usr/bin/vi" | "-/usr/bin/vi")
-# apply only when founded vim and vi are in expected dirs from distro
-# we need to call a shell function to avoid shell restarts when vi/vim
-# is being installed/uninstalled
-alias vi=__vi_internal_vim_alias
-alias view=__view_internal_vim_alias
-alias vim=__vi_internal_vim_alias
-;;
- esac
-fi
diff --git a/vim.spec b/vim.spec
index ce7d61b..3d02476 100644
--- a/vim.spec
+++ b/vim.spec
@@ -21,26 +21,26 @@ Summary: The VIM editor
URL: http://www.vim.org/
Name: vim
Version: %{baseversion}.%{patchlevel}
-Release: 2%{?dist}
+Release: 3%{?dist}
License: Vim and MIT
Source0: ftp://ftp.vim.org/pub/vim/unix/vim-%{baseversion}-%{patchlevel}.tar.bz2
-Source1: vim.sh
-Source2: vim.csh
-Source4: virc
-Source5: vimrc
-Source7: gvim16.png
-Source8: gvim32.png
-Source9: gvim48.png
-Source10: gvim64.png
+Source1: virc
+Source2: vimrc
+Source3: gvim16.png
+Source4: gvim32.png
+Source5: gvim48.png
+Source6: gvim64.png
+Source7: spec-template.new
+Source8: macros.vim
+Source9: vim-default-editor.sh
+Source10: vim-default-editor.csh
+Source11: vim-default-editor.fish
+Source12: view_wrapper
+
%if %{withvimspell}
-Source13: vim-spell-files.tar.bz2
+Source100: vim-spell-files.tar.bz2
%endif
-Source14: spec-template.new
-Source15: macros.vim
-Source16: vim-default-editor.sh
-Source17: vim-default-editor.csh
-Source18: vim-default-editor.fish
-Source19: vim.fish
+
Patch2002: vim-7.0-fixkeys.patch
Patch2003: vim-7.4-specsyntax.patch
@@ -130,6 +130,8 @@ Conflicts: %{name}-common < %{epoch}:8.1.1-1
Conflicts: vim-enhanced < 2:8.2.2146-2
Provides: vi
Provides: %{_bindir}/vi
+# needs alternatives for post and
Re: Fedora 34 Change: Scale ZRAM to Full Memory Size — arbitrary scaling
* Alexander Bokovoy: > This is a good note. If zram breaks kernel API promise to user space > (/proc/meminfo is one such API), how can it be enabled by default. I > also would question enabling zram by default if it does not play along > with cgroups. We do depend on cgroups being properly managed by systemd, > including resource allocation. But that's impossible: The existing interfaces assume that there's no RAM compression (or tiers of swap), so something has to give. As these reported numbers are used for auto-sizing heaps and caches, there have to be heuristics that happen to work for the majority of cases. (Similar to what file systems do if they allocate inodes dynamically, but still have to synthesize a reasonable-looking maximum to satisfy the POSIX statvfs interface constraints.) The alternative would be to come up with entirely new interfaces. The container side of things did that, and from that perspective, anything reading /proc/meminfo is already broken and needs to transition to the new interfaces. But that Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
