No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-33-20201125.0):
ID: 729000 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL:
https://fedorapeople.org/groups/389ds/ci/nightly/2020/11/26/report-389-ds-base-2.0.1-20201126gitce7beae.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
On 2020-11-25 6:18 a.m., Wim Taymans wrote:
So, the current sentiment is:
* provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
That will be great as a lab suite maintainer. pipewire-pulse is
currently
Hi all,
Can people please review a few python packages for me? These should be
relatively straightforward.
* dependencies for spyder
pyls_black - https://bugzilla.redhat.com/show_bug.cgi?id=1901757
pyls-spyder - https://bugzilla.redhat.com/show_bug.cgi?id=1901758
* dependency for nbconvert
It would be nice to have a version of tortoisehg to go with it. Currently
I've tried thg-5.6 built as:
pip install --user tortoisehg-5.6.tar.gz
And using mercurial-5.6 installed as
pip install --user --upgrade mercurial (IIRC)
And using system versions of PyQt etc. It segfaults on many
https://github.com/389ds/389-ds-base/pull/4463
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
https://fedorapeople.org/groups/389ds/ci/nightly/2020/11/25/report-389-ds-base-2.0.1-20201125git8bb2f6b.fc33.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
* Gabriel L. Somlo:
> Hi Florian,
>
> On Wed, Nov 25, 2020 at 02:12:09PM +0100, Florian Weimer wrote:
>> A mock configuration for eln-build-side-32479 should have it. This
>> generated configuration looks reasonable, but I haven't tried it:
>>
>> mock-config --target=eln-build-side-32479
On Wed, Nov 25, 2020 at 7:39 PM Jerry James wrote:
>
> Sorry for the late reply.
>
> On Thu, Nov 19, 2020 at 2:25 AM Mikolaj Izdebski wrote:
> > This warning is relevant for upstream projects, but you can safely
> > ignore it when building RPM packages with XMvn - it always uses
> > packaged
Hi Florian,
On Wed, Nov 25, 2020 at 02:12:09PM +0100, Florian Weimer wrote:
> A mock configuration for eln-build-side-32479 should have it. This
> generated configuration looks reasonable, but I haven't tried it:
>
> mock-config --target=eln-build-side-32479 --arch=x86_64
Which version of (I
On Wed, Nov 25, 2020 at 11:21:21AM -0700, Jeff Law wrote:
>
>
> On 11/25/20 5:41 AM, Gabriel L. Somlo wrote:
> > Hi,
> >
> > Someone dropped a gcc-11 specific patch into a package I
> > (co-)maintain:
> >
> >
Sorry for the late reply.
On Thu, Nov 19, 2020 at 2:25 AM Mikolaj Izdebski wrote:
> This warning is relevant for upstream projects, but you can safely
> ignore it when building RPM packages with XMvn - it always uses
> packaged versions of Maven plugins, ignoring versions configured in
> POM.
> * re-evaluate situation for f35 beta freeze to make a default switch.
>
> Although a bit slower than expected, I guess more testing is good. It sounds
> like an acceptable plan to me.
> I'm not sure how it works, if spinoffs can/want to make an earlier switch?
I feel that based on testing if
I can confirm that this works great. I've used it with BlueJeans without issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
On Wed, Nov 25, 2020 at 7:01 PM Kevin Fenzi wrote:
> I don't think we need to go this slow, unless we run into problems...
>
> If we run into problems in f34, we can just revert and try again for
> f35. Of course that does assume that it's made easy to switch the
> default back.
>
> So, for me
On 11/25/20 5:41 AM, Gabriel L. Somlo wrote:
> Hi,
>
> Someone dropped a gcc-11 specific patch into a package I
> (co-)maintain:
>
> https://src.fedoraproject.org/rpms/yosys/c/ff37aa8a48b430546f4831ece89896cccfe7b1a1?branch=master
>
> which really rather belongs upstream. I'd like to test it
On Wed, Nov 25, 2020 at 02:18:45PM -, Wim Taymans wrote:
> So, the current sentiment is:
Well, of a few folks. :)
> * provide an easy way to test in f33, either copr or with regular packages.
>- rawhide is a not a good place to get good testing anyway
It's likely more limited than f33
On 11/25/20 5:56 PM, Miro Hrončok wrote:
On 11/25/20 5:15 PM, Ondrej Pohorelsky wrote:
We are working on dropping Python 2 version of Mercurial in Fedora[0] entirely.
Hurray \o/
Currently there is a working version of Mercurial 5.6 in COPR[1] that
needs further testing. If anyone who uses
On 11/25/20 5:15 PM, Ondrej Pohorelsky wrote:
We are working on dropping Python 2 version of Mercurial in Fedora[0] entirely.
Hurray \o/
Currently there is a working version of Mercurial 5.6 in COPR[1] that
needs further testing. If anyone who uses Mercurial would be able to
test it and give
We are working on dropping Python 2 version of Mercurial in Fedora[0] entirely.
Currently there is a working version of Mercurial 5.6 in COPR[1] that
needs further testing. If anyone who uses Mercurial would be able to
test it and give me some feedback, I would be glad!
Also there is a question
Hello!
we recently merged [1] a development version of ansible module for
enabling copr repositories. At this moment we would like to get your
early feedback - before we submit this to Galaxy, or propose this as
ansible core library.
Quick howto. Either copy the copr.py file into
Hello, the python-mongoquery package is now orphaned, our group doesn't
need it anymore. It doesn't seem to be required by any other package. If
python-mongoquery is useful to you, feel free to take it:
https://src.fedoraproject.org/rpms/python-mongoquery
Cheers,
Kamil
On 11/25/20 8:18 AM, Wim Taymans wrote:
So, the current sentiment is:
* provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
* encourage people to test. Provide instructions on how to do this and how to
On ke, 25 marras 2020, Tomáš Popela wrote:
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy
wrote:
Screencasting still does not work in Fedora 33. It pretends to work as
in claiming through the applications and GNOME indicators that the
screen / application window / browser tabs are shared
On Wed, Nov 25, 2020 at 2:29 PM Josef Skladanka wrote:
> > Orphaning python-mongoquery and retiring everything else makes sense to
> > me.
> >
> > Tim
>
> +1
>
OK, I'll make it happen.
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To
So, the current sentiment is:
* provide an easy way to test in f33, either copr or with regular packages.
- rawhide is a not a good place to get good testing anyway
* encourage people to test. Provide instructions on how to do this and how to
leave feedback.
* Carry this over to f34,
FESCo meeting today is cancelled. There is no agenda and Thanksgiving in the US
is tomorrow.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Wed, Nov 25, 2020 at 1:51 PM Alexander Bokovoy
wrote:
> Screencasting still does not work in Fedora 33. It pretends to work as
> in claiming through the applications and GNOME indicators that the
> screen / application window / browser tabs are shared but nothing gets
> actually shared.
On Mon, Nov 23, 2020 at 7:11 PM Tim Flink wrote:
>
> On Thu, 12 Nov 2020 18:25:17 +0100
> Kamil Paral wrote:
>
> > Note: The email subject should have said "retiring" instead of
> > "orphaning". There is little reason to orphan them, retiring is the
> > right approach here. Perhaps except for
* Gabriel L. Somlo:
> Hi,
>
> Someone dropped a gcc-11 specific patch into a package I
> (co-)maintain:
>
> https://src.fedoraproject.org/rpms/yosys/c/ff37aa8a48b430546f4831ece89896cccfe7b1a1?branch=master
>
> which really rather belongs upstream. I'd like to test it before
> pushing an upstream
On 25.11.2020 13:36, Neal Gompa wrote:
We don't use API shims anymore for PulseAudio, we now replace the
daemon and reuse the original PulseAudio libraries.
This is not a complete replacement now. Running another daemon is not
good for me.
--
Sincerely,
Vitaly Zaitsev
On Wed, Nov 25, 2020 at 7:49 AM Alexander Bokovoy wrote:
>
> On ke, 25 marras 2020, Wim Taymans wrote:
> >Hi all,
> >
> >First of all, thanks for the comments, keep them coming. We have seen
> >these concerns many times before with big infrastructure changes like
> >pulseaudio or wayland or
On ke, 25 marras 2020, Wim Taymans wrote:
Hi all,
First of all, thanks for the comments, keep them coming. We have seen
these concerns many times before with big infrastructure changes like
pulseaudio or wayland or systemd. I think they are necessary to keep
our feet on the ground and not get
Hi,
Someone dropped a gcc-11 specific patch into a package I
(co-)maintain:
https://src.fedoraproject.org/rpms/yosys/c/ff37aa8a48b430546f4831ece89896cccfe7b1a1?branch=master
which really rather belongs upstream. I'd like to test it before
pushing an upstream PR myself, but a cursory googling
On Wed, Nov 25, 2020 at 6:06 AM Vitaly Zaitsev via devel
wrote:
>
> On 24.11.2020 21:34, Neal Gompa wrote:
> > The packaging for PipeWire has been changing rapidly as the API shims
> > for PulseAudio changed from libraries to a replacement daemon, that's
> > why this is broken again.
>
> I see
https://bugzilla.redhat.com/show_bug.cgi?id=1900710
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from
On 24.11.2020 21:34, Neal Gompa wrote:
The packaging for PipeWire has been changing rapidly as the API shims
for PulseAudio changed from libraries to a replacement daemon, that's
why this is broken again.
I see that they removed[1] the API shims. What about applications that
require or even
On 24.11.2020 22:33, Kevin Fenzi wrote:
Additionally, since it's a big change with a wide amount of workflows
and hardware and users expected, thats another reason to accept the
change for f34. It will then get testing up until the beta freeze... if
it's not ready then, it can be moved to f35
On 25/11/2020 10:47, Wim Taymans wrote:
but I don't want to test all this
This is ok, I can understand that you don't want to deal with possible audio
problems. You
will have to install pulseaudio again and opt out. You will have to hope that
other people
do sufficient testing. It is a bit
On 24.11.2020 22:29, Kevin Fenzi wrote:
Barely over a month? I guess you are dropping all of this month, next
month and january? That seems a bit unfair.
Yes. We need at least 1 full Fedora release to test everything on real
hardware. Optional PipeWire in F34 and default in F35.
--
* Jan Pazdziora:
> it seems that both fakeroot and fakechroot fail to build in Fedora
> rawhide (at least partially) because _STAT_VER is no longer declared
> in the current glibc (or rather, its headers):
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1889862
>
Hi all,
First of all, thanks for the comments, keep them coming. We have seen these
concerns many times
before with big infrastructure changes like pulseaudio or wayland or systemd. I
think they are
necessary to keep our feet on the ground and not get carried away by our pipe
dreams (pun
https://bugzilla.redhat.com/show_bug.cgi?id=1891478
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
https://bugzilla.redhat.com/show_bug.cgi?id=1772783
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
On Wed, 25 Nov 2020 11:34:37 +0100
"Antonio T. sagitter" wrote:
> Is upstream still active?
I would call it "they are alive", there were commits few months ago,
see https://github.com/nima/python-dmidecode
Dan
> On 25/11/20 10:56, Miro Hrončok wrote:
> > On 11/25/20 10:43
Is upstream still active?
On 25/11/20 10:56, Miro Hrončok wrote:
On 11/25/20 10:43 AM, Dan Horák wrote:
Hi all,
I'm orphaning python-dmidecode, I have inherited it after a member of
our team left and have no interest or use case for it. I vaguely
remember there was a project who relied on
Hello,
it seems that both fakeroot and fakechroot fail to build in Fedora
rawhide (at least partially) because _STAT_VER is no longer declared
in the current glibc (or rather, its headers):
https://bugzilla.redhat.com/show_bug.cgi?id=1889862
> On Wed, 25 Nov 2020 10:56:39 +0100
> > It returns subscription-manager:
> >
> > $ repoquery --repo=rawhide{,-source} --whatrequires python3-dmidecode
> > subscription-manager-0:1.29.0-1.fc34.x86_64
There is also a weak dependency in tuned:
# repoquery --repo=rawhide --whatdepends
On Tue, 2020-11-24 at 09:51 +, Sérgio Basto wrote:
> On Tue, 2020-11-24 at 10:25 +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 11/23/20 3:56 PM, Sérgio Basto wrote:
> > > Sorry ,
> > > I updated ogre in rawhide to ogre-1.12.6 ( the PR
> > >
https://bugzilla.redhat.com/show_bug.cgi?id=1901409
Jitka Plesnikova changed:
What|Removed |Added
Status|ASSIGNED|CLOSED
On Wed, 25 Nov 2020 10:56:39 +0100
Miro Hrončok wrote:
> On 11/25/20 10:43 AM, Dan Horák wrote:
> > Hi all,
> >
> > I'm orphaning python-dmidecode, I have inherited it after a member of
> > our team left and have no interest or use case for it. I vaguely
> > remember there was a project who
On 11/25/20 10:43 AM, Dan Horák wrote:
Hi all,
I'm orphaning python-dmidecode, I have inherited it after a member of
our team left and have no interest or use case for it. I vaguely
remember there was a project who relied on python-dmidecode, so if it's
still true, then they should step up.
Hi all,
I'm orphaning python-dmidecode, I have inherited it after a member of
our team left and have no interest or use case for it. I vaguely
remember there was a project who relied on python-dmidecode, so if it's
still true, then they should step up. Repoquery returns nothing for
https://bugzilla.redhat.com/show_bug.cgi?id=1901409
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |ASSIGNED
Doc Type|---
On 11/24/20 9:17 PM, Neal Gompa wrote:
On Tue, Nov 24, 2020 at 2:07 PM Joël Krähemann wrote:
That being said, I have spoken to a few audio engineers, and basically
none of them use ALSA directly. They can't because ALSA doesn't
support mixing properly, among other things. Most of them use
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-32-20201124.0):
ID: 728703 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL:
56 matches
Mail list logo
