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
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
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,
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
https://bugzilla.redhat.com/show_bug.cgi?id=1922014
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from
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
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:
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
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
>
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
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
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
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
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:
>
>
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
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 :)
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
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
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
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
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
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
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
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
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
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
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:
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:
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/
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
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
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
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/
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
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
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
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
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,
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
>
> 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
>
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
> >
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
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
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
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
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
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,
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1922014
Jitka Plesnikova changed:
What|Removed |Added
Status|CLOSED |MODIFIED
Resolution|RAWHIDE
https://bugzilla.redhat.com/show_bug.cgi?id=1922014
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
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*
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*
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1921785
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1921785
Petr Pisar changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://bugzilla.redhat.com/show_bug.cgi?id=1921955
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
Fixed In Version|
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
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
* 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
78 matches
Mail list logo
