No missing expected images.
Soft failed openQA tests: 1/7 (x86_64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-32-20200826.0):
ID: 649130 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproj
Hi Jonathan,
As per the below guidelines I tried the below steps but iam getting the
below error when I run fedpkg scratch-build --srpm.
And how can I see the error logs?
Could you please let me know what went wrong.
fedpkg clone fctxpd
cd fctxpd
edited the spec file
fedpkg srpm
fedpkg scratch-
Take a look at build.log that is available at provided koji URL.
/var/tmp/rpm-tmp.0K14Wz: line 39: cd:
bsn-fc-txptd-ccbaf3a0cbadaaef727bcb53c1ac543fa049: No such file or directory
That's the reason of your build failure.
Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
Hi Josey,
But the src.rpm has a fctxpd-ccbaf3a.tar.gz and fctxpd.spec.
And when we extract fctxpd-ccbaf3a.tar.gz it has
bsn-fc-txpd-ccbaf3a0cbadaaef727bcb53c1ac543fa049.
Can you please let me know whether iam missing something.
And how did u see the below error.
/var/tmp/rpm-tmp.0K14Wz: l
No missing expected images.
Passed openQA tests: 7/7 (x86_64)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorap
Hi Josey,
Thanks for pointing out the issue.
I fixed the issue and it build successfully.
Thanks for your quick help.
Regards,
Muneendra.
-Original Message-
From: Muneendra Kumar M [mailto:muneendra.ku...@broadcom.com]
Sent: Thursday, August 27, 2020 3:50 PM
To: 'Josef Ridky' ; 'Developme
fedpkg provided you task URL, where you can find all logs related to current
build.
In your case, taks URL is
https://koji.fedoraproject.org/koji/taskinfo?taskID=50235166
Under this URL, you find links to sub-builds of your package (sub-build mean
your package built for specific architecture -
Hi Josey,
Thanks for sharing the info and I was able to fix the issue and upgrade the
package to FC34.
How do I upgrade my package to EPEL 7 and EPEL 8 which still has old version
of package(fctxpd-0.1-1.20190813gitc195e67.el8).
Any help here will be great.
Release Stable versionFedora
3
Hi Josey,
Will the below steps work to upgrade the package for epel7.
Please let me know if there is any issue.
fedpkg clone fctxpd
cd fctxpd/
git branch
fedpkg switch-branch epel7
git branch
git merge master
fedpkg push
fedpkg build
Regards,
Muneendra.
-Original Message-
From: Muneendra K
In theory, it should be fine, but opinion from someone, who works with epel
regularly would be better.
Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.
- Original Message -
| From: "Muneendra Kumar M via devel"
| To: "Josef Ridky"
| Cc: "Development discussions re
Hi folks,
I've run into the compilation problem in the Galera package
This problem occurs only on f33 and higher tho.
Here is build performed on Fedora 32:
https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504
And here is the same build, but on Fedora 33:
https://koji.fedoraproject.org/ko
On 27.08.20 13:27, Muneendra Kumar M via devel wrote:
> Hi Josey,
> Will the below steps work to upgrade the package for epel7.
Epel works just like any other Fedora branch, so unless there are
differences in dependencies on CentOS/RHEL vs Fedora (doesn't seem to be
the case, as you already have t
On Thu, 27 Aug 2020 14:21:03 +0200
Lukas Javorsky wrote:
> Hi folks,
>
> I've run into the compilation problem in the Galera package
> This problem occurs only on f33 and higher tho.
>
> Here is build performed on Fedora 32:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504
>
> An
On Thu, 27 Aug 2020 14:21:03 +0200
Lukas Javorsky wrote:
> Hi folks,
>
> I've run into the compilation problem in the Galera package
> This problem occurs only on f33 and higher tho.
>
> Here is build performed on Fedora 32:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504
>
> An
On Thu, Aug 27, 2020 at 02:21:03PM +0200, Lukas Javorsky wrote:
> I've run into the compilation problem in the Galera package
> This problem occurs only on f33 and higher tho.
>
> Here is build performed on Fedora 32:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504
>
> And here is
On Wed, Aug 26, 2020 at 1:53 PM kevin wrote:
>
> On Wed, Aug 26, 2020 at 07:18:49PM +0200, Fabio Valentini wrote:
> >
> > Hrm. It looks like at least some of those issues were transient, yes.
> > However, two issues are still left:
> >
> > - libdkimpp-2.0.0-6.fc33 is tagged with f33 and f34 but 2.
On Thu, Aug 27, 2020 at 9:42 AM Mohan Boddu wrote:
>
> On Wed, Aug 26, 2020 at 1:53 PM kevin wrote:
> >
> > On Wed, Aug 26, 2020 at 07:18:49PM +0200, Fabio Valentini wrote:
> > >
> > > Hrm. It looks like at least some of those issues were transient, yes.
> > > However, two issues are still left:
https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names
== Summary ==
Use CPython upstream architecture naming in Fedora's Python ecosystem
(mostly in filenames) instead of the previously patched Fedora names.
For example, have
/usr/lib64/python3.9/lib-dynload/array.cpython-39-po
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
== Summary ==
Improve compression ratio of SquashFS filesystem on the installation media.
== Owner ==
* Name: [[User:bkhomuts|Bohdan Khomutskyi]]
* Email: bkhom...@redhat.com
== Detailed Description ==
As of Fedora 31, the LiveOS/squashfs.
On Thu, 2020-08-27 at 14:21 +0200, Lukas Javorsky wrote:
> Hi folks,
>
> I've run into the compilation problem in the Galera package
> This problem occurs only on f33 and higher tho.
>
> Here is build performed on Fedora 32:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=50232504
>
> An
On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson
wrote:
>
> Basic networking
>
> It must be possible to establish both IPv4 and IPv6 network connections
> using DHCP and static addressing. The default network configuration
> tools for the console and for release-blocking desktops must wor
On Wed, 2020-08-26 at 19:07 -0700, Erich Eickmeyer wrote:
> HI all,
>
> Since the release of Koji 1.22, there has been a bug [1] blocking any
> Fedora Jam 33 or Rawhide iso images from being spun. As you can imagine,
> this is making me quite nervous. As it turns out, I'm waiting for Koji
> 1.2
Hi Adam,
On 8/27/20 2:18 PM, Adam Williamson wrote:
Unfortunately, as Jam isn't a release-blocking image, it can't by
definition block the Beta release. Even if it doesn't build at all.
As Neal suggested, I'd recommend requesting the fix be backported to
our Koji by filing a ticket with the inf
On Thu, 2020-08-27 at 11:13 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
>
> == Summary ==
> Improve compression ratio of SquashFS filesystem on the installation
> media.
>
...
>
> Based on the results above, I'd suggest selecting the following
> ''optimal c
OLD: Fedora-33-20200826.n.0
NEW: Fedora-33-20200827.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 1
Dropped packages:5
Upgraded packages: 3
Downgraded packages: 0
Size of added packages: 114.10 MiB
Size of dropped packages:5.95 MiB
Size
No missing expected images.
Failed openQA tests: 9/181 (x86_64)
New failures (same test not failed in Fedora-33-20200826.n.0):
ID: 649776 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/649776
Old failures (same test failed in Fedora-33
'It's a trap!' :D
On 8/27/20 5:13 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Python_Upstream_Architecture_Names
>
> == Summary ==
> Use CPython upstream architecture naming in Fedora's Python ecosystem
> (mostly in filenames) instead of the previously patched Fedora names.
> F
All,
The below question came up in the context of a LibreOffice unit test,
where LibreOffice writes out a PNG image (involving zlib for
compression) and the test checked the exact sequence of bytes, which
failed on aarch64 when using Fedora's zlib. (Though the resulting
images look rather id
Hello Fedorans, Bastien,
I have noticed that the shared-mime-info package was orphaned couple days ago.
Bastien, AFAIK you were the primary point of contact in Fedora and I also see
you are the RHEL 8 default bugzilla assignee.
Considering the following commit:
https://gitlab.freedesktop.org
29 matches
Mail list logo
