On Friday, August 28, 2020 9:55:18 PM MST drago01 wrote:
> On Saturday, August 29, 2020, John M. Harris Jr
>
> wrote:
> > On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
> > > On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
> > >
> > > wrote:
> > > > Zbigniew, do you agree
On Saturday, August 29, 2020, John M. Harris Jr
wrote:
> On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
> > On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
> > wrote:
> >
> > > Zbigniew, do you agree that we should remove the script if and only
> > > if it is generated by N
On Monday, August 10, 2020 9:52:42 AM MST Michael Catanzaro wrote:
> On Tue, Aug 4, 2020 at 9:08 am, Michael Catanzaro
> wrote:
>
> > Zbigniew, do you agree that we should remove the script if and only
> > if it is generated by NetworkManager? Otherwise, the change is only
> > partially-implem
On Tuesday, August 4, 2020 9:32:35 AM MST Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Aug 04, 2020 at 05:11:49PM +0200, Miroslav Lichvar wrote:
>
> > I'm considering to split the default configuration file in the chrony
> > package to make it easier for vendors, products, and configuration
> > to
On Fri, 2020-08-28 at 18:56 -0700, Michel Alexandre Salim wrote:
> On Fri, 2020-08-28 at 18:36 -0700, Michel Alexandre Salim wrote:
> > Hi,
> >
> > Björn added some useful Lua packaging macros in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1447324
> >
> > One of them, %lua_requires, adds a d
On Fri, Aug 28, 2020 at 7:52 PM Chris Murphy wrote:
> The IPP Everywhere specification requires clients to support DNS-SD
> (mDNS is part of that) or WS-Discovery. Printers are required to
> support both DNS-SD and WS-Discovery. Avahi and systemd-resolved
> support DNS-SD, functionally equating D
On Fri, 2020-08-28 at 18:36 -0700, Michel Alexandre Salim wrote:
> Hi,
>
> Björn added some useful Lua packaging macros in
> https://bugzilla.redhat.com/show_bug.cgi?id=1447324
>
> One of them, %lua_requires, adds a dependency on either `lua(abi) =
> %{lua_version}` or, on EL6 and below, on lua
[Sorry for the double post, somewhere along the way desktop@ and kde@
were dropped, so I'm re-adding them and that means double post for
test@ and devel@.]
Re: add working mDNS to the criterion
The IPP Everywhere specification requires clients to support DNS-SD
(mDNS is part of that) or WS-Disco
On Fri, Aug 28, 2020 at 5:56 PM Adam Williamson
wrote:
>
> On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote:
> > 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 connectio
Hi,
Björn added some useful Lua packaging macros in
https://bugzilla.redhat.com/show_bug.cgi?id=1447324
One of them, %lua_requires, adds a dependency on either `lua(abi) =
%{lua_version}` or, on EL6 and below, on lua >= current version and lua
< next version.
Somehow this seems to be automatica
# F33 Blocker Review meeting
# Date: 2020-08-31
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 3 proposed Beta blockers, 1 proposed Final blocker
and 4 proposed Beta freeze exceptions to review, so let's have a Fedora
33 blocker review meeting on Monday!
Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't
have anything urgent this week. We can discuss the network criterion in
the blocker review meeting, I think.
If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and
On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
> Hi folks!
>
> So at this week's blocker review meeting, the fact that we don't have
> explicit networking requirements in the release criteria really started
> to bite us. In the past we have squeezed networking-related issues in
> under
On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote:
> 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 configura
On Wed, 2020-08-26 at 01:14 +, Gary Buhrmaster wrote:
> On Tue, Aug 25, 2020 at 10:51 PM Michel Alexandre Salim
> wrote:
>
> > Also, should we add WireGuard to this list for future-proofing?
>
> I had thought about explicitly suggesting
> wireguard, but then thought that we should
> focus on
On Fri, Aug 28, 2020 at 10:44 PM Sérgio Basto wrote:
>
> On Fri, 2020-08-28 at 15:03 +, Martin Gansser wrote:
> > ok, I'll try again tomorrow or the day after tomorrow when it's
> > available in Rawhide.
>
> you may build it with koji package if you add enabled=1 in [local]
> configuration at
On Fri, 2020-08-28 at 15:03 +, Martin Gansser wrote:
> ok, I'll try again tomorrow or the day after tomorrow when it's
> available in Rawhide.
you may build it with koji package if you add enabled=1 in [local]
configuration at /etc/mock/templates/fedora-rawhide.tpl [1]
[1]
[local]
name=lo
On 28. 08. 20 20:31, Ankur Sinha wrote:
Hiya,
Is anyone working with python packages that use versioneer[1]? My
primary issue here is that upstream does not include tests in the pypi
tars, but because they use versioneer and it does all sorts of "magic":
- it is non trivial to figure out what u
On Friday, 28 August 2020 20:30:18 CEST Eugene Syromiatnikov wrote:
> Hello.
>
> My name is Eugene Syromiatnikov, I am a Software Engineer at Red Hat,
> an IBM company. I maintain strace and microcode_ctl packages
> in RHEL, among other things. Also, I am a strace developer and used
> to contrib
Hiya,
Is anyone working with python packages that use versioneer[1]? My
primary issue here is that upstream does not include tests in the pypi
tars, but because they use versioneer and it does all sorts of "magic":
- it is non trivial to figure out what untagged commit on Github matches
the lat
Hello.
My name is Eugene Syromiatnikov, I am a Software Engineer at Red Hat,
an IBM company. I maintain strace and microcode_ctl packages
in RHEL, among other things. Also, I am a strace developer and used
to contribute to the MoinMoin wiki project.
My main areas of interests are computer archi
On Fri, 2020-08-28 at 16:41 +0200, Tomasz Torcz wrote:
> On Fri, Aug 28, 2020 at 02:30:20PM -, Martin Gansser wrote:
> > the macro "%{vdr_apiversion}" is included in the package vdr-devel
> >
> > rpm -qf /usr/lib/rpm/macros.d/macros.vdr
> > vdr-devel-2.4.4-1.fc32.x86_64
>
> There is no such
Greetings.
As many of you know, the s390x builders have been very slow or failing
builds with intermittent i/o issues for a while now.
I've done what I can to mitigate this on the builder level, but the
problem is at a deeper level.
I've been asked to try and collect issues that package mainta
Dne 28. 08. 20 v 19:09 Adam Williamson napsal(a):
> On Fri, 2020-08-28 at 18:51 +0200, Vít Ondruch wrote:
>> Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a):
>>> No, unfortunately the key is there, but the package is incomplete.
>>>
>>> If you have enabled gpg signatures verification, it would fail.
On Fri, Aug 28, 2020 at 06:51:24PM +0200, Vít Ondruch wrote:
>
> Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a):
> > No, unfortunately the key is there, but the package is incomplete.
> >
> > If you have enabled gpg signatures verification, it would fail. At least
> > it does to me.
> >
> > Check it
On Fri, 2020-08-28 at 18:51 +0200, Vít Ondruch wrote:
> Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a):
> > No, unfortunately the key is there, but the package is incomplete.
> >
> > If you have enabled gpg signatures verification, it would fail. At least
> > it does to me.
> >
> > Check it with:
>
Dne 25. 08. 20 v 16:25 Petr Menšík napsal(a):
> No, unfortunately the key is there, but the package is incomplete.
>
> If you have enabled gpg signatures verification, it would fail. At least
> it does to me.
>
> Check it with:
>
> rpm -ql fedora-gpg-keys | grep fedora-34-$(arch)
>
> It just does
Hi, in accordance with [1] this is a non-responsive maintainer check for
Tom Moertel.
Non-responsive bug: https://bugzilla.redhat.com/show_bug.cgi?id=1873573
Unactioned bugs (earliest is February 2017):
https://bugzilla.redhat.com/show_bug.cgi?id=1221305
https://bugzilla.redhat.com/show_bug.cgi?i
Hi,
On 8/28/20 1:38 AM, Stephan Bergmann wrote:
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 z
ok, I'll try again tomorrow or the day after tomorrow when it's available in
Rawhide.
Regards
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
htt
On Fri, Aug 28, 2020 at 02:30:20PM -, Martin Gansser wrote:
> the macro "%{vdr_apiversion}" is included in the package vdr-devel
>
> rpm -qf /usr/lib/rpm/macros.d/macros.vdr
> vdr-devel-2.4.4-1.fc32.x86_64
There is no such version in Fedora (is this a local build)?
Latest in F32 is vdr-2.4.
the macro "%{vdr_apiversion}" is included in the package vdr-devel
rpm -qf /usr/lib/rpm/macros.d/macros.vdr
vdr-devel-2.4.4-1.fc32.x86_64
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproj
No missing expected images.
Failed openQA tests: 9/181 (x86_64)
New failures (same test not failed in Fedora-33-20200827.n.0):
ID: 650037 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/650037
Old failures (same test failed in Fedora-33-20200827.n.
Hi,
when I want to do a review with: fedora-review -m fedora-rawhide-x86_64 -b
1873407
i get this error message:
warning: line 16: Possible unexpanded macro in: Requires:
vdr(abi)(x86-64) = %{vdr_apiversion}
Building target platforms: x86_64
Building for target x86_64
setting SOURCE_DATE
- Original Message -
> On 28. 08. 20 13:33, Bastien Nocera wrote:
> > I'm sorry, I read through the mail, but I don't understand what you'd want
> > me to say, or what questions you'd want me to answer.
>
> You pretty much answered all the questions. Thanks.
>
> > In short, I've maintai
On 28. 08. 20 13:33, Bastien Nocera wrote:
I'm sorry, I read through the mail, but I don't understand what you'd want
me to say, or what questions you'd want me to answer.
You pretty much answered all the questions. Thanks.
In short, I've maintained the upstream shared-mime-info for 16 years,
OLD: Fedora-33-20200827.n.0
NEW: Fedora-33-20200828.n.0
= SUMMARY =
Added images:1
Dropped images: 1
Added packages: 0
Dropped packages:3
Upgraded packages: 1
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:889.49 KiB
Size of
- Original Message -
> Hello Fedorans, Bastien,
>
> I have noticed that the shared-mime-info package was orphaned couple days
> ago.
I'm sorry, I read through the mail, but I don't understand what you'd want
me to say, or what questions you'd want me to answer.
In short, I've maintaine
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
No missing expected images.
Failed openQA tests: 1/16 (x86_64)
New failures (same test not failed in Fedora-IoT-33-20200826.0):
ID: 649883 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/649883
Soft failed openQA tests: 2/16 (x86_64)
(Tests completed,
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-20200827.0):
ID: 649871 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproj
Hi Christopher,
Thanks for the detailed information.
Regards,
Muneendra.
-Original Message-
From: Christopher Engelhard [mailto:c...@lcts.de]
Sent: Friday, August 28, 2020 2:26 PM
To: devel@lists.fedoraproject.org
Subject: Re: Query on upgrading the Fedora package
Hi Muneendra,
On 28.08
Hi Muneendra,
On 28.08.20 10:47, Muneendra Kumar M via devel wrote:
> After stable time i.e 14 day's the updates will be automatically moved to
> stable .Is this correct.
That is the default yes, but you can configure it differently in the
Bodhi web interface if you choose.
Check out the EPEL G
Of course this would "solve" issue with GPG signature. It opens door for
man-in-the-middle attack without any protection. But I am aware there
are no many better fixes. There is one with arch symlink, allowing
continued GPG verification.
On 8/25/20 5:56 PM, Mattia Verga via devel wrote:
> Il 25/08
Hi Chrstopher,
Thanks for the info.
I have run the below command for update
Fedpkg update --type enhancement.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-77b06c3bc1
After stable time i.e 14 day's the updates will be automatically moved to
stable .Is this correct.
Regards,
Muneendra
Yep, thanks for help
Lukas
On Fri, Aug 28, 2020 at 10:11 AM Dan Horák wrote:
> On Fri, 28 Aug 2020 10:01:37 +0200
> Lukas Javorsky wrote:
>
> > > one difference is that F-33 enabled LTO (new compiler flags added at
> > > the distro level, [1], but as you are building with -Werror, then you
> >
On 28.08.20 10:04, Muneendra Kumar M wrote:
> Do I need to call fedpkg update --type enhancement after fedpkg build for
> epel8 ?
Yes. Any branch that is Bodhi-enabled (normally any branch except
rawhide & epel8-playground) will require a 'fedpkg update' to actually
submit the build to the reposit
On Fri, 28 Aug 2020 10:01:37 +0200
Lukas Javorsky wrote:
> > one difference is that F-33 enabled LTO (new compiler flags added at
> > the distro level, [1], but as you are building with -Werror, then you
> > should review the code for real issues.
as others already mentioned - there is a problem
Hi Christopher,
A small doubt .
Do I need to call fedpkg update --type enhancement after fedpkg build for
epel8 ?
Regards,
Muneendra.
-Original Message-
From: Muneendra Kumar M [mailto:muneendra.ku...@broadcom.com]
Sent: Friday, August 28, 2020 1:00 PM
To: 'Development discussions relate
> one difference is that F-33 enabled LTO (new compiler flags added at
> the distro level, [1], but as you are building with -Werror, then you
> should review the code for real issues.
What do you mean by real issues?
On Thu, Aug 27, 2020 at 2:38 PM Dan Horák wrote:
> On Thu, 27 Aug 2020 14:21:
Hi Christopher,
I did the below steps to upgrade my package to EPEL8 and fedpkg build was
success.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1602105
Do I need to do anything more for the same.
As the below link still shows the older version.
https://src.fedoraproject.org/rpms/fctxpd
51 matches
Mail list logo
