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://op
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 missi
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 operations
* 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 --arc
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 vers
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:
> >
> > https://src.fedoraproject.org/rpms/yosys/c/ff37aa8a48b430546f4831ece89896cccfe7b1a1?bran
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.
Th
> * 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 th
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:
https://docs.fedoraproject
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 pe
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 befo
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 Me
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 i
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
`/usr/share/an
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
leave
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 bu
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, probabl
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 devel-le...@lists
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. Tested
* 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 P
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 (vit...@easycoding.or
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 system
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 ca
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 for
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 tha
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 dl
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 all
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 s
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.
--
Sincerely
* 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
> https://bugzilla.redha
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 intend
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 AM,
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 pyth
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
https://bugzilla.redhat.com/show_bug.c
> 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 python3-dmidec
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://src.fedoraproject.org/rpms/ogre/pull-reque
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 reli
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. Repo
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
"--whatrequires
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 JACK
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: https://op
45 matches
Mail list logo
