Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

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 that we should remove the script if and only
> > > > if it is generated by NetworkManager? Otherwise, the change is only
> > > > partially-implemented for users upgrading from F32 and earlier.
> > > 
> > > We agreed to go with this approach. /etc/resolv.conf will be moved to
> > > /etc/resolv.conf.orig-with-nm on upgrade to F33 if the 'Generated by
> > > NetworkManager' comment is present. If you've gone to the trouble to
> > > prevent NetworkManager from managing this file, it's likely you've also
> > > removed the comment. If not, you can either remove the comment before
> > > upgrade, or recover your previous configuration from the
> > > /etc/resolv.conf.orig-with-nm backup file after upgrade, and hopefully
> > > have only a small blip in your upgrade experience. This will make the
> > > upgrade work properly for the 99% of users who don't mess with the
> > > defaults and should not be too difficult for those who do.
> > 
> > That comment being there doesn't mean that is still the case. I haven't
> > removed that comment, I just fixed the file. It would be best to just not
> > mess
> > with this file on upgrade, and, instead, change the behavior of new
> > installs.
> > This wouldn't break anything, and would have all newly installed systems
> > with
> > the configuration you seem to want.
> > 
> > There's no reason to break peoples' systems here, we can easily plan for
> > this.
> > I also don't know where you're getting this estimate of 99% of users not
> > changing this file.
> 
> People expect to get the new features on upgrades without having to
> reinstall.

This isn't a new feature, it's breaking existing functionality.

> There is no reason to upgrades differently - if you have customized
> configuration you should be reading the changes before doing an upgrade.

The major reason that we've had different functionality on upgrade in the past 
is precisely what I described: to prevent needlessly breaking the users' 
systems. Regardless of the changes coming, updating should never break your 
system, especially when it's easily avoided, as it is in this case.

-- 
John M. Harris, Jr.

___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[drago01]

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 NetworkManager? Otherwise, the change is only
> > > partially-implemented for users upgrading from F32 and earlier.
> >
> >
> > We agreed to go with this approach. /etc/resolv.conf will be moved to
> > /etc/resolv.conf.orig-with-nm on upgrade to F33 if the 'Generated by
> > NetworkManager' comment is present. If you've gone to the trouble to
> > prevent NetworkManager from managing this file, it's likely you've also
> > removed the comment. If not, you can either remove the comment before
> > upgrade, or recover your previous configuration from the
> > /etc/resolv.conf.orig-with-nm backup file after upgrade, and hopefully
> > have only a small blip in your upgrade experience. This will make the
> > upgrade work properly for the 99% of users who don't mess with the
> > defaults and should not be too difficult for those who do.
>
> That comment being there doesn't mean that is still the case. I haven't
> removed that comment, I just fixed the file. It would be best to just not
> mess
> with this file on upgrade, and, instead, change the behavior of new
> installs.
> This wouldn't break anything, and would have all newly installed systems
> with
> the configuration you seem to want.
>
> There's no reason to break peoples' systems here, we can easily plan for
> this.
> I also don't know where you're getting this estimate of 99% of users not
> changing this file.


People expect to get the new features on upgrades without having to
reinstall.

There is no reason to upgrades differently - if you have customized
configuration you should be reading the changes before doing an upgrade.


> --
> John M. Harris, Jr.
>
> ___
> 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.
> org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org
>
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[John M. Harris Jr]

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-implemented for users upgrading from F32 and earlier.
> 
> 
> We agreed to go with this approach. /etc/resolv.conf will be moved to 
> /etc/resolv.conf.orig-with-nm on upgrade to F33 if the 'Generated by 
> NetworkManager' comment is present. If you've gone to the trouble to 
> prevent NetworkManager from managing this file, it's likely you've also 
> removed the comment. If not, you can either remove the comment before 
> upgrade, or recover your previous configuration from the 
> /etc/resolv.conf.orig-with-nm backup file after upgrade, and hopefully 
> have only a small blip in your upgrade experience. This will make the 
> upgrade work properly for the 99% of users who don't mess with the 
> defaults and should not be too difficult for those who do.

That comment being there doesn't mean that is still the case. I haven't 
removed that comment, I just fixed the file. It would be best to just not mess 
with this file on upgrade, and, instead, change the behavior of new installs. 
This wouldn't break anything, and would have all newly installed systems with 
the configuration you seem to want.

There's no reason to break peoples' systems here, we can easily plan for this. 
I also don't know where you're getting this estimate of 99% of users not 
changing this file.

-- 
John M. Harris, Jr.

___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Switching package to fragmented default configuration

[John M. Harris Jr]

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
> > tools to override some specific settings (like the default NTP
> > servers) by dropping a file into a directory, instead of having to
> > modify a packaged config file. It seems to be a modern trend, used
> > by many packages in Fedora, and I have received some RFEs to adopt
> > in chrony.
> > 
> > The default /etc/chrony.conf would just have a single directive
> > loading configuration fragments from /etc/chrony.d and
> > /var/lib/chrony.d (and maybe also /var/run/chrony.d).
> 
> 
> It's nice to not require any files in /etc (so for example the admin
> can do 'rm -rf /etc/*' to restore vendor defaults). So instead of
> using /etc/chrony.conf to load other files, please consider just
> building this logic directly into the code. There is also no need to
> make those config paths configurable.

Why would you move configuration files from /etc? If this is to be done, 
please leave the files in /etc and symlink at the new location, or the 
reverse, so sysadmins don't have to update all of our carefully written 
scripts and learn yet another location across the various versions of systems 
used. This wouldn't make things easier for admins, it would make it more 
difficult. Right now, we know where the config file currently being read by 
the software is. It's easy to check for it, and see what's in it.

Defaults go in /etc/default or just the default config file, so that it's 
there only if the admins don't change it. Please don't change this, this is 
really easy to work with.

> The whole goal of the config-in-dropin-files-logic is that anaconda
> wouldn't parse existing config, it would just write
> /etc/chrony.d/50-anaconda.conf that would override only the parts it
> cares about.

Anaconda doesn't need to parse existing config, as far as I know, it just 
writes out new config. Anaconda is run at install-time, where the existing 
config doesn't really matter.

> Also, please don't invent a new logic — just follow the same one that
> systemd does [1]. This has the advantage that if something *needs* to
> look all of config, it can reuse what an existing loader. Also, admins
> don't need to learn a new set of rules. Ideally,
> 'systemd-analyze cat-config chrony.conf' would just work.

Please don't invent a new logic, especially the one that systemd does. This 
makes it very difficult to figure out where in the world the configuration 
file for a given program is. With systemd, sure, it's not so bad, as the 
command will tell you where the unit file is. There's no such command for, for 
example, chronyd, httpd or any other program that itself isn't using such a 
convoluted configuration system. Even systemd wouldn't work if you blew away /
etc.

> > Also,
> > I'm not sure how user-friendly this is for regular users who modify
> > the configuration manually.
> > 
> > Are there any recommendations for switching an existing single-config
> > package to a fully fragmented configuration? Is it worth the trouble,
> > or do you have any other suggestions?
> 
> 
> Yes, it's definitely worth the trouble, it makes many things easier and
> more robust.

Who does this make things easier for? How does added complexity make this more 
robust?

-- 
John M. Harris, Jr.

___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] 389 DS nightly 2020-08-29 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/08/29/report-389-ds-base-1.4.4.4-20200828git3d61aaf.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

[EPEL-devel] Re: Continuing playground discussion

[Leon Fauster]

Am 29.08.20 um 00:11 schrieb Troy Dawson:

On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson  wrote:


On Sat, Aug 22, 2020 at 11:12 AM kevin  wrote:


On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:


On 21/8/20 19:06, Troy Dawson wrote:



C) Drop playground.  Say it was an interesting experiment and we
learned stuff, but shut it down.
(and clean up the package.cfg files as part of shutting it down)

D)
1 - Manual builds only.  No package.cfg files.  No automatic builds.
2 - Assume playground depends on epel8.
3 - Use CentOS 8 Stream to build against.

I am leaning towards option D.
We've already got all the playground infrastructure setup.  I don't
want to waste that.  So, although I said option C in the meeting, that
doesn't mean I want it, I was just stating it was an option.

I like option D too, looks like a more polished version of option B


Do we have any data here?

Are stream changes breaking epel packages so that they need rebuilds
often?

It will mean that if someone wants to use playground to test some large
change in epel, they will have to find people who also enable stream to
test it most likely?

Do we know that many/any people are consuming stream all the time?

We also don't have much way to say 'if you enable epel8-playground you
have to enable stream repos also'.

I guess I don't think the yummy to trouble ratio is good enough here to
justify the trouble of enabling stream. Can you expand on why this is
good/what it gets us?



Pros for building against stream:
- We would have a way to test EPEL packages that matter against the
not yet released RHEL version.
-- How often would this matter?
-- It's hard to say.  There might not be a single EPEL package needing
this for the entire RHEL 8.3 release.
-- I know for the 8.2 release, I would have liked it so I would have
had a place to let others test my updated KDE.
--- But I found a work around, so I didn't have to have it.

Cons for building against stream:
- I think you've hit on a big thing.  For those wanting a major
change, but don't care about stream, then playground becomes useless.
-- So this cuts down on the usefulness of playground.  Packagers who
want a major change in their package, and are working on stream.
- HERE IS THE BIGGEST CON AGAINST USING STREAM
-- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes
out.  At some point after that, it switches to being based off RHEL9.
--- This means that infrastructure is going to have to switch
everything back to being built off RHEL.
--- We will have to re-document things.
--- More confusion if we had go the CentOS Stream route.

Troy


At the EPEL Steering Committee Meeting, this was discussed again.
I believe we all agree that having -playground build off Stream isn't
a good thing.
But we are also concerned about possible library changes in RHEL8 that
might affect EPEL8 packages, and having something based off Stream
would be good.
Here is the proposal.
Note: A) was re-written with better wording than above.

A) epel8-playground
1 - Manual builds only.  No package.cfg files.  No automatic builds.
2 - Assume playground depends on epel8.
3 - Built off RHEL8 and CentOS Devel, just like epel8 is built.

E) epel8-next
1 - Manual builds only.  No package.cfg files.  No automatic builds.
2 - Assume -next depends on epel.
3 - Built off CentOS Stream.
4 - Has a limited lifetime that corresponds with the CentOS Stream /
RHEL lifetime.
-- In other words, after CentOS Stream switches from RHEL8 to RHEL9,
then epel8-next get's archived.

If people are wondering about the name, it was decided to use -next
instead of -stream, due to the overuse of 'stream' among other
reasons.




Just a thought - this assumes that when RHEL9 gets out of the door. The 
above mentioned scenario (possible library changes) will not happen? 
Implies after May 31, 2024 (EL8 Maintenance Support Phase starts) ...


--
Leon



___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: %lua_requires behaves differently in F33+

[Michel Alexandre Salim]

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 dependency on either `lua(abi) =
> > %{lua_version}` or, on EL6 and below, on lua >= current version and
> > lua
> > < next version.
> > 
...
> > PS Björn -- we should consider moving the macros out of lua-devel
> > and
> > into lua-rpm-macros, that lua-devel then depends on. That will fix
> > the
> > inability to get these macros out to EPEL6 and EPEL7 - on those,
> > lua
> > packages can just BR the macro package directly.
> > 
> So having lua-rpm-macros with potentially a lua-srpm-macros would
> help
> here.
> 

I've created a review request for the proposed new macro package here:
https://bugzilla.redhat.com/show_bug.cgi?id=1873676

If this is accepted:
- we can immediately branch and ship this for EL6 and EL7 so Lua
packages for those releases can use macros
- I'll get redhat-rpm-config to pull in lua-srpm-macros, the same way
it pulls in other *-srpm-macros packages
- I'll refactor lua in Fedora so lua-devel pulls in lua-rpm-macros
rather than shipping macros.lua, then enable shipping macros.lua in
lua-rpm-macros (right now it's excluded on Fedora to avoid file
conflicts)

I'll also look at creating an official SIG including having a mailing
list.

Thanks,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


signature.asc
Description: This is a digitally signed message part
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Release criteria proposal: networking requirements

[Chris Murphy]

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 DNS-SD and mDNS.

From the spec:

"Printers MUST publish a text (TXT) record that provides service
information over mDNS.
Printers that support dynamic DNS updates MUST publish separate TXT
records for each
domain that is updated."

I'm not completely certain, but I'm wondering whether it's possible to
print IPP Everywhere at all, if DNS-SD or WS-Discovery aren't working
on the client. Even having the IP address might not be enough.

I guess one way to test it would be to run the printing test case with
an IPP Everywhere printer, and try to print with avahi stopped.


-- 
Chris Murphy
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %lua_requires behaves differently in F33+

[Michel Alexandre Salim]

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 >= current version and
> lua
> < next version.
> 
> Somehow this seems to be automatically applied on Fedora 33 and above
> -- without adding any manual require on lua(abi)
> 
> e.g. lua-lunitx on Fedora 33
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c23dc64c0
> 
> on Fedora 32, though, the macro is not automatically invoked (so the
> update below is bad and I need to redo it)
>  https://bodhi.fedoraproject.org/updates/FEDORA-2020-9074133de4
> 
> In fact, trying to use %lua_requires does not seem to work, with and
> without curly braces:
> 
> error: line 15: Unknown tag: %lua_requires
> error: line 15: Unknown tag: %{lua_requires}
> 
Partially answering this point: this is because %lua_requires is not
available on the system where rpmbuild -bs was invoked to create the
SRPM.

Some languages (e.g. Python) ship $LANG-srpm-macros packages that are
pulled in by redhat-rpm-config to address this.


> PS Björn -- we should consider moving the macros out of lua-devel and
> into lua-rpm-macros, that lua-devel then depends on. That will fix
> the
> inability to get these macros out to EPEL6 and EPEL7 - on those, lua
> packages can just BR the macro package directly.
> 
So having lua-rpm-macros with potentially a lua-srpm-macros would help
here.

But this won't even be needed if we can figure out how %lua_requires
get triggered on Fedora 33+ and have it work that way on older releases
too.

Thanks,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


signature.asc
Description: This is a digitally signed message part
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Release criteria proposal: networking requirements

[Chris Murphy]

[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-Discovery. Printers are required to
support both DNS-SD and WS-Discovery. Avahi and systemd-resolved
support DNS-SD, functionally equating DNS-SD and mDNS.

Final release criterion says printing via the generic IPP driver must
work. This implies discovery or you can't print. Or accept a
craptastic user experience by fudging the requirement to say, well as
long as an IP address works, the criterion is met.

It's even less of a leap if folks can't discover other services like
SMB shares. That's more common than printing.

Between avahi and systemd-resolved, I'm not sure which one is more
dependable for blocking on. Or whether their maintainers would be on
board with such a criterion. At least for F33, Avahi is what we're
using on desktops for this. Both resolve and respond are disabled in
systemd-resolved so if it's better to do this with systemd-resolved,
then it probably needs a Fedora 34 feature proposal.

--
Chris Murphy
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Release criteria proposal: networking requirements

[Chris Murphy]

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 connections
> > > using DHCP and static addressing. The default network configuration
> > > tools for the console and for release-blocking desktops must work well
> > > enough to allow typical network connection configuration operations
> > > without major workarounds. Standard network functions such as address
> > > resolution and connections with common protocols such as ping, HTTP and
> > > ssh must work as expected.
> >
> > What about mDNS?
>
> ehhh
>
> I am probably a bit biased on this front because I always found mDNS to
> be a pile of garbage and gave up trying to use it a while back. :P But
> if a significant amount of people are actually using it and relying on
> it, adding it might make sense. Anyone else have input on this? Who out
> there does use mDNS?

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 DNS-SD and mDNS.

Final release criterion says printing via the generic IPP driver must
work. This implies discovery or you can't print. Or accept a
craptastic user experience by fudging the requirement to say, well as
long as an IP address works, the criterion is met.

It's even less of a leap if folks can't discover other services like
SMB shares. That's more common than printing.

Between avahi and systemd-resolved, I'm not sure which one is more
dependable for blocking on. Or whether their maintainers would be on
board with such a criterion. At least for F33, Avahi is what we're
using on desktops for this. Both resolve and respond are disabled in
systemd-resolved so if it's better to do this with systemd-resolved,
then it probably needs a Fedora 34 feature proposal.


-- 
Chris Murphy
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

%lua_requires behaves differently in F33+

[Michel Alexandre Salim]

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 automatically applied on Fedora 33 and above
-- without adding any manual require on lua(abi)

e.g. lua-lunitx on Fedora 33
https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c23dc64c0

on Fedora 32, though, the macro is not automatically invoked (so the
update below is bad and I need to redo it)
 https://bodhi.fedoraproject.org/updates/FEDORA-2020-9074133de4

In fact, trying to use %lua_requires does not seem to work, with and
without curly braces:

error: line 15: Unknown tag: %lua_requires
error: line 15: Unknown tag: %{lua_requires}

Could someone help explain these two behaviors? I'm working on resuming
the Lua packaging draft so I want to have a canonical example on how
the macros are supposed to be used.

PS Björn -- we should consider moving the macros out of lua-devel and
into lua-rpm-macros, that lua-devel then depends on. That will fix the
inability to get these macros out to EPEL6 and EPEL7 - on those, lua
packages can just BR the macro package directly.

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


signature.asc
Description: This is a digitally signed message part
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] 2020-08-31 @ 16:00 UTC - Fedora 33 Blocker Review Meeting

[Adam Williamson]

# 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!

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F33 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Proposal to CANCEL: 2020-08-31 Fedora QA Meeting

[Adam Williamson]

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 run the meeting.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] plasma has moved from epel into playground causing update conflicts

[Andy Hall]

Can the below be fixed ? I guess this package should not be in both repos...

# yum update
Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST.
Error:
 Problem 1: package
plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install the best update candidate for package
plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64
  - cannot install the best update candidate for package
gpsd-libs-3.19-4.el8.1.x86_64
 Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and
gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
  - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - package plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64
requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground,
but none of the providers can be installed
  - cannot install the best update candidate for package
plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64

# yum info plasma-workspace-geolocation
Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST.
Installed Packages
Name : plasma-workspace-geolocation
Version  : 5.18.4.1
Release  : 2.el8
Architecture : x86_64
Size : 206 k
Source   : plasma-workspace-5.18.4.1-2.el8.src.rpm
Repository   : @System
From repo: epel
Summary  : Plasma5 geolocation components
URL  : https://cgit.kde.org/plasma-workspace.git
License  : GPLv2+
Description  : Plasma5 geolocation components.

Available Packages
Name : plasma-workspace-geolocation
Version  : 5.18.4.1
Release  : 2.epel8.playground
Architecture : x86_64
Size : 87 k
Source   : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm
Repository   : epel-playground
Summary  : Plasma5 geolocation components
URL  : https://cgit.kde.org/plasma-workspace.git
License  : GPLv2+
Description  : Plasma5 geolocation components.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Release criteria proposal: networking requirements

[Adam Williamson]

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 other criteria, but for some issues that's really difficult,
> notably VPN issues. So, we agreed we should draft some explicit
> networking criteria.

Update: here's a second draft with feedback so far incorporated, thanks
to everyone. Still mulling over whether/how to split it more across
milestones.

=== Network requirements ===

Each of these requirements apply to both installer and installed system
environments. For any given installer environment, the 'default network
configuration tools' are considered to be those the installer documents
as supported ways to configure networking (e.g. for anaconda-based
environments, configuration via kernel command line options, a
kickstart, or interactively in anaconda itself are included).

 Basic networking 

It must be possible to establish both IPv4 and IPv6 network connections
using both typical router-provided addressing systems (e.g. DHCP on
IPv4 or SLAAC or IPv6) and static addressing. The default network
configuration tools for the console, for release-blocking desktops and
for installer environments must work well enough to allow typical
network connection configuration operations without major workarounds.
Standard network functions such as address resolution and connections
with common protocols such as ping, HTTP and ssh must work as expected.

Footnote titled "Supported hardware": Supported network hardware is
hardware for which the Fedora kernel includes drivers and, where
necessary, for which a firmware package is available. If support for a
commonly-used piece or type of network hardware that would usually be
present is omitted, that may constitute a violation of this criterion,
after consideration of the [[Blocker_Bug_FAQ|hardware-dependent-
issues|normal factors for hardware-dependent issues]]. Similarly,
violations of this criteria that are hardware or configuration
dependent are, as usual, subject to consideration of those factors when
determining whether they are release-blocking

 VPN connections 

Using the default network configuration tools for the console and for
release-blocking desktops, it must be possible to establish a working
connection to common OpenVPN, openconnect-supported and vpnc-supported
VPN servers with typical configurations.

Footnote titled "Supported servers and configurations": As there are
many different VPN server applications and configurations, blocker
reviewers must use their best judgment in determining whether
violations of this criterion are likely to be encountered commonly
enough to block a release, and if so, at which milestone. As a general
principle, the more people are likely to use affected servers and the
less complicated the configuration required to hit the bug, the more
likely it is to be a blocker.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Release criteria proposal: networking requirements

[Adam Williamson]

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 configuration
> > tools for the console and for release-blocking desktops must work well
> > enough to allow typical network connection configuration operations
> > without major workarounds. Standard network functions such as address
> > resolution and connections with common protocols such as ping, HTTP and
> > ssh must work as expected.
> 
> What about mDNS?

ehhh

I am probably a bit biased on this front because I always found mDNS to
be a pile of garbage and gave up trying to use it a while back. :P But
if a significant amount of people are actually using it and relying on
it, adding it might make sense. Anyone else have input on this? Who out
there does use mDNS?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Release criteria proposal: networking requirements

[Adam Williamson]

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 what is currently being used, and
> while *I* use wireguard, it is still not really
> a common use case.
> 
> We do, of course, need to remember to
> regularly review all the criteria to make
> sure that they still make sense in the current
> environment and be willing to delete some
> things from the list when only a few still
> have such equipment or use the functionality.
> 
> I would almost suggest any addition
> should come with a criteria deletion,
> to bound the work for the QA team,
> who are, after all, a limited resource.

I **AM** THE QA TEAM

well, okay, not all of it. :P But yeah, I get the intention of that
idea, but it wouldn't really work out. We do just need to add things
sometimes. This is really about covering stuff that we would have
wanted to block on anyway (and sometimes have, by stretching other
criteria) but just hadn't ever written into the criteria.

We do drop things sometimes and make other adjustments like how we
stopped requiring such extensive testing of physical media and
restricted the desktop criteria a bit, a couple of releases back. But
making it a strict one in/one out probably wouldn't be practical.

Also note that ensuring the products meets these criteria is meant to
be a collaborative effort; the teams who build the products are
supposed to share that responsibility with the QA team, including doing
some of the actual testing.

I agree on the WireGuard front - that's what I meant by saying "It
doesn't really make sense to add things to the release criteria for
future proofing." The criteria should reflect *current* importance.
Unless use of WireGuard is in the same ballpark as OpenVPN or Cisco
etc. we probably wouldn't want to include it right now.

I *do* wonder if any of the other VPN plugins I see listed at
https://wiki.gnome.org/Projects/NetworkManager/VPN but didn't include
in the criterion are candidates. Does anyone have stats / practical
knowledge of the relative popularity of all those?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1873624] perl-DateTime-Locale-1.28 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1873624

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-DateTime-Locale-1.27   |perl-DateTime-Locale-1.28
   |is available|is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.28
Current version/release in rawhide: 1.25-2.fc32
URL: http://search.cpan.org/dist/DateTime-Locale/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/6477/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Re: Continuing playground discussion

[James Cassell]

On Fri, Aug 28, 2020, at 6:11 PM, Troy Dawson wrote:
> On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson  wrote:
> >
> > On Sat, Aug 22, 2020 at 11:12 AM kevin  wrote:
> > >
> > > On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
> > > >
> > > > On 21/8/20 19:06, Troy Dawson wrote:
> > >
> > > > > C) Drop playground.  Say it was an interesting experiment and we
> > > > > learned stuff, but shut it down.
> > > > > (and clean up the package.cfg files as part of shutting it down)
> > > > >
> > > > > D)
> > > > > 1 - Manual builds only.  No package.cfg files.  No automatic builds.
> > > > > 2 - Assume playground depends on epel8.
> > > > > 3 - Use CentOS 8 Stream to build against.
> > > > >
> > > > > I am leaning towards option D.
> > > > > We've already got all the playground infrastructure setup.  I don't
> > > > > want to waste that.  So, although I said option C in the meeting, that
> > > > > doesn't mean I want it, I was just stating it was an option.
> > > > I like option D too, looks like a more polished version of option B
> > >
> > > Do we have any data here?
> > >
> > > Are stream changes breaking epel packages so that they need rebuilds
> > > often?
> > >
> > > It will mean that if someone wants to use playground to test some large
> > > change in epel, they will have to find people who also enable stream to
> > > test it most likely?
> > >
> > > Do we know that many/any people are consuming stream all the time?
> > >
> > > We also don't have much way to say 'if you enable epel8-playground you
> > > have to enable stream repos also'.
> > >
> > > I guess I don't think the yummy to trouble ratio is good enough here to
> > > justify the trouble of enabling stream. Can you expand on why this is
> > > good/what it gets us?
> > >
> >
> > Pros for building against stream:
> > - We would have a way to test EPEL packages that matter against the
> > not yet released RHEL version.
> > -- How often would this matter?
> > -- It's hard to say.  There might not be a single EPEL package needing
> > this for the entire RHEL 8.3 release.
> > -- I know for the 8.2 release, I would have liked it so I would have
> > had a place to let others test my updated KDE.
> > --- But I found a work around, so I didn't have to have it.
> >
> > Cons for building against stream:
> > - I think you've hit on a big thing.  For those wanting a major
> > change, but don't care about stream, then playground becomes useless.
> > -- So this cuts down on the usefulness of playground.  Packagers who
> > want a major change in their package, and are working on stream.
> > - HERE IS THE BIGGEST CON AGAINST USING STREAM
> > -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes
> > out.  At some point after that, it switches to being based off RHEL9.
> > --- This means that infrastructure is going to have to switch
> > everything back to being built off RHEL.
> > --- We will have to re-document things.
> > --- More confusion if we had go the CentOS Stream route.
> >
> > Troy
> 
> At the EPEL Steering Committee Meeting, this was discussed again.
> I believe we all agree that having -playground build off Stream isn't
> a good thing.
> But we are also concerned about possible library changes in RHEL8 that
> might affect EPEL8 packages, and having something based off Stream
> would be good.
> Here is the proposal.
> Note: A) was re-written with better wording than above.
> 
> A) epel8-playground
> 1 - Manual builds only.  No package.cfg files.  No automatic builds.
> 2 - Assume playground depends on epel8.
> 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built.
> 
> E) epel8-next
> 1 - Manual builds only.  No package.cfg files.  No automatic builds.
> 2 - Assume -next depends on epel.
> 3 - Built off CentOS Stream.
> 4 - Has a limited lifetime that corresponds with the CentOS Stream /
> RHEL lifetime.
> -- In other words, after CentOS Stream switches from RHEL8 to RHEL9,
> then epel8-next get's archived.
> 
> If people are wondering about the name, it was decided to use -next
> instead of -stream, due to the overuse of 'stream' among other
> reasons.
> 
> Thoughts?

Sounds like the perfect solution to me!

V/r,
James Cassell
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

[Fabio Valentini]

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 /etc/mock/templates/fedora-rawhide.tpl [1]

No need to modify system config files:

fedora-review -m fedora-rawhide-x86_64 -o "--enablerepo local" -b 1234567

Does the same thing :)

Fabio
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[EPEL-devel] Re: Continuing playground discussion

[Troy Dawson]

On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson  wrote:
>
> On Sat, Aug 22, 2020 at 11:12 AM kevin  wrote:
> >
> > On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
> > >
> > > On 21/8/20 19:06, Troy Dawson wrote:
> >
> > > > C) Drop playground.  Say it was an interesting experiment and we
> > > > learned stuff, but shut it down.
> > > > (and clean up the package.cfg files as part of shutting it down)
> > > >
> > > > D)
> > > > 1 - Manual builds only.  No package.cfg files.  No automatic builds.
> > > > 2 - Assume playground depends on epel8.
> > > > 3 - Use CentOS 8 Stream to build against.
> > > >
> > > > I am leaning towards option D.
> > > > We've already got all the playground infrastructure setup.  I don't
> > > > want to waste that.  So, although I said option C in the meeting, that
> > > > doesn't mean I want it, I was just stating it was an option.
> > > I like option D too, looks like a more polished version of option B
> >
> > Do we have any data here?
> >
> > Are stream changes breaking epel packages so that they need rebuilds
> > often?
> >
> > It will mean that if someone wants to use playground to test some large
> > change in epel, they will have to find people who also enable stream to
> > test it most likely?
> >
> > Do we know that many/any people are consuming stream all the time?
> >
> > We also don't have much way to say 'if you enable epel8-playground you
> > have to enable stream repos also'.
> >
> > I guess I don't think the yummy to trouble ratio is good enough here to
> > justify the trouble of enabling stream. Can you expand on why this is
> > good/what it gets us?
> >
>
> Pros for building against stream:
> - We would have a way to test EPEL packages that matter against the
> not yet released RHEL version.
> -- How often would this matter?
> -- It's hard to say.  There might not be a single EPEL package needing
> this for the entire RHEL 8.3 release.
> -- I know for the 8.2 release, I would have liked it so I would have
> had a place to let others test my updated KDE.
> --- But I found a work around, so I didn't have to have it.
>
> Cons for building against stream:
> - I think you've hit on a big thing.  For those wanting a major
> change, but don't care about stream, then playground becomes useless.
> -- So this cuts down on the usefulness of playground.  Packagers who
> want a major change in their package, and are working on stream.
> - HERE IS THE BIGGEST CON AGAINST USING STREAM
> -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes
> out.  At some point after that, it switches to being based off RHEL9.
> --- This means that infrastructure is going to have to switch
> everything back to being built off RHEL.
> --- We will have to re-document things.
> --- More confusion if we had go the CentOS Stream route.
>
> Troy

At the EPEL Steering Committee Meeting, this was discussed again.
I believe we all agree that having -playground build off Stream isn't
a good thing.
But we are also concerned about possible library changes in RHEL8 that
might affect EPEL8 packages, and having something based off Stream
would be good.
Here is the proposal.
Note: A) was re-written with better wording than above.

A) epel8-playground
1 - Manual builds only.  No package.cfg files.  No automatic builds.
2 - Assume playground depends on epel8.
3 - Built off RHEL8 and CentOS Devel, just like epel8 is built.

E) epel8-next
1 - Manual builds only.  No package.cfg files.  No automatic builds.
2 - Assume -next depends on epel.
3 - Built off CentOS Stream.
4 - Has a limited lifetime that corresponds with the CentOS Stream /
RHEL lifetime.
-- In other words, after CentOS Stream switches from RHEL8 to RHEL9,
then epel8-next get's archived.

If people are wondering about the name, it was decided to use -next
instead of -stream, due to the overuse of 'stream' among other
reasons.

Thoughts?
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

[Sérgio Basto]

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=local
baseurl=https://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/
cost=2000
enabled=1
skip_if_unavailable=False


> Regards
> Martin
> ___
> 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.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
-- 
Sérgio M. B.
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: python-versioneer: no version information in github archives?

[Miro Hrončok]

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 untagged commit on Github matches
   the latest pypi tar release

- even if one does manage to locate the commit, if we use the GitHub
   archives, versioneer cannot get the version information from them:
   https://github.com/warner/python-versioneer/issues/140#issuecomment-292746426

Does any one have any ideas here? I've requested upstream to include
tests in the pypi tars[2], but a way of forcing versioneer to provide the
correct version would be really nice.

[1] https://github.com/warner/python-versioneer
[2] https://github.com/BlueBrain/eFEL/issues/181


I remember it was but it was extremely hard to use anything but the sdist when 
hacking on nb2plots. See:


https://src.fedoraproject.org/rpms/python-nb2plots/pull-request/2

Overall, versioneer behaves very badly when you try to bend it for RPM 
packaging. Also, it appears upstream dead and this particular issue is not 
getting anywhere:


https://github.com/warner/python-versioneer/issues/199

I'd ask upstream if they could consider using setuptools_scm instead.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1873624] New: perl-DateTime-Locale-1.27 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1873624

Bug ID: 1873624
   Summary: perl-DateTime-Locale-1.27 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DateTime-Locale
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.27
Current version/release in rawhide: 1.25-2.fc32
URL: http://search.cpan.org/dist/DateTime-Locale/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/6477/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Self Introduction: Eugene Syromiatnikov

[Robert-André Mauchin]

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 contribute to the MoinMoin wiki project.
> 
> My main areas of interests are computer architecture, low-level
> programming, and high-performance computing.


Welcome to Fedora!



___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

python-versioneer: no version information in github archives?

[Ankur Sinha]

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 latest pypi tar release

- even if one does manage to locate the commit, if we use the GitHub
  archives, versioneer cannot get the version information from them:
  https://github.com/warner/python-versioneer/issues/140#issuecomment-292746426

Does any one have any ideas here? I've requested upstream to include
tests in the pypi tars[2], but a way of forcing versioneer to provide the
correct version would be really nice.

[1] https://github.com/warner/python-versioneer
[2] https://github.com/BlueBrain/eFEL/issues/181

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Self Introduction: Eugene Syromiatnikov

[Eugene Syromiatnikov]

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 architecture, low-level
programming, and high-performance computing.
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

[Sérgio Basto]

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 version in Fedora (is this a local build)?
> Latest in F32 is vdr-2.4.1-5.fc32, and the spec has BR >= 2.4.3.
> 
>   For Rawhide, you just built vdr-2.4.4-1.fc34 yesterday – it may not
> be
> available in Rawhide compose yet.



yes, I see in root.log 

DEBUG util.py:623:  Last metadata expiration check: 0:00:02 ago on Fri
Aug 28 19:11:55 2020.
DEBUG util.py:621:  No matching package to install: 'vdr-devel >=
2.4.3'
DEBUG util.py:621:  Not all dependencies satisfied
DEBUG util.py:621:  Error: Some packages could not be found.


-- 
Sérgio M. B.
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

s390x builder issues

[kevin]

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 maintainers are
hitting on these builders and provide them to mainframe admins so they
can understand the impact on us and prioritize more resources or other
corrective measures. 

To that end, if you are a maintainer and: 

* A build on s390x being slow affects you (needed for another build,
important bug fix, etc) in a serious way

or

* a build on a s390x builder fails in some odd way that is NOT related
to your package (unable to download src.rpm, checksum mismatches, etc). 

I'd love for you to note: 

* the link to the failed/slow task 
* The time (UTC preferred)
* which exact builder it was 
* what the issue was
* how it impacted your fedora work

into: https://pagure.io/fedora-infrastructure/issue/9232

Please don't post to the list, mail me privately, etc. 
Just add the info to the above issue. 

Thanks for your help

kevin


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

s390x builder issues

[kevin]

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 maintainers are
hitting on these builders and provide them to mainframe admins so they
can understand the impact on us and prioritize more resources or other
corrective measures. 

To that end, if you are a maintainer and: 

* A build on s390x being slow affects you (needed for another build,
important bug fix, etc) in a serious way

or

* a build on a s390x builder fails in some odd way that is NOT related
to your package (unable to download src.rpm, checksum mismatches, etc). 

I'd love for you to note: 

* the link to the failed/slow task 
* The time (UTC preferred)
* which exact builder it was 
* what the issue was
* how it impacted your fedora work

into: https://pagure.io/fedora-infrastructure/issue/9232

Please don't post to the list, mail me privately, etc. 
Just add the info to the above issue. 

Thanks for your help

kevin


signature.asc
Description: PGP signature
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: [HOWTO] Keep using Rawhide after branching

[Vít Ondruch]

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. At least
>>> it does to me.
>>>
>>> Check it with:
>>>
>>> rpm -ql fedora-gpg-keys | grep fedora-34-$(arch)
>>>
>>> It just does not provide correct key.
>>
>> Actually, yesterday I did update of another system with my approach and
>> you are right that the fedora-gpg-keys-33-0.9 did not contained the
>> proper links to the key. However, the fedora-gpg-keys-33-0.10 works just
>> fine (not really sure what caused the difference).
> The change to archmap in this commit:
> https://src.fedoraproject.org/rpms/fedora-repos/c/5f02f474842d23a0217c1118893f508009236c18?branch=f33
> which landed between 0.9 and 0.10 (the versioning was fixed up in the
> next commit).


Thx, right, I have missed that. Pretty confusing series of commits :(


Vít
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HOWTO] Keep using Rawhide after branching

[kevin]

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 with:
> >
> > rpm -ql fedora-gpg-keys | grep fedora-34-$(arch)
> >
> > It just does not provide correct key.
> 
> 
> Actually, yesterday I did update of another system with my approach and
> you are right that the fedora-gpg-keys-33-0.9 did not contained the
> proper links to the key. However, the fedora-gpg-keys-33-0.10 works just
> fine (not really sure what caused the difference). I did precisely:

the 0.9 one was broken. Incorrect. Had a bug. Mistaken. Not right. 
Not represenative of how the process is supposed to work. 

The 0.10 one was fixed and should behave as you note, and work to
upgrade to rawhide without disabling any gpg key. 

Sorry this time it wasn't correct. Mistakes happen. 

kevin


signature.asc
Description: PGP signature
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HOWTO] Keep using Rawhide after branching

[Adam Williamson]

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:
> > 
> > rpm -ql fedora-gpg-keys | grep fedora-34-$(arch)
> > 
> > It just does not provide correct key.
> 
> 
> Actually, yesterday I did update of another system with my approach and
> you are right that the fedora-gpg-keys-33-0.9 did not contained the
> proper links to the key. However, the fedora-gpg-keys-33-0.10 works just
> fine (not really sure what caused the difference).

The change to archmap in this commit:
https://src.fedoraproject.org/rpms/fedora-repos/c/5f02f474842d23a0217c1118893f508009236c18?branch=f33
which landed between 0.9 and 0.10 (the versioning was fixed up in the
next commit).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HOWTO] Keep using Rawhide after branching

[Vít Ondruch]

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 not provide correct key.


Actually, yesterday I did update of another system with my approach and
you are right that the fedora-gpg-keys-33-0.9 did not contained the
proper links to the key. However, the fedora-gpg-keys-33-0.10 works just
fine (not really sure what caused the difference). I did precisely:


~~~

$ sudo dnf update --disablerepo=rawhide --enablerepo=fedora
fedora-gpg-keys --release 33

$ sudo dnf update fedora-repos\* --release 34

~~~


Vít


>  The same issue is there for f31
> and f32. When you create platform link yourself, then you can upgrade
> without turning off signature verification.
>
> I got mad it always breaks and prepared automated test [1]. Hope next
> time rolling rawhide would be possible. I report issue with that every
> release and got tired of it. It is a bit better now, but not great.
>
> 1. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/76
> 2. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/77
>
>
> On 8/25/20 12:16 PM, Vít Ondruch wrote:
>> Dne 25. 08. 20 v 11:40 Petr Menšík napsal(a):
>>> Hi Vít,
>>>
>>> Unfortunately your workaround does not on my rawhide container. I think
>>> the problem is in missing gpg keys from fedora-gpg-keys, which do not
>>> contain also architecture specific keys.
>>>
>>> # rpm -q fedora-repos fedora-repos-rawhide fedora-gpg-keys
>>> fedora-repos-33-0.9.noarch
>>> fedora-repos-rawhide-33-0.9.noarch
>>> fedora-gpg-keys-33-0.9.noarch
>>>
>>> # sudo dnf -y --enablerepo=updates --enablerepo=rawhide update
>>> fedora-gpg-keys
>>
>> The `--enablerepo=rawhide` is the issue IMO.
>>
>> You should understand, that Rawhide up to the branching point was F33
>> and signed by F33 key. So first you need to update to at least
>> fedora-gpg-keys-33-0.9.noarch.rpm (and note the '33' there), which is
>> signed by known F33 key but already contains the F34 key. Since that
>> point you can use F34 packages signed by F34 key.
> No, it should have worked this way, but it did not. Made pull request
> for f32 update [2]. It should be done also for f31, if there is still
> time for that.
>
>>
>> Vít
>>
>>
>>> Last metadata expiration check: 0:54:22 ago on Tue Aug 25 10:24:53 2020.
>>> Dependencies resolved.
>>> =
>>>  Package   Architecture
>>> Version  Repository Size
>>> =
>>> Upgrading:
>>>  fedora-gpg-keys   noarch
>>> 34-0.2   rawhide   105 k
>>>
>>> Transaction Summary
>>> =
>>> Upgrade  1 Package
>>>
>>> Total size: 105 k
>>> Downloading Packages:
>>> [SKIPPED] fedora-gpg-keys-34-0.2.noarch.rpm: Already downloaded
>>>
>>> warning:
>>> /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/fedora-gpg-keys-34-0.2.noarch.rpm:
>>> Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
>>> Fedora - Rawhide - Developmental packages for the next Fedora release
>>>  1.6 MB/s | 1.6 kB 00:00
>>> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
>>> (0x9570FF31) is already installed
>>> The GPG keys listed for the "Fedora - Rawhide - Developmental packages
>>> for the next Fedora release" repository are already installed but they
>>> are not correct for this package.
>>> Check that the correct key URLs are configured for this repository..
>>> Failing package is: fedora-gpg-keys-34-0.2.noarch
>>>  GPG Keys are configured as:
>>> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
>>> The downloaded packages were saved in cache until the next successful
>>> transaction.
>>> You can remove cached packages by executing 'dnf clean packages'.
>>> Error: GPG check FAILED
>>>
>>> I have complained two release before and this is still the same. It
>>> always break on new release. The only option now is to install it by
>>> hand from koji, where it is not yet signed (yuck!)
>>>
>>> # dnf install
>>> https://kojipkgs.fedoraproject.org//packages/fedora-repos/34/0.2/noarch/fedora-gpg-keys-34-0.2.noarch.rpm
>>>
>>> Then your commands would work, followed by normal upgrade.
>>>
>>> Filled bug #1872248 for it. It should finally work without user even
>>> fiddling with gpg keys manually. Is there some pressure to keep users
>>> from using rawhide?
>>>
>>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248

Non-responsive maintainer: tmoertel

[Robbie Harwood]

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?id=1572360
https://bugzilla.redhat.com/show_bug.cgi?id=1292482

So, does anyone know how to contact Tom?

Thanks,
--Robbie

1: 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/


signature.asc
Description: PGP signature
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1869726] perl-Getopt-Long-2.52 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1869726



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2020-d51b4bbc27 has been pushed to the Fedora 32 Modular stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1af9888c22   
golang-1.15-1.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

php-horde-Horde-Core-2.31.15-1.el6
php-horde-imp-6.2.27-1.el6
pspg-3.1.3-1.el6

Details about builds:



 php-horde-Horde-Core-2.31.15-1.el6 (FEDORA-EPEL-2020-84711fb527)
 Horde Core Framework libraries

Update Information:

**Horde_Core 2.31.15**  * [mjr] Fix ActiveSync SmartForward handling.

ChangeLog:

* Fri Aug 28 2020 Remi Collet  - 2.31.15-1
- update to 2.31.15




 php-horde-imp-6.2.27-1.el6 (FEDORA-EPEL-2020-53ec4aba67)
 A web based webmail system

Update Information:

**imp 6.2.27**  * [mjr] Fix attachments disappearing when forwarding in PHP 7.4
(Bug #15031). * [mjr] Prevent creating an empty To: header (Bug #15019). * |+

ChangeLog:

* Fri Aug 28 2020 Remi Collet  - 6.2.27-1
- update to 6.2.27




 pspg-3.1.3-1.el6 (FEDORA-EPEL-2020-2f125922be)
 A unix pager optimized for psql

Update Information:

new upstream release, per release notes:  -
https://github.com/okbob/pspg/releases/tag/3.1.3 -
https://github.com/okbob/pspg/releases/tag/3.1.2 -
https://github.com/okbob/pspg/releases/tag/3.1.1 -
https://github.com/okbob/pspg/releases/tag/3.0.7 -
https://github.com/okbob/pspg/releases/tag/3.0.6

ChangeLog:

* Fri Aug 28 2020 Pavel Raiskup  - 3.1.3-1
- new upstream release, per release notes:
  https://github.com/okbob/pspg/releases/tag/3.1.3
  https://github.com/okbob/pspg/releases/tag/3.1.2
  https://github.com/okbob/pspg/releases/tag/3.1.1
  https://github.com/okbob/pspg/releases/tag/3.0.7
  https://github.com/okbob/pspg/releases/tag/3.0.6
* Tue Jul 28 2020 Fedora Release Engineering  - 
3.0.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

References:

  [ 1 ] Bug #1826790 - pspg-3.1.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1826790


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1869106] perl-Importer-0.026 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1869106



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2020-d51b4bbc27 has been pushed to the Fedora 32 Modular stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1869106] perl-Importer-0.026 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1869106



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2020-9f03413d40 has been pushed to the Fedora 31 Modular stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1869726] perl-Getopt-Long-2.52 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1869726



--- Comment #11 from Fedora Update System  ---
FEDORA-MODULAR-2020-9f03413d40 has been pushed to the Fedora 31 Modular stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fwd: Re: CppunitTest_sw_htmlexport failing due to zlib variation?

[Jeremy Linton]

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 zlib.  (Though the resulting 
images look rather identical.  Full thread starting at 
 
"CppunitTest_sw_htmlexport failing due to zlib variation?")


Given the Fedora zlib aarch64 optimization patches quoted below:  Does 
anybody know whether it is indeed the case that the above scenario 
(client code using zlib to generate a PNG image) can legitimately 
generate varying output depending on zlib implementation details?  Or 
would that rather indicate a bug somewhere?


Yes, the short answer is that it is possible to create valid zlib 
archives that vary depending on the exact zlib implementation or 
compression setting. This is even part of the library's compression 
level (Z_BEST_SPEED vs Z_BEST_COMPRESSION) selection.


If one is trying to test a compression function the best way to test it 
is to turn around and decompress the output and compare it with the 
original rather than checking that the output from a compressor hasn't 
changed.


The zlib patches in fedora are an attempt to gain a bit of performance 
on an algorithm that compared with more modern algorithm/implementations 
is frightfully slow without any significant upside on the compression 
ratio. A lot of the byte oriented code runs poorly on modern cores. 
Looking at the fedora patches, there appears to be a s390 patch 
offloading the whole thing to hardware. This isn't just a arm/s390 
problem either as IIRC there were x86 perf fixes posted as well that 
haven't been merged either.






Thanks,
Stephan


 Forwarded Message 
Subject: Re: CppunitTest_sw_htmlexport failing due to zlib variation?
Date: Wed, 26 Aug 2020 08:37:15 +0200
From: Stephan Bergmann 
To: libreoff...@lists.freedesktop.org

On 25/08/2020 11:07, Stephan Bergmann wrote:
At least when building recent master on recent Fedora rawhide aarch64 
with (among others) --with-system-zlib, CppunitTest_sw_htmlexport 
fails with

[...]
The base64-encoded payload apparently is a PNG image.  And from what 
little I know about PNG, it looks plausible to me that there can be 
different (compressed) PNG content that decompress to identical raw 
data, and that the LibreOffice code would be allowed to generate 
differing (compressed) PNG content for the above data:image/png URL 
payload.


What supports the theory that "the LibreOffice code would be allowed to 
generate differing (compressed) PNG content" is the Fedora zlib commit 
 
"aarch64 optimizations", adding lots of code that presumably is only 
relevant for aarch64 and presumably changes details of the compression 
algorithm.



___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

[Martin Gansser]

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: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1843866] perl-Mango-1.30-7.fc33 FTBFS: t/bson.t: Failed test 'successful roundtrip'

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1843866



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-4a08a623d2 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-4a08a623d2`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-4a08a623d2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

[Tomasz Torcz]

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.1-5.fc32, and the spec has BR >= 2.4.3.

  For Rawhide, you just built vdr-2.4.4-1.fc34 yesterday – it may not be
available in Rawhide compose yet.


-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

[Martin Gansser]

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.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-33-20200828.n.0 compose check report

[Fedora compose checker]

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.0):

ID: 649972  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/649972
ID: 649978  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/649978
ID: 650010  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/650010
ID: 650020  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/650020
ID: 650021  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/650021
ID: 650051  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/650051
ID: 650078  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/650078
ID: 650079  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/650079

Soft failed openQA tests: 92/181 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-33-20200827.n.0):

ID: 649961  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/649961

Old soft failures (same test soft failed in Fedora-33-20200827.n.0):

ID: 649901  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/649901
ID: 649902  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/649902
ID: 649904  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/649904
ID: 649905  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/649905
ID: 649906  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/649906
ID: 649907  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/649907
ID: 649908  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/649908
ID: 649909  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/649909
ID: 649912  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/649912
ID: 649913  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/649913
ID: 649914  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/649914
ID: 649915  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/649915
ID: 649930  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/649930
ID: 649936  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/649936
ID: 649941  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/649941
ID: 649942  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/649942
ID: 649946  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/649946
ID: 649947  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/649947
ID: 649959  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/649959
ID: 649982  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/649982
ID: 649983  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/649983
ID: 649993  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/649993
ID: 65  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/65
ID: 650001  Test: x86_64 universal install_blivet_with_swap
URL: https://openqa.fedoraproject.org/tests/650001
ID: 650002  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/650002
ID: 650004  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/650004
ID: 650005  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/650005
ID: 650007  Test: x86_64 universal upgrade_2_minimal_64bit
URL: 

fedora-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

[Martin Gansser]

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_EPOCH=1598313600
Wrote: /builddir/build/SRPMS/vdr-skinelchihd-0.5.0-1.fc34.src.rpm
Child return code was: 0
Mock Version: 2.4

.. that's all I get in the build.log

How can i solve this ?

Regards
Martin
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Future of shared-mime-info in Fedora

[Bastien Nocera]

- 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 maintained the upstream shared-mime-info for 16 years, and
> > now is the time to let others in the community maintain it, both upstream
> > and downstream. It is still absolutely required, but it's not important
> > enough to be able to set time aside for.
> 
> Understood.
> 
> > As for the mimeapps.list, you might need to peruse the shared-mime-info
> > specifications, which explain what the different files do:
> > https://specifications.freedesktop.org/
> 
> How is the list maintained in Fedora? Is there some working group (e.g.
> workstation) overseeing this or is it just the shared-mime-info package
> maintainer? Or is it Rex as indicated in
> https://lists.fedoraproject.org/pipermail/devel/2015-July/212403.html ?

It used to a direct copy of the Workstation (GNOME) defaults. Now it's a copy
of nothing, and folks that care about it can ask the new maintainer for
changes.

The GNOME/Workstation defaults now live in the gnome-desktop3 package. I'd
encourage other desktops to ship their own mimeapps.list files to set defaults,
and leave the mimeapps.list in shared-mime-info well alone (it shouldn't
be needed, but "it broke things" not to have, and I never actually knew what
it broke).
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Future of shared-mime-info in Fedora

[Miro Hrončok]

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, and
now is the time to let others in the community maintain it, both upstream
and downstream. It is still absolutely required, but it's not important
enough to be able to set time aside for.


Understood.


As for the mimeapps.list, you might need to peruse the shared-mime-info
specifications, which explain what the different files do:
https://specifications.freedesktop.org/


How is the list maintained in Fedora? Is there some working group (e.g. 
workstation) overseeing this or is it just the shared-mime-info package 
maintainer? Or is it Rex as indicated in

https://lists.fedoraproject.org/pipermail/devel/2015-July/212403.html ?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 33 compose report: 20200828.n.0 changes

[Fedora Rawhide Report]

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 upgraded packages:   60.82 KiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   802 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-33-20200828.n.0.iso

= DROPPED IMAGES =
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-33-20200827.n.0-sda.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: geronimo-interceptor-1.0.1-24.fc33
Summary: Java EE: Interceptor API v3.0
RPMs:geronimo-interceptor geronimo-interceptor-javadoc
Size:275.13 KiB

Package: geronimo-jaxrpc-2.1-27.fc33
Summary: Java EE: Java API for XML Remote Procedure Call v1.1
RPMs:geronimo-jaxrpc geronimo-jaxrpc-javadoc
Size:364.13 KiB

Package: istack-commons-3.0.11-1.fc33
Summary: Common code for some Glassfish projects
RPMs:import-properties-plugin istack-commons istack-commons-buildtools 
istack-commons-maven-plugin istack-commons-runtime istack-commons-soimp 
istack-commons-test istack-commons-tools
Size:250.22 KiB


= UPGRADED PACKAGES =
Package:  appliance-tools-011.1-1.fc33
Old package:  appliance-tools-010.2-1.fc33
Summary:  Tools for building Appliances
RPMs: appliance-tools
Size: 60.82 KiB
Size change:  802 B
Changelog:
  * Wed Aug 26 2020 Neal Gompa  - 010.2-2
  - Add proposed patch to fix configuring fstab and grub for btrfs (#1855034)

  * Wed Aug 26 2020 Neal Gompa  - 010.2-3
  - Refresh patches for fixing bootloader config for btrfs

  * Wed Aug 26 2020 Neal Gompa  - 011.0-1
  - Update to 011.0 release
  - Drop merged patches

  * Thu Aug 27 2020 Neal Gompa  - 011.1-1
  - Update to 011.1 release



= DOWNGRADED PACKAGES =
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Future of shared-mime-info in Fedora

[Bastien Nocera]

- 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 maintained the upstream shared-mime-info for 16 years, and
now is the time to let others in the community maintain it, both upstream
and downstream. It is still absolutely required, but it's not important
enough to be able to set time aside for.

As for the mimeapps.list, you might need to peruse the shared-mime-info
specifications, which explain what the different files do:
https://specifications.freedesktop.org/

Did I miss anything?

> 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/xdg/shared-mime-info/-/commit/6f4947b01
> 
> I've disregarded the idea the the package was orphaned by accident.
> 
> I also see that GNOME mime types have been moved away from the package (on
> rawhide only):
> 
> https://src.fedoraproject.org/rpms/shared-mime-info/c/da05922d10
> https://src.fedoraproject.org/rpms/gnome-desktop3/c/9909d22b
> 
> I always considered shared-mime-info an important package, however I don't
> see
> it in comps. Maybe it is no longer that important?
> 
> A repoquery reveals ~50 packages that require it including PackageKit, Thunar
> (Xfce), some NetworkManager packages, kdelibs (KDE)...
> 
> A recursive repoquery yields ~ 6650 packages.
> 
> I've taken the orphaned package for now to avoid any disruption (and a
> totally
> unreadable orphans report), but I don't really understand the Fedora package,
> it
> has a manually created source without any comment explaining where is this
> from:
> 
> https://src.fedoraproject.org/rpms/shared-mime-info/blob/master/f/mimeapps.list
> 
> Bastien, could you please give me a hint about this file? Thanks
> 
> -
> 
> The package technically has 8 co-maintainers and a sig, but I don't put much
> hopes into the crowd there considering they haven't touched the package in
> years.
> 
> Are there any interested Fedora packages that understand mime info better
> than I do
> 
> -
> 
> PS There is an interesting file-ownership problem reported in Bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1486468 - I plan to discuss this
> later on the packaging mailing list as well.
> 
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> 
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-31-20200828.0 compose check report

[Fedora compose checker]

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.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-IoT-33-20200828.0 compose check report

[Fedora compose checker]

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, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-33-20200826.0):

ID: 649878  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/649878
ID: 649879  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/649879

Passed openQA tests: 13/16 (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.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] Re: Odd behaviour in import

[Ludwig Krispenz]

On 27.08.20 04:01, William Brown wrote:

Hey there,

I'm seeing some odd behaviour in an import test. I'm seeing that a large number 
of entries won't import unless the directory is restarted before the import 
task is performed.

The error appears to be:

[25/Aug/2020:14:14:58.973490600 +1000] - WARN - import_foreman - import userRoot: Skipping entry 
"cn=group0,ou=Groups,dc=example,dc=com" which has no parent, ending at line 154 of file 
"/opt/dirsrv/var/lib/dirsrv/slapd-standalone1/ldif/4f8afb8d-ec97-4246-94a2-ec343c0eacb4.ldif"
...
[25/Aug/2020:14:14:59.307477400 +1000] - INFO - bdb_import_main - import 
userRoot: Import complete.  Processed 14 entries (10 were skipped) in 1 
seconds. (14.00 entries/sec)


This is where a newly created backend *with* example entries, then has it's 
entire content overwriten during an import. Anything that is underneath the 
ou=* entries is not imported, but the ou= and dc=are fine.

I'm wondering if this is something related to the fact we are replacing the ou= 
entries with different ids/nsunique ids. IE

id 3
rdn: ou=groups
objectClass: top
objectClass: organizationalunit
ou: groups
aci: (targetattr="cn || member || gidNumber || nsUniqueId || 
description || ob
 jectClass")(targetfilter="(objectClass=groupOfNames)")(version 3.0; acl 
"Enab
 le anyone group read"; allow (read, search, 
compare)(userdn="ldap:///anyone;)
 ;)
aci: 
(targetattr="member")(targetfilter="(objectClass=groupOfNames)")(version
 3.0; acl "Enable group_modify to alter members"; allow 
(write)(groupdn="ldap:
 ///cn=group_modify,ou=permissions,dc=example,dc=com");)
aci: (targetattr="cn || member || gidNumber || description || 
objectClass")(ta
 rgetfilter="(objectClass=groupOfNames)")(version 3.0; acl "Enable 
group_admin
  to manage groups"; allow (write, add, 
delete)(groupdn="ldap:///cn=group_admi
 n,ou=permissions,dc=example,dc=com");)
creatorsName: cn=directory manager
modifiersName: cn=directory manager
createTimestamp: 20200827015033Z
modifyTimestamp: 20200827015033Z
nsUniqueId: b0fce42b-e80711ea-8141c872-2df18128
parentid: 1
entryid: 3
numSubordinates: 1

Becomes:

id 4
rdn: ou=Groups
createTimestamp: 20200224023755Z
creatorsName: cn=Manager,dc=example,dc=com
entryUUID: 67cc2212-eafa-1039-8830-152569770969
modifiersName: cn=Manager,dc=example,dc=com
modifyTimestamp: 20200224023755Z
objectClass: organizationalUnit
objectClass: top
ou: Groups
nsUniqueId: 87b64988-e68911ea-a943c898-6d74ab17
parentid: 1
entryid: 4


Given that these id's are changing I'm wondering if this is somehow breaking 
our import ordering? Any ideas on where I should start to investigate this?
shouldn't the nsuniqueid be preserved ? Otherwise you could not use 
import to initilaize a replica.


Thanks!

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Fedora-Cloud-32-20200828.0 compose check report

[Fedora compose checker]

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.fedoraproject.org/tests/649871

Passed openQA tests: 6/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.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RE: Query on upgrading the Fedora package

[Muneendra Kumar M via devel]

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.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 Guidelines if you're unsure [1][2].

Personally, I disable all automatic pushing to stable for EPEL, because I
try to align updates there with major updates to the underlying CentOS/RHEL
release & give it enough time in Fedora to iron out any issues - the package
will still be available in the testing repo for those who like to try it
early.

Best,
Christopher

[1] https://fedoraproject.org/wiki/EPEL_Updates_Policy
[2] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Query on upgrading the Fedora package

[Christopher Engelhard]

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 Guidelines if you're unsure [1][2].

Personally, I disable all automatic pushing to stable for EPEL, because
I try to align updates there with major updates to the underlying
CentOS/RHEL release & give it enough time in Fedora to iron out any
issues - the package will still be available in the testing repo for
those who like to try it early.

Best,
Christopher

[1] https://fedoraproject.org/wiki/EPEL_Updates_Policy
[2] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HOWTO] Keep using Rawhide after branching

[Petr Menšík]

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/20 11:40, Petr Menšík ha scritto:
>> Hi Vít,
>>
>> Unfortunately your workaround does not on my rawhide container.
>> ...
> 
> I just did
> 
> ~~~
> 
> $ sudo dnf update fedora-gpg-keys --nogpgcheck
> 
> $ sudo dnf update fedora-repos --release 34
> 
> ~~~
> 
> ___
> 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.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.asc
Description: OpenPGP digital signature
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RE: Query on upgrading the Fedora package

[Muneendra Kumar M via devel]

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.



-Original Message-
From: Christopher Engelhard [mailto:c...@lcts.de]
Sent: Friday, August 28, 2020 1:45 PM
To: Development discussions related to Fedora

Subject: Re: Query on upgrading the Fedora package

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 repositories.

See here the documentation [1][2] for more info.

Christopher

[1]
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#bodhi-enabling
[2] https://fedoraproject.org/wiki/Package_maintenance_guide
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Galera FTBFS in f33, but same build passes in f32

[Lukas Javorsky]

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
> > > should review the code for real issues.
>
> as others already mentioned - there is a problem in the project's source
> code with the fail_*() functions leading to a compiler warning that's
> turned into an error by -Werror.
>
>
> Dan
>
> > 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: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
> > > >
> > > > And here is the same build, but on Fedora 33:
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=50232498
> > > >
> > > > Does anyone know what could cause this?
> > > > It looks like something that changed in *cc1plus* or *scons *is
> causing
> > > > this, so if you had similar issue, please let me know.
> > >
> > > 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.
> > >
> > >
> > > Dan
> > >
> > > [1] https://fedoraproject.org/wiki/LTOByDefault
> > > ___
> > > 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.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > >
> >
> >
> > --
> > S pozdravom/ Best regards
> >
> > Lukas Javorsky
> >
> > Intern, Core service - Databases
> >
> > Red Hat 
> >
> > Purkyňova 115 (TPB-C)
> >
> > 612 00 Brno - Královo Pole
> >
> > ljavo...@redhat.com
> > 
> ___
> 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.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
S pozdravom/ Best regards

Lukas Javorsky

Intern, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Query on upgrading the Fedora package

[Christopher Engelhard]

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 repositories.

See here the documentation [1][2] for more info.

Christopher

[1]
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#bodhi-enabling
[2] https://fedoraproject.org/wiki/Package_maintenance_guide
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Galera FTBFS in f33, but same build passes in f32

[Dan Horák]

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 in the project's source
code with the fail_*() functions leading to a compiler warning that's
turned into an error by -Werror.


Dan
 
> 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: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
> > >
> > > And here is the same build, but on Fedora 33:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=50232498
> > >
> > > Does anyone know what could cause this?
> > > It looks like something that changed in *cc1plus* or *scons *is causing
> > > this, so if you had similar issue, please let me know.
> >
> > 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.
> >
> >
> > Dan
> >
> > [1] https://fedoraproject.org/wiki/LTOByDefault
> > ___
> > 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.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> 
> 
> -- 
> S pozdravom/ Best regards
> 
> Lukas Javorsky
> 
> Intern, Core service - Databases
> 
> Red Hat 
> 
> Purkyňova 115 (TPB-C)
> 
> 612 00 Brno - Královo Pole
> 
> ljavo...@redhat.com
> 
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RE: Query on upgrading the Fedora package

[Muneendra Kumar M via devel]

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 related to Fedora'

Cc: 'c...@lcts.de' ; 'Jonathan Wakely'
; 'Josef Ridky' 
Subject: RE: Query on upgrading the Fedora package

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

Release Stable versionFedora
34  fctxpd-0.2-1.20200827gitccbaf3a.fc34Fedora
31  fctxpd-0.1-1.20190813gitc195e67.fc31Fedora
EPEL 8  fctxpd-0.1-1.20190813gitc195e67.el8 <== this is to be
fctxpd-0.2-1.20200827gitccbaf3a.el8Steps:
fedpkg clone fctxpd
 cd fctxpd/
 git branch
 fedpkg switch-branch epel8
 git branch
 git merge master
 fedpkg push
 fedpkg build


Could you please help me on the same.

Regards,
Muneendra.


-Original Message-
From: Christopher Engelhard [mailto:c...@lcts.de]
Sent: Thursday, August 27, 2020 6:04 PM
To: devel@lists.fedoraproject.org
Subject: Re: Query on upgrading the Fedora package

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 the old EPEL builds) just merging master and
building should work.

If there are incompatibilities you can either adapt the spec after merging
or deal with them with conditionals in the master spec file.

Christopher
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Galera FTBFS in f33, but same build passes in f32

[Lukas Javorsky]

> 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: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
> >
> > And here is the same build, but on Fedora 33:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=50232498
> >
> > Does anyone know what could cause this?
> > It looks like something that changed in *cc1plus* or *scons *is causing
> > this, so if you had similar issue, please let me know.
>
> 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.
>
>
> Dan
>
> [1] https://fedoraproject.org/wiki/LTOByDefault
> ___
> 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.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
S pozdravom/ Best regards

Lukas Javorsky

Intern, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RE: Query on upgrading the Fedora package

[Muneendra Kumar M via devel]

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

Release Stable versionFedora
34  fctxpd-0.2-1.20200827gitccbaf3a.fc34Fedora
31  fctxpd-0.1-1.20190813gitc195e67.fc31Fedora
EPEL 8  fctxpd-0.1-1.20190813gitc195e67.el8 <== this is to be
fctxpd-0.2-1.20200827gitccbaf3a.el8Steps:
fedpkg clone fctxpd
 cd fctxpd/
 git branch
 fedpkg switch-branch epel8
 git branch
 git merge master
 fedpkg push
 fedpkg build


Could you please help me on the same.

Regards,
Muneendra.


-Original Message-
From: Christopher Engelhard [mailto:c...@lcts.de]
Sent: Thursday, August 27, 2020 6:04 PM
To: devel@lists.fedoraproject.org
Subject: Re: Query on upgrading the Fedora package

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 the old EPEL builds) just merging master and
building should work.

If there are incompatibilities you can either adapt the spec after merging
or deal with them with conditionals in the master spec file.

Christopher
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Future of shared-mime-info in Fedora

[Miro Hrončok]

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/xdg/shared-mime-info/-/commit/6f4947b01

I've disregarded the idea the the package was orphaned by accident.

I also see that GNOME mime types have been moved away from the package (on 
rawhide only):


https://src.fedoraproject.org/rpms/shared-mime-info/c/da05922d10
https://src.fedoraproject.org/rpms/gnome-desktop3/c/9909d22b

I always considered shared-mime-info an important package, however I don't see 
it in comps. Maybe it is no longer that important?


A repoquery reveals ~50 packages that require it including PackageKit, Thunar 
(Xfce), some NetworkManager packages, kdelibs (KDE)...


A recursive repoquery yields ~ 6650 packages.

I've taken the orphaned package for now to avoid any disruption (and a totally 
unreadable orphans report), but I don't really understand the Fedora package, it 
has a manually created source without any comment explaining where is this from:


https://src.fedoraproject.org/rpms/shared-mime-info/blob/master/f/mimeapps.list

Bastien, could you please give me a hint about this file? Thanks

-

The package technically has 8 co-maintainers and a sig, but I don't put much 
hopes into the crowd there considering they haven't touched the package in years.


Are there any interested Fedora packages that understand mime info better than 
I do

-

PS There is an interesting file-ownership problem reported in Bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1486468 - I plan to discuss this 
later on the packaging mailing list as well.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fwd: Re: CppunitTest_sw_htmlexport failing due to zlib variation?

[Stephan Bergmann]

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 identical.  Full thread starting at 
 
"CppunitTest_sw_htmlexport failing due to zlib variation?")


Given the Fedora zlib aarch64 optimization patches quoted below:  Does 
anybody know whether it is indeed the case that the above scenario 
(client code using zlib to generate a PNG image) can legitimately 
generate varying output depending on zlib implementation details?  Or 
would that rather indicate a bug somewhere?


Thanks,
Stephan


 Forwarded Message 
Subject: Re: CppunitTest_sw_htmlexport failing due to zlib variation?
Date: Wed, 26 Aug 2020 08:37:15 +0200
From: Stephan Bergmann 
To: libreoff...@lists.freedesktop.org

On 25/08/2020 11:07, Stephan Bergmann wrote:
At least when building recent master on recent Fedora rawhide aarch64 
with (among others) --with-system-zlib, CppunitTest_sw_htmlexport fails 
with

[...]
The base64-encoded payload apparently is a PNG image.  And from what 
little I know about PNG, it looks plausible to me that there can be 
different (compressed) PNG content that decompress to identical raw 
data, and that the LibreOffice code would be allowed to generate 
differing (compressed) PNG content for the above data:image/png URL 
payload.


What supports the theory that "the LibreOffice code would be allowed to 
generate differing (compressed) PNG content" is the Fedora zlib commit 
 
"aarch64 optimizations", adding lots of code that presumably is only 
relevant for aarch64 and presumably changes details of the compression 
algorithm.

___
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.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org