Re: Unretire gjots2 (gtk heirarchical note jotter)

[Bob Hepple]

Thanks Alexander,

I am (recently) a member of the packagers group - just finding my feet!

I have done the review request here:
https://bugzilla.redhat.com/show_bug.cgi?id=1823599

I also made a request on releng to resurrect the git repo for f-31, 32 & epel8


Cheers


Bob

On Tue, 14 Apr 2020 at 11:27, Alexander Ploumistos
 wrote:
>
> Hello Bob,
>
> On Tue, Apr 14, 2020 at 3:12 AM Bob Hepple  wrote:
> > I'd like to unretire the package gjots2 package
> > Full disclosure - I'm upstream. The package has been updated to python3
>
> Since gjots2 had been orphaned quite some time ago, it will need to be
> reviewed again:
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers
>
> If you are not already a member of the packagers group, the procedure
> in order to join is outlined here:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
>
> Best regards,
> A.
> ___
> 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: Unretire gjots2 (gtk heirarchical note jotter)

[Alexander Ploumistos]

Hello Bob,

On Tue, Apr 14, 2020 at 3:12 AM Bob Hepple  wrote:
> I'd like to unretire the package gjots2 package
> Full disclosure - I'm upstream. The package has been updated to python3

Since gjots2 had been orphaned quite some time ago, it will need to be
reviewed again:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

If you are not already a member of the packagers group, the procedure
in order to join is outlined here:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Best regards,
A.
___
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: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

[Richard Shaw]

On Mon, Apr 13, 2020 at 8:05 PM Scott Talbert  wrote:

>
> Have you tried the py3 branch of chirp?
> https://chirp.danplanet.com/projects/chirp/repository/show?rev=py3


Not in some time. From a packager POV I have no way to tell if it's ready
for "prime time" and I don't want to be responsible for bricking anyone's
radio.

So the last commit seems to be from Feb, so newer than I was expecting, but
it's now April...

Thanks,
Richard
___
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

Unretire gjots2 (gtk heirarchical note jotter)

[Bob Hepple]

I'd like to unretire the package gjots2 package

Full disclosure - I'm upstream. The package has been updated to python3
___
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: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

[Scott Talbert]

On Mon, 13 Apr 2020, Michael Catanzaro wrote:


So how do I get a functional python2 interpreter and access to pip?


As a short-term solution, you can switch the runtime-version in your manifest 
to 18.08, but this runtime will only be supported for four more months, until 
August (when the 20.08 runtime is released), so users will start to see EOL 
warnings soon if you take that approach. Each version of freedesktop-sdk is 
supported for two years, and freedesktop-sdk 19.08 is a python3-only runtime.


If porting to python3 is not an option, and you don't want to accept that the 
app is dead (if upstream is not interested in python3, it certainly seems 
that way), then you can *try* to build python2 in your manifest. I'm not sure 
if anyone has successfully done that before, but in theory it could work.


Have you tried the py3 branch of chirp?
https://chirp.danplanet.com/projects/chirp/repository/show?rev=py3

Scott
___
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: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

[Michael Catanzaro]

On Mon, Apr 13, 2020 at 5:52 pm, Richard Shaw  
wrote:

So how do I get a functional python2 interpreter and access to pip?


As a short-term solution, you can switch the runtime-version in your 
manifest to 18.08, but this runtime will only be supported for four 
more months, until August (when the 20.08 runtime is released), so 
users will start to see EOL warnings soon if you take that approach. 
Each version of freedesktop-sdk is supported for two years, and 
freedesktop-sdk 19.08 is a python3-only runtime.


If porting to python3 is not an option, and you don't want to accept 
that the app is dead (if upstream is not interested in python3, it 
certainly seems that way), then you can *try* to build python2 in your 
manifest. I'm not sure if anyone has successfully done that before, but 
in theory it could work.


___
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: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

[Blaise Pabon]

Hi Richard,
I'm, a CHIRP user (even spotted Dan some cash) and I would love to see it
it Fedora since it's "gateway app" for some many new HAMs.
I didn't know this was a problem and I would welcome an opportunity to help.
Feel free to contact me (blaise at gmail)

Neal,
Thanks for the info on Fedora Flatpaks, I didn't know there was a
difference!

-Blaise

On Mon, Apr 13, 2020 at 4:18 PM Neal Gompa  wrote:

> On Mon, Apr 13, 2020 at 6:53 PM Richard Shaw  wrote:
> >
> > So with Python 2 being fully removed (more or less) with Fedora 32,
> Fedora 31 is the last version that will contain Chirp, which is an
> important and the ONLY tool for Amateur Radio operators to program radios
> in linux.
> >
> > Don't get me started on upstreams lack of interest on correcting the
> issue...
> >
> > So I decided to look at flatpaks as a method of making it available post
> Fedora 31.
> >
> > 1. The documentation sucks. You see code snippets everywhere and it's
> not clear what section it belongs in the json file, which leads me to #2.
> >
> > 2. JSON may be fine for machine readability but it SUCKS for human
> readability. Both brackets and braces! Do I need a "," after that one? All
> I know is I screw around with it until vim doesn't show me any more red
> highlights.
> >
> > Yes, you can do YAML instead, which is FAR more readable, but MOST of
> the examples are in JSON.
> >
> > 3. I understand the names (app-id) need to be unique, but how about some
> better guidance on how to name them!
> >
> > 4. Examples show you how to execute "pip..." to install python
> dependencies, but they don't show you what you need to include SDK wise so
> a python interpreter is available! I've googles references that you need
> the correct SDK, but "flatpak search" doesn't return those.
> >
>
> You've more or less hit the nail on the head for why I've personally
> not been interested in Flatpaks. There's definitely some cool
> technology there, but clearly it's not made for humans to work with.
> It feels like you need too much built-in knowledge and understanding
> of the pieces below you that do automagic to be able to use it well.
> In essence, it feels a lot like how Debian packaging tooling feels to
> me (in the bad ways).
>
> I try to avoid talking about this much, because historically I haven't
> felt that my opinion would be valued there, but as a game developer of
> an open source game, these kinds of things have held some degree of
> interest for me. I considered making a Flatpak, and later taking over
> the Flatpak in Flathub once one became available, but I absolutely
> abhor the experience for developing and maintaining Flatpaks. As you
> noted, the experience for developing Flatpaks is pretty bad. The
> experience for Flathub indicates that nobody has seriously thought
> about how a developer experience for producing and submitting Flatpaks
> should work. I mean, really? Submitting GitHub PRs to a "null repo"
> and then manually going through crap to transfer that into an
> individual repo, then closing the PR? That's seriously speaking to
> lack of interest in making a coherent and streamlined developer
> experience.
>
> Now all of these problems are only unique to the GNOME implementation
> of Flatpak. Fedora's implementation of Flatpak works a bit
> differently, leveraging the Modularity technology to get things
> working. With the Fedora implementation, there's still a few problems:
> * Everything *still* has to get built over and over, which is frankly
> quite dumb and wasteful, especially since we *know* what version of
> Fedora everything is built for. Reuse would be a major accelerator of
> adoption.
> * It is somewhat unclear how the build orchestration works. I know
> that a modulemd.yaml is involved and some kind of container build
> definition, but not much else.
> * The Flatpak naming restriction makes things get really ugly since
> you need to force to fit RDNN naming convention.
>
> The submission experience for new flatpaks is essentially the same as
> RPMs. So while not good, it's not entirely awful like the Flathub one
> is. Maybe one day that will be improved for RPMs, containers, modules,
> and Flatpaks...
>
> You may find that Fedora Flatpaks will be a better way to get your app
> built.
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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
>


-- 
LinkedIn   |  Quora
  |  Github

“If you want to go fast, go alone. If you want to go far, go
together.” --African

Re: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

[Neal Gompa]

On Mon, Apr 13, 2020 at 6:53 PM Richard Shaw  wrote:
>
> So with Python 2 being fully removed (more or less) with Fedora 32, Fedora 31 
> is the last version that will contain Chirp, which is an important and the 
> ONLY tool for Amateur Radio operators to program radios in linux.
>
> Don't get me started on upstreams lack of interest on correcting the issue...
>
> So I decided to look at flatpaks as a method of making it available post 
> Fedora 31.
>
> 1. The documentation sucks. You see code snippets everywhere and it's not 
> clear what section it belongs in the json file, which leads me to #2.
>
> 2. JSON may be fine for machine readability but it SUCKS for human 
> readability. Both brackets and braces! Do I need a "," after that one? All I 
> know is I screw around with it until vim doesn't show me any more red 
> highlights.
>
> Yes, you can do YAML instead, which is FAR more readable, but MOST of the 
> examples are in JSON.
>
> 3. I understand the names (app-id) need to be unique, but how about some 
> better guidance on how to name them!
>
> 4. Examples show you how to execute "pip..." to install python dependencies, 
> but they don't show you what you need to include SDK wise so a python 
> interpreter is available! I've googles references that you need the correct 
> SDK, but "flatpak search" doesn't return those.
>

You've more or less hit the nail on the head for why I've personally
not been interested in Flatpaks. There's definitely some cool
technology there, but clearly it's not made for humans to work with.
It feels like you need too much built-in knowledge and understanding
of the pieces below you that do automagic to be able to use it well.
In essence, it feels a lot like how Debian packaging tooling feels to
me (in the bad ways).

I try to avoid talking about this much, because historically I haven't
felt that my opinion would be valued there, but as a game developer of
an open source game, these kinds of things have held some degree of
interest for me. I considered making a Flatpak, and later taking over
the Flatpak in Flathub once one became available, but I absolutely
abhor the experience for developing and maintaining Flatpaks. As you
noted, the experience for developing Flatpaks is pretty bad. The
experience for Flathub indicates that nobody has seriously thought
about how a developer experience for producing and submitting Flatpaks
should work. I mean, really? Submitting GitHub PRs to a "null repo"
and then manually going through crap to transfer that into an
individual repo, then closing the PR? That's seriously speaking to
lack of interest in making a coherent and streamlined developer
experience.

Now all of these problems are only unique to the GNOME implementation
of Flatpak. Fedora's implementation of Flatpak works a bit
differently, leveraging the Modularity technology to get things
working. With the Fedora implementation, there's still a few problems:
* Everything *still* has to get built over and over, which is frankly
quite dumb and wasteful, especially since we *know* what version of
Fedora everything is built for. Reuse would be a major accelerator of
adoption.
* It is somewhat unclear how the build orchestration works. I know
that a modulemd.yaml is involved and some kind of container build
definition, but not much else.
* The Flatpak naming restriction makes things get really ugly since
you need to force to fit RDNN naming convention.

The submission experience for new flatpaks is essentially the same as
RPMs. So while not good, it's not entirely awful like the Flathub one
is. Maybe one day that will be improved for RPMs, containers, modules,
and Flatpaks...

You may find that Fedora Flatpaks will be a better way to get your app built.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Fedpkg: (scratch)-build forked repo directly in Koji

[clime]

On Tue, 14 Apr 2020 at 00:15, Ondrej Nosek  wrote:
>
> TLDR: Is $SUBJ function reasonable to implement in fedpkg?
>
> Hi,
>
> some time ago, fedpkg issue tracker got a request [1] for method, that allows 
> direct builds. That means without sending srpms via "--srpm" argument. 
> Currently, user's changes can be built:
>
> fedpkg scratch-build --srpm
>
> This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends just 
> (git) hash id to koji. But fedpkg needs modification to send a right hash id 
> for user changes. Additionally, koji doesn't allow building hash ids from 
> forked repos.
> The question to the community. Is reasonable to implement this way of 
> building scratches? --srpm argument would still work as previously.

Hello Ondrej,

I think it is reasonable given that koji implements a new config
option named something like: `allowed_scms_for_scratch` to explicitly
name uris allowed for scratch builds. It makes it clear what scms are
allowed for scratch builds and what are allowed for normal builds.

clime

>
> There is a suggested PR for this here: [2]. It is not completed yet.
>
> Risks:
> * approach could confuse users. Users are used to work with fedpkg 
> differently.
> * koji would have to allow these builds
> * more code complexity; currently there is a way how to reach your result 
> even without this function
>
> Thanks
> Ondrej
>
> [1] https://pagure.io/fedpkg/issue/282
> [2] https://pagure.io/fedpkg/pull-request/390
> ___
> 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

RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

[Richard Shaw]

So with Python 2 being fully removed (more or less) with Fedora 32,
Fedora 31 is the last version that will contain Chirp, which is an
important and the ONLY tool for Amateur Radio operators to program radios
in linux.

Don't get me started on upstreams lack of interest on correcting the
issue...

So I decided to look at flatpaks as a method of making it available post
Fedora 31.

1. The documentation sucks. You see code snippets everywhere and it's not
clear what section it belongs in the json file, which leads me to #2.

2. JSON may be fine for machine readability but it SUCKS for human
readability. Both brackets and braces! Do I need a "," after that one? All
I know is I screw around with it until vim doesn't show me any more red
highlights.

Yes, you can do YAML instead, which is FAR more readable, but MOST of the
examples are in JSON.

3. I understand the names (app-id) need to be unique, but how about some
better guidance on how to name them!

4. Examples show you how to execute "pip..." to install python
dependencies, but they don't show you what you need to include SDK wise so
a python interpreter is available! I've googles references that you need
the correct SDK, but "flatpak search" doesn't return those.

So I know I need the following (and their dependencies):
$ rpm -q --requires chirp | grep ^py
pygtk2
python(abi) = 2.7
python2-libxml2
python2dist(pyserial)
python2dist(suds-jurko)
python2dist(future)

So how do I get a functional python2 interpreter and access to pip?

I've gotten this far and pretty much stuck at this point:


"app-id": "org.flatpak.chirp",
"runtime": "org.freedesktop.Platform",
"runtime-version": "19.08",
"sdk": "org.freedesktop.Sdk",
"command": "chirpw",
"modules": [
{
"name": "chirp",
"buildsystem": "simple",
"build-commands": [
"pip install --prefix=/app pygtk2 future libxml2 pyserial
suds-jurko",
"/usr/bin/python2 setup.py  build
--executable='/usr/bin/python2 -s'",
"mkdir /app/share/applications",
"cp org.flatpak.chirp.desktop /app/share/applications/"
],
"sources": [
{
"type": "archive",
"url": "
http://trac.chirp.danplanet.com/chirp_daily/daily-20200409/chirp-daily-20200409.tar.gz
",
"sha256":
"98923aeece4c3e3b0ab9eb21e9de174104ec26e75be9583abeb3dcdac5e3f09b"
}
]
}
],
"finish-args": [
"--socket=x11",
"--socket=wayland",
"--share=network"
]
}


If I had to use JSON for packing for Fedora I think I would give up and
just be an end user again...

Thanks,
Richard
___
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

Fedpkg: (scratch)-build forked repo directly in Koji

[Ondrej Nosek]

TLDR: Is $SUBJ function reasonable to implement in fedpkg?

Hi,

some time ago, fedpkg issue tracker got a request [1] for method, that
allows direct builds. That means without sending srpms via "--srpm"
argument. Currently, user's changes can be built:

fedpkg scratch-build --srpm

This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends
just (git) hash id to koji. But fedpkg needs modification to send a right
hash id for user changes. Additionally, koji doesn't allow building hash
ids from forked repos.
The question to the community. Is reasonable to implement this way of
building scratches? --srpm argument would still work as previously.

There is a suggested PR for this here: [2]. It is not completed yet.

Risks:
* approach could confuse users. Users are used to work with fedpkg
differently.
* koji would have to allow these builds
* more code complexity; currently there is a way how to reach your result
even without this function

Thanks
Ondrej

[1] https://pagure.io/fedpkg/issue/282
[2] https://pagure.io/fedpkg/pull-request/390
___
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: Why does Koschei not run real builds?

[clime]

On Mon, 13 Apr 2020 at 19:23, clime  wrote:
>
> On Mon, 13 Apr 2020 at 14:48, Neal Gompa  wrote:
> >
> > On Mon, Apr 13, 2020 at 5:15 AM Fabio Valentini  
> > wrote:
> > >
> > > On Mon, Apr 13, 2020 at 10:55 AM Dan Čermák
> > >  wrote:
> > > >
> > > > Hi list,
> > > >
> > > > my question is pretty much $subject: Why doesn't Koschei kick of
> > > > real builds off packages on dependency changes? From my naive POV that
> > > > looks like the missing piece to give us the "OBS-experience". Having
> > > > that at least in Rawhide sounds like a good thing to me.
> > >
> > > It *might* be a good idea to help deal with rebuilds, but I see some
> > > problems with that.
> > >
> > > - koschei would need to add "rebuilt by koschei" commits to dist-git
> > > for this (OBS doesn't have a real VCS, so it's not a problem there)
> > > - those changes would add a lot of churn to .spec files, possibly
> > > angering a lot of packagers, and would also create possible conflicts
> > > between local changes and koschei builds
> > > - the builds add a lot of load to koji already (although at lower
> > > priority), which will probably be a problem when there's reduced
> > > capacity (e.g. the upcoming datacenter move)
> > >
> >
> > I think the fundamental premise here is that rebuilds this way
> > requires commits into Dist-Git.
>
> Assuming we have tooling for it, commits is not the only option. The
> other option might be tags. You don't create a new (potentially empty)
> commit, but instead, you create a new tag from koschei environment and
> if you succeed, you build that tag. That tag can also automatically
> populate changelog with the reason for rebuild.
>
> But then I think it would be good to have some name separation of the
> user tags vs. the koschei tags and technical details of this need to
> be figured out, i.e. it would require more discussion and
> brainstorming to determine if the separation is technically possible
> and how to do it.
>
> Both, the commit and the tag approach try to maintain dist-git as the
> single source of truth [1] to provide basic package information such
> as name-version-release, which is beneficial for local build
> reproducibility, it makes the result easier to calculate and predict,
> and it also makes services less intertwined.
>
> [1] https://en.wikipedia.org/wiki/Single_source_of_truth

Also, I actually like the option that you proposed here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ERTHZICHK56MGWLLEJ2GHR6S5UEHQCOC/

with adding/using an additional rpm property to determine uniqueness
in koji and to extend the rpm comparison algo to take that property
into account. So that property would be handled purely by build system
whereas NVR would be handled by git. I admit I am not a big fan of
services doing changes in user's git repos.

>
> > With what Pierre-Yves and his group
> > released last week for testing[1], that may no longer be an issue.
> >
> > [1]: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LWE4URIRWVTEZKXKP7QOK5JXFNVJRUNW/
> >
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> > ___
> > 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

[Bug 1803531] perl-Test-mysqld-1.0013 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-a9cc3de21c 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-a9cc3de21c`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a9cc3de21c

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

[Bug 1823526] New: bugzilla fails to build with Sphinx 3.0.0

[bugzilla]

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

Bug ID: 1823526
   Summary: bugzilla fails to build with Sphinx 3.0.0
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: bugzilla
  Assignee: ita...@ispbrasil.com.br
  Reporter: cstra...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: cstra...@redhat.com, emman...@seyman.fr,
ita...@ispbrasil.com.br, mhron...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 1783776
  Target Milestone: ---
Classification: Fedora



bugzilla fails to build with Sphinx 3.0.0.

This report is automated and not very verbose, but we'll try to get back here
with details.

For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/cstratak/sphinx_3.0.0/fedora-rawhide-x86_64/01335438-bugzilla/

For all our attempts to build bugzilla with Sphinx 3.0.0, see:
https://copr.fedorainfracloud.org/coprs/cstratak/sphinx_3.0.0/package/bugzilla/

Testing and mass rebuild of packages is happening in copr. You can follow these
instructions to test locally in mock if your package builds with Sphinx 3:
https://copr.fedorainfracloud.org/coprs/cstratak/sphinx_3.0.0/

Let us know here if you have any questions.

Sphinx 3 will be included in Fedora 33. To make that update smoother, we're
building the dependent packages in Copr.
We'd appreciate help from the people who know this package best, but if you
don't want to work on this now, let us know so we can try to work around it on
our side.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1783776
[Bug 1783776] python-sphinx-3.0.1 is available
-- 
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: ocaml-bisect-ppx and related updates

[Richard W.M. Jones]

On Mon, Apr 13, 2020 at 11:36:03AM -0600, Jerry James wrote:
> I would like to update the ocaml-bisect-ppx package to its latest
> version, 2.3.1.  It is currently on a post-1.4.1 git snapshot.  The
> new version requires ocaml-ppx-tools-versioned >= 5.3.0.  That
> requirement sets off a cascade of updates and rebuilds.  I am BCCing
> all of the affected package maintainers.  Here is what I would like to
> do, in the approximate order each would need to be done:

So semi-related to this, to get OCaml working on RISC-V again (a
Fedora secondary arch) we will need to at some point move to post-4.10
in Rawhide.

We've carried nojb's out of tree RISC-V patch in the OCaml package
since Nov 2016.  However he hasn't updated it for 4.10 (for various
good, but complicated technical reasons).  For this reason the OCaml
compiler doesn't work for RISC-V in Fedora 32 or Rawhide which have
OCaml 4.10.

To resolve this I'd like to use the upstream RISC-V patch which is
close to getting into the OCaml compiler:

  https://github.com/ocaml/ocaml/pull/9441

(They're currently waiting on building a QEMU-based CI system which I
hope will be based around Fedora.)

The PR above is closer to OCaml 4.11, but OCaml 4.11 hasn't been
released yet (not even alphas).

Long and the short is this will require some sort of OCaml pre-4.11
package, and a complete rebuild of everything in Rawhide.  (I'm not
proposing that we bother fixing OCaml for RISC-V in Fedora 32).

We could do it this week?  If it helps you.  If it's going to be a
problem then I could delay this until you've rebuilt the packages you
mention below.  I don't believe the delta from 4.10 to 4.11 is that
large, but as with any rebuild of this scale there can always be
unexpected problems.

> ocaml-migrate-parsetree: update to version 1.7.0.  I'm going to want
> this version for a later ocaml-tyxml update anyway, so we may as well
> do it now while we are rebuilding most of the affected packages for
> other reasons.
> 
> ocaml-ppxfind: rebuild due to the ocaml-migrate-parsetree update; drop
> a patch needed to work with ocaml-migrate-parsetree <= 1.5.0.
> 
> ocaml-ppx-tools-versioned: update to 5.3.0
> 
> ocaml-bisect-ppx: update to version 2.3.1
> 
> ocaml-ppx-deriving: rebuild due to the ocaml-migrate-parsetree update
> 
> ocaml-sedlex: rebuild due to the ocaml-ppx-tools-versioned update
> 
> ocaml-lwt: update to version 5.2.0
> 
> ocaml-curl: update to version 0.9.1 (it needs rebuilding anyway due to
> the ocaml-lwt update)
> 
> ocaml-lwt-log: rebuild due to the ocaml-lwt update
> 
> ocaml-ounit: rebuild due to the ocaml-lwt update
> 
> ocaml-zmq: rebuild due to the ocaml-lwt update
> 
> ocaml-lambda-term: update to version 2.0.3 (it needs rebuilding anyway
> due to the ocaml-bisect-ppx and ocaml-lwt updates)
> 
> ocaml-markup: rebuild due to the ocaml-bisect-ppx update
> 
> ocaml-tyxml: rebuild due to the ocaml-ppx-tools-versioned update
> 
> utop: update to version 2.4.3 and BR ocaml-bisect-ppx-devel for the
> tests.  I see that this package is orphaned.  I'll take it if nobody
> else wants it.
> 
> If any package maintainers object to this plan, please let me know.  I
> can submit git pull requests if you prefer to do it that way, but in
> that case please do not start a build after merging as all of these
> builds will need to be done together.  I have done all of the builds
> noted above in mock on an x86_64 machine with no problems.

Seems fine to me.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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-20200413.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 1/8 (x86_64)

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

ID: 575428  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/575428

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

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

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

Passed openQA tests: 5/8 (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

[Bug 1823484] perl-Test-Simple-1.302175 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
An unexpected error occurred while creating the scratch build and has been
automatically reported. Sorry!


-- 
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 1823484] New: perl-Test-Simple-1.302175 is available

[bugzilla]

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

Bug ID: 1823484
   Summary: perl-Test-Simple-1.302175 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-Simple
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.302175
Current version/release in rawhide: 1.302174-1.fc33
URL: http://search.cpan.org/dist/Test-Simple/

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/11977/


-- 
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 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 607  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 349  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
 347  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  56  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6   
python-waitress-1.4.3-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b23fa957bb   
drupal7-ckeditor-1.19-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-16bf726581   
php-robrichards-xmlseclibs1-1.4.3-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-181270fbae   
chromium-80.0.3987.163-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-34295ace88   
cacti-1.2.11-1.el7 cacti-spine-1.2.11-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b6453e2708   
nrpe-4.0.2-1.el7


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

msmtp-1.8.7-2.el7
nfdump-1.6.20-1.el7
rdiff-backup-2.0.0-1.el7

Details about builds:



 msmtp-1.8.7-2.el7 (FEDORA-EPEL-2020-8107d97f0f)
 SMTP client

Update Information:

Rebuild for epel7

ChangeLog:

* Thu Feb 27 2020 Peter Lemenkov  - 1.8.7-2
- Rebuild for epel7
* Thu Feb 27 2020 Peter Lemenkov  - 1.8.7-1
- Ver. 1.8.7 (rhbz#1786781)
* Wed Jan 29 2020 Fedora Release Engineering  - 
1.8.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Fri Sep 27 2019 Gerald Cox  - 1.8.6-1
- Upstream release rhbz#1756345
* Thu Jul 25 2019 Fedora Release Engineering  - 
1.8.5-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Fri Jul 12 2019 Gerald Cox  - 1.8.5-1
- Upstream release rhbz#1729541
* Wed Apr 24 2019 Gerald Cox  - 1.8.4-1
- Upstream release rhbz#1702798
* Tue Feb 12 2019 Gerald Cox  - 1.8.3-1
- Upstream release rhbz#1675527
* Fri Feb  1 2019 Fedora Release Engineering  - 
1.8.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Mon Jan 28 2019 Gerald Cox  - 1.8.2-1
- Upstream release rhbz#1670013
* Sat Jul 14 2018 Gerald Cox  - 1.6.7-3
- Adjust alternatives priority rhbz#1598386
* Fri Jul 13 2018 Fedora Release Engineering  - 
1.6.7-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Fri Jun 22 2018 Gerald Cox  - 1.6.7-1
- Upstream release 1.6.7 rhbz#1594450
* Fri Jun 22 2018 Gerald Cox  - 1.6.6-6
- Add alternatives rhbz#1367858
* Thu Feb  8 2018 Fedora Release Engineering  - 
1.6.6-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Aug  3 2017 Fedora Release Engineering  - 
1.6.6-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
* Wed Jul 26 2017 Fedora Release Engineering  - 
1.6.6-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Fri Feb 10 2017 Fedora Release Engineering  - 
1.6.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Tue Nov 15 2016 Peter Lemenkov  - 1.6.6-1
- Ver. 1.6.6
* Mon Jun  6 2016 Peter Lemenkov  - 1.6.5-1
- Ver. 1.6.5
* Sat Feb 20 2016 Niels de Vos  - 1.6.4-1
- Update to version 1.6.4 (#1303788)
* Thu Feb  4 2016 Fedora Release Engineering  - 
1.6.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
* Sun Nov 29 2015 Niels de Vos  - 1.6.3-1
- Update to version 1.6.3 (#1286308)
- TLS: use system crypto policy (#1179321)
* Wed Jun 17 2015 Fedora Release Engineering  
- 1.6.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
* Thu May  7 2015 Niels de Vos  - 1.6.2-1
- Update to version 1.6.2 (#1170995)
* Sun Aug 17 2014 Fedora Release Engineering  
- 1.4.32-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
* Sat Jun  7 2014 Fedora Release Engineering  
- 1.4.32-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild




 nfdump-1.6.20-1.el7 (FEDORA-EPEL-2020-c8f8fb9487)
 NetFlow collecting and processing tools

Update Information:

nfdump-1.6.20 ---  Important fix for -N plain number printing. v1.6.19 may
disturb many output parses relaying on -N working correctly.

ChangeLog:

* Fri Apr 10 2020 Denis Fateyev  - 1.6.20-1
- Update to version 1.6.20

References:

  [ 1 ] Bug #1818606 - nfdump-1.6.20 is available

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  36  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4   
ansible-2.9.6-1.el8
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-83cd17b92f   
nrpe-4.0.2-2.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6637ed458e   
chromium-80.0.3987.163-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8fcf741d7f   
cacti-1.2.11-1.el8 cacti-spine-1.2.11-1.el8


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

NetworkManager-l2tp-1.8.2-1.el8
earlyoom-1.6-1.el8
gwe-0.14.1-2.el8
libgsasl-1.8.0-8.el8
ncrack-0.7-1.el8
nfdump-1.6.20-1.el8
perl-Sys-Statistics-Linux-0.66-21.el8
perl-Test-mysqld-1.0013-1.el8
python-mimeparse-1.6.0-13.el8
python-py3nvml-0.2.6-1.el8
python-txws-0.9.1-20.el8
swift-lang-5.2.1-3.el8
vdpauinfo-1.0-10.el8
worker-4.4.0-1.el8

Details about builds:



 NetworkManager-l2tp-1.8.2-1.el8 (FEDORA-EPEL-2020-0a51e52bb1)
 NetworkManager VPN plugin for L2TP and L2TP/IPsec

Update Information:

Updated to 1.8.2 release

ChangeLog:

* Sun Apr 12 2020 Douglas Kosovic  - 1.8.2-1
- Updated to 1.8.2 release
- Remove redundant patches
- Remove redundant libnm_glib conditionals as can not be built with RHEL < 8
- Correct BuildRequires version dependencies
- Use --enable-libreswan-dh2 configure switch with RHEL8
- Recommends (libreswan or strongswan) instead of just libreswan
* Thu Feb 27 2020 Douglas Kosovic  - 1.8.0-5
- Patch for user certificate support fix
* Wed Feb 26 2020 Douglas Kosovic  - 1.8.0-4
- Patch to support libreswan 3.30 which is no longer built with modp1024 support
* Sat Feb 22 2020 Adam Williamson  - 1.8.0-3
- Rebuild for new ppp
* Tue Jan 28 2020 Fedora Release Engineering  - 
1.8.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild




 earlyoom-1.6-1.el8 (FEDORA-EPEL-2020-82951565e2)
 Early OOM Daemon for Linux

Update Information:

Updated to version 1.6.    Updated to version 1.5.

ChangeLog:

* Sat Apr 11 2020 Vitaly Zaitsev  - 1.6-1
- Updated to version 1.6.
* Fri Apr 10 2020 Neal Gompa  - 1.5-2
- Add Supplements to fedora-release-workstation for F32+ to work around 
RHBZ#1814306
* Mon Mar 23 2020 Vitaly Zaitsev  - 1.5-1
- Updated to version 1.5.




 gwe-0.14.1-2.el8 (FEDORA-EPEL-2020-253583aae8)
 System utility designed to provide information of NVIDIA card

Update Information:

Update to latest version

ChangeLog:

* Sat Apr 11 2020 Artem Polishchuk  - 0.14.1-2
- Add dep 'libdazzle'
* Fri Apr 10 2020 Artem Polishchuk  - 0.14.1-1
- Update to 0.14.1




 libgsasl-1.8.0-8.el8 (FEDORA-EPEL-2020-9d71894c78)
 GNU SASL library

Update Information:

Initial submission to epel8

ChangeLog:





 ncrack-0.7-1.el8 (FEDORA-EPEL-2020-4d8ea0e0b0)
 A high-speed network auth cracking tool

Update Information:

Update to bugfix release 0.7

ChangeLog:





 nfdump-1.6.20-1.el8 (FEDORA-EPEL-2020-9a3e560ce9)
 NetFlow collecting and processing tools

Update Information:

nfdump-1.6.20 ---  Important fix for -N plain number printing. v1.6.19 may
disturb many output parses relaying on -N working correctly.

[Bug 1819677] perl-Sys-Statistics-Linux missing in EPEL-8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #9 from Fedora Update System  ---
FEDORA-EPEL-2020-409a866a09 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-409a866a09

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

[Bug 1803531] perl-Test-mysqld-1.0013 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2020-df373fbeba has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-df373fbeba

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

Self Introduction: Devin Acosta

[Devin A]

My name is Devin Acosta, and I have been doing Information Technology for
well over 20+ Years. I am a Red Hat Certified Architect and I am trying to
help get my first package into EPEL7/EPEL8. The program that I am trying to
get into EPEL is Sensu Go (Open Source version). I have filed by Review
Request here (https://bugzilla.redhat.com/show_bug.cgi?id=1818670), and I
have had some feedback already. I have made modifications based upon most
of the comments given to me about my SPEC file and I am not sure what is
the process of getting sponsored and getting it moving forward?

---

Devin Acosta
___
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

system time in Fedora 32

[Dennis Gilmore]

Hi all,

before going off an filing a bug, I wanted to gather some input.  I
added a battery  for the RTC to one of my ARM boards, in testing that
it was working as expected I booted the system I noticed the following

[root@localhost ~]# date
Wed 01 Apr 2020 05:24:35 PM UTC
[root@localhost ~]# hwclock
2020-04-08 15:15:29.146007+00:00

trying to sync the clock I get

[root@localhost ~]# hwclock --hctosys --verbose
hwclock from util-linux 2.35.1
System Time: 1585762054.571276
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1585761886 seconds after 1969
Last calibration done at 1585761886 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2020/04/08 15:18:25
Hw clock time : 2020/04/08 15:18:25 = 1586359105 seconds since 1969
Time since last adjustment is 597219 seconds
Calculated Hardware Clock drift is 0.00 seconds
Calling settimeofday(NULL, 0) to set persistent_clock_is_local.
Calling settimeofday(1586359105.00, 0)
hwclock: settimeofday() failed: Invalid argument
[root@localhost ~]# rpm -q glibc
glibc-2.31-2.fc32.aarch64

I came across https://www.mail-archive.com/info-gnu@gnu.org/msg02694.html
which to me indicates that the API used by hwclock is being removed
and it needs updating. I wanted to get a better understanding of what
is going on, and if it should be considered as a blocker for f32. I
tested and the bug exists on x86 and arm and would exist on other
arches also if the network is connected at boot it should not matter
as ntp/chrony would do the right thing. However, without network, the
date and time would be broken, potentially off so much that when
network is connected dnf will not work.

Dennis
___
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

ocaml-bisect-ppx and related updates

[Jerry James]

I would like to update the ocaml-bisect-ppx package to its latest
version, 2.3.1.  It is currently on a post-1.4.1 git snapshot.  The
new version requires ocaml-ppx-tools-versioned >= 5.3.0.  That
requirement sets off a cascade of updates and rebuilds.  I am BCCing
all of the affected package maintainers.  Here is what I would like to
do, in the approximate order each would need to be done:

ocaml-migrate-parsetree: update to version 1.7.0.  I'm going to want
this version for a later ocaml-tyxml update anyway, so we may as well
do it now while we are rebuilding most of the affected packages for
other reasons.

ocaml-ppxfind: rebuild due to the ocaml-migrate-parsetree update; drop
a patch needed to work with ocaml-migrate-parsetree <= 1.5.0.

ocaml-ppx-tools-versioned: update to 5.3.0

ocaml-bisect-ppx: update to version 2.3.1

ocaml-ppx-deriving: rebuild due to the ocaml-migrate-parsetree update

ocaml-sedlex: rebuild due to the ocaml-ppx-tools-versioned update

ocaml-lwt: update to version 5.2.0

ocaml-curl: update to version 0.9.1 (it needs rebuilding anyway due to
the ocaml-lwt update)

ocaml-lwt-log: rebuild due to the ocaml-lwt update

ocaml-ounit: rebuild due to the ocaml-lwt update

ocaml-zmq: rebuild due to the ocaml-lwt update

ocaml-lambda-term: update to version 2.0.3 (it needs rebuilding anyway
due to the ocaml-bisect-ppx and ocaml-lwt updates)

ocaml-markup: rebuild due to the ocaml-bisect-ppx update

ocaml-tyxml: rebuild due to the ocaml-ppx-tools-versioned update

utop: update to version 2.4.3 and BR ocaml-bisect-ppx-devel for the
tests.  I see that this package is orphaned.  I'll take it if nobody
else wants it.

If any package maintainers object to this plan, please let me know.  I
can submit git pull requests if you prefer to do it that way, but in
that case please do not start a build after merging as all of these
builds will need to be done together.  I have done all of the builds
noted above in mock on an x86_64 machine with no problems.

Regards,
-- 
Jerry James
http://www.jamezone.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: Modularity Survey

[Matthew Miller]

On Sat, Apr 11, 2020 at 01:30:57PM +0200, Kevin Kofler wrote:
> That is another major concern, that decisions made by Fedora for Fedora 
> users depend more and more on input from people (and companies) who are NOT 
> Fedora users. What makes sense for RHEL and/or CentOS does not necessarily 
> make sense for Fedora (and for that matter, what makes sense for RHEL also 
> does not necessarily make sense for CentOS). Fedora decisions should depend 
> ONLY on the input and needs of Fedora users.

Fedora has huge impact beyond our immediate userbase because we are the
upstream for RHEL, CentOS, and their further derivatives.

Take a look https://imgur.com/a/58OXYve. This is Fedora EPEL (which is part
of our project!), not the downstreams themselves, but shows just *one*
aspect of that impact. (It's so large that I see I need to figure out how to
tell matplotlib to not shift to e notation!)

I agree that when we make decisions in Fedora, we need to consider direct
users of the OS we make first. But we are also making a system we _want_ to
be useful as an upstream, and taking downstream needs into account is the
only way we can succeed at that.


-- 
Matthew Miller

Fedora Project Leader
Not the Pope
___
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: Why does Koschei not run real builds?

[clime]

On Mon, 13 Apr 2020 at 14:48, Neal Gompa  wrote:
>
> On Mon, Apr 13, 2020 at 5:15 AM Fabio Valentini  wrote:
> >
> > On Mon, Apr 13, 2020 at 10:55 AM Dan Čermák
> >  wrote:
> > >
> > > Hi list,
> > >
> > > my question is pretty much $subject: Why doesn't Koschei kick of
> > > real builds off packages on dependency changes? From my naive POV that
> > > looks like the missing piece to give us the "OBS-experience". Having
> > > that at least in Rawhide sounds like a good thing to me.
> >
> > It *might* be a good idea to help deal with rebuilds, but I see some
> > problems with that.
> >
> > - koschei would need to add "rebuilt by koschei" commits to dist-git
> > for this (OBS doesn't have a real VCS, so it's not a problem there)
> > - those changes would add a lot of churn to .spec files, possibly
> > angering a lot of packagers, and would also create possible conflicts
> > between local changes and koschei builds
> > - the builds add a lot of load to koji already (although at lower
> > priority), which will probably be a problem when there's reduced
> > capacity (e.g. the upcoming datacenter move)
> >
>
> I think the fundamental premise here is that rebuilds this way
> requires commits into Dist-Git.

Assuming we have tooling for it, commits is not the only option. The
other option might be tags. You don't create a new (potentially empty)
commit, but instead, you create a new tag from koschei environment and
if you succeed, you build that tag. That tag can also automatically
populate changelog with the reason for rebuild.

But then I think it would be good to have some name separation of the
user tags vs. the koschei tags and technical details of this need to
be figured out, i.e. it would require more discussion and
brainstorming to determine if the separation is technically possible
and how to do it.

Both, the commit and the tag approach try to maintain dist-git as the
single source of truth [1] to provide basic package information such
as name-version-release, which is beneficial for local build
reproducibility, it makes the result easier to calculate and predict,
and it also makes services less intertwined.

[1] https://en.wikipedia.org/wiki/Single_source_of_truth

> With what Pierre-Yves and his group
> released last week for testing[1], that may no longer be an issue.
>
> [1]: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LWE4URIRWVTEZKXKP7QOK5JXFNVJRUNW/
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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

Fedora rawhide compose report: 20200413.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200412.n.0
NEW: Fedora-Rawhide-20200413.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   49
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   2.20 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   281.72 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20200413.n.0.iso
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20200413.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  NetworkManager-strongswan-1.5.0-1.fc33
Old package:  NetworkManager-strongswan-1.4.5-2.fc32
Summary:  NetworkManager strongSwan IPSec VPN plug-in
RPMs: NetworkManager-strongswan NetworkManager-strongswan-gnome
Size: 204.64 KiB
Size change:  9.27 KiB
Changelog:
  * Sun Apr 12 2020 Mikhail Zabaluev  - 1.5.0-1
  - Updated to 1.5.0


Package:  OpenImageIO-2.1.13.0-2.fc33
Old package:  OpenImageIO-2.1.13.0-1.fc33
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 19.78 MiB
Size change:  16.18 KiB
Changelog:
  * Sun Apr 12 2020 Richard Shaw  - 2.1.13.0-2
  - Rebuild for funky depdendency problem in Rawhide/33.


Package:  balsa-2.6.0-1.fc33
Old package:  balsa-2.5.9-2.fc32
Summary:  Mail Client
RPMs: balsa
Size: 15.05 MiB
Size change:  85.48 KiB
Changelog:
  * Sun Apr 12 2020 Pawel Salek  - 2.6.0-1
  - Update to upstream balsa-2.6.0.
  - Remove --with-gpgme as gpg is fixed build requirement now.


Package:  cdbs-0.4.161-1.fc33
Old package:  cdbs-0.4.159-4.fc32
Summary:  Common build system for Debian packages
RPMs: cdbs
Size: 58.19 KiB
Size change:  2 B
Changelog:
  * Sun Apr 12 2020 Sandro Mani  - 0.4.161-1
  - Update to 0.4.161


Package:  clojure-core-specs-alpha-1:0.1.24-2.fc33
Old package:  clojure-core-specs-alpha-1:0.1.24-1.fc33
Summary:  Clojure library containing specs to describe Clojure core macros 
and functions
RPMs: clojure-core-specs-alpha
Size: 19.70 KiB
Size change:  2.50 KiB
Changelog:
  * Sun Apr 12 2020 Markku Korkeala  - 1:0.1.24-2
  - Add builder helper to copy clojure files


Package:  clojure-spec-alpha-1:0.1.134-2.fc33
Old package:  clojure-spec-alpha-1:0.1.134-1.fc33
Summary:  Spec is a Clojure library to describe the structure of data and 
functions
RPMs: clojure-spec-alpha
Size: 514.71 KiB
Size change:  497.25 KiB
Changelog:
  * Sun Apr 12 2020 Markku Korkeala  - 1:0.1.134-2
  - Hook clojure-maven-plugin goals to maven goals


Package:  coin-or-Clp-1.17.5-2.fc33~bootstrap
Old package:  coin-or-Clp-1.17.5-1.fc33
Summary:  Coin-or linear programming
RPMs: coin-or-Clp coin-or-Clp-devel coin-or-Clp-doc
Size: 22.98 MiB
Size change:  -176.72 KiB
Changelog:
  * Sun Apr 12 2020 Nicolas Chauvet  - 1.17.5-2
  - Rebuilt for MUMPS 5.3


Package:  coin-or-Ipopt-3.13.0-3.fc33
Old package:  coin-or-Ipopt-3.13.0-2.fc33
Summary:  Interior Point OPTimizer
RPMs: coin-or-Ipopt coin-or-Ipopt-common coin-or-Ipopt-devel 
coin-or-Ipopt-mpich coin-or-Ipopt-mpich-devel coin-or-Ipopt-openmpi 
coin-or-Ipopt-openmpi-devel
Size: 21.48 MiB
Size change:  2.58 KiB
Changelog:
  * Sun Apr 12 2020 Nicolas Chauvet  - 3.13.0-3
  - Rebuilt for MUMPS 5.3


Package:  dummy-test-package-crested-0-162.fc33
Old package:  dummy-test-package-crested-0-150.fc33
Summary:  Dummy Test Package called Crested
RPMs: dummy-test-package-crested
Size: 19.42 KiB
Size change:  721 B
Changelog:
  * Sun Apr 12 2020 packagerbot  - 0-151
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-152
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-153
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-154
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-155
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-156
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-157
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-158
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-159
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-160
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-161
  - rebuilt

  * Mon Apr 13 2020 packagerbot  - 0-162
  - rebuilt


Package:  dummy-test-package-gloster-0-181.fc33
Old package:  dummy-test-package-gloster-0-170.fc33
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 20.45 KiB
Size change:  665 B
Changelog:
  * Sun Apr 12 2020 packagerbot  - 0-171
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-172
  - rebuilt

  * Sun Apr 12 2020 packagerbot  - 0-173

Re: The Chromium Dilemma

[Vitaly Zaitsev via devel]

On 13.04.2020 18:58, Michael Catanzaro wrote:
> I guess that solves the problem, doesn't it? There is zero reason for
> Fedora to be doing a component build anymore if it's no longer of
> benefit to rpmfusion. Yes?

I think so.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: The Chromium Dilemma

[Michael Catanzaro]

On Mon, Apr 13, 2020 at 6:33 pm, Vitaly Zaitsev via devel 
 wrote:

Due to major synchronization problems between Fedora and RPM Fusion
repositories.

Fedora updates chromium -> RPM fusion need need 1-3 days to push this
update to rpmfusion-free-updates and users complains about broken
updates. Everyone is tired of this. That's why chromium-freeworld
package was created.


I guess that solves the problem, doesn't it? There is zero reason for 
Fedora to be doing a component build anymore if it's no longer of 
benefit to rpmfusion. Yes?


___
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-32-20200413.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

Old failures (same test failed in Fedora-IoT-32-20200412.0):

ID: 575105  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/575105

Passed openQA tests: 7/8 (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: The Chromium Dilemma

[Tom Callaway]

The linker said: error adding symbols: Malformed archive. Searching leads
me to translate that error to "too many open files". See:
https://github.com/OSSystems/meta-browser/issues/194

Apparently, gold does not have this issue, but I have not tested.

Tom

On Mon, Apr 13, 2020 at 12:05 PM Lennart Poettering 
wrote:

> On Mo, 13.04.20 09:56, Tom Callaway (tcall...@redhat.com) wrote:
>
> > C) Chromium's build process gets...angrier. Still doable, but you have to
> > do things like set ulimit -n 4096. (Fun fact: the man page section for
> > ulimit says that for -n, "most systems do not allow this value to be
> set".
> > Guess modern Linux isn't most systems.)
>
> Hmm what precisely fails?
>
> Note that in systemd we took the liberty to bump RLIMIT_NOFILE's hard
> limit to 512K a while back, which one can effectively understand as
> "there's no limit on fds anymore" (this was on suggestion of some
> kernel folks, because fds are these days tracked like memory and hence
> are accounted like that too and are not as expensive as hey used to
> be). We would have liked to bump the matching soft limit too (i.e. the
> one you tweak with ulimit -n), but that's something what we can't do
> without breaking compability a litte bit too agressively: fds above
> 1023 are not compatible with select(), and plenty software still uses
> select() (they really shouldn't, it's a terrible interface), and it's
> a silent failure.
>
> Long story short: If there are programs that are likely to deal with
> large numbers of fds (like in your case, the linker I presume?) they
> should probably just bump the soft limit to the hard limit early on in
> their C code, and thus just get as many fds they want. Raising the
> soft limit up to the hard limit is an unprivileged operation and can
> be done by regular users. Programs that do that should reset the soft
> limit back to 1K before forking off foreign programs again though,
> again for compatibility with any such programs that use select().
>
> Very short version: consider filing a bug against your linker tool (or
> whichever other tool needed the ulimit -n above), and ask them to set
> RLIMIT_NOFILE's soft value to the hard value. And then they will just
> work without any manual limit bumping for regular people on modern
> distros.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> 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: The Chromium Dilemma

[Vitaly Zaitsev via devel]

On 13.04.2020 18:01, Tom Callaway wrote:
> What I don't understand is _why_ RPM Fusion made that change. Not saying
> it is without merit, just that I don't understand why a total rebuild is
> preferred.

Due to major synchronization problems between Fedora and RPM Fusion
repositories.

Fedora updates chromium -> RPM fusion need need 1-3 days to push this
update to rpmfusion-free-updates and users complains about broken
updates. Everyone is tired of this. That's why chromium-freeworld
package was created.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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

Summary/Minutes from today's FESCo Meeting (2020-04-13)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

=
#fedora-meeting-1: FESCO (2020-04-13)
=


Meeting started by sgallagh at 15:01:54 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-13/fesco.2020-04-13-15.01.log.html
.



Meeting summary
- ---
* init process  (sgallagh, 15:01:54)

* #2365 F33 System-Wide Change: ELN Buildroot and Compose  (sgallagh,
  15:04:57)
  * this received +7 in the ticket, so it is accepted  (sgallagh,
15:05:18)
  * AGREED: ELN Buildroot and Compose is accepted (+7, 1, -0)
(sgallagh, 15:05:36)

* #2364 F33 System-Wide Change: Introduce module Obsoletes and EOL
  (sgallagh, 15:06:54)
  * AGREED: Delay this discussion for a week due to holiday in CZ.
Questions will be posed to the devel-list.  (sgallagh, 15:12:44)

* Open Floor  (sgallagh, 15:12:57)
  * LINK:
https://fedorapeople.org/groups/schedule/f-33/f-33-infrastructure-tasks.html
(bcotton, 15:23:24)
  * LINK: https://tinyurl.com/wanx75h   (dcantrell, 15:33:57)

* Next Week's Chair  (sgallagh, 15:35:08)
  * ACTION: mhroncok will chair the meeting of 2020-04-20  (sgallagh,
15:36:24)
  * ACTION: bookwar will chair the meeting of 2020-04-27  (sgallagh,
15:36:42)

Meeting ended at 15:37:20 UTC.




Action Items
- 
* mhroncok will chair the meeting of 2020-04-20
* bookwar will chair the meeting of 2020-04-27




Action Items, by person
- ---
* bookwar
  * bookwar will chair the meeting of 2020-04-27
* mhroncok
  * mhroncok will chair the meeting of 2020-04-20
* **UNASSIGNED**
  * (none)




People Present (lines said)
- ---
* sgallagh (49)
* zodbot (17)
* nirik (15)
* bookwar (12)
* dcantrell (10)
* bcotton (6)
* decathorpe (4)
* adamw (1)
* ignatenkobrain (0)
* mhroncok (0)
* contyk (0)
* zbyszek (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl6UkisACgkQRduFpWgo
bRFbJgv/VWaBGWxOH7ul5RlW5664LvDD0ZQRtd7LnQ9vRSYLzzh/dQsrrGBRudEu
bcDBSAjh3HWlklobR8fmfDLKpnzMSPEV4PV7X96xtOBH0Y44Bxl7C6Jo30QFQzWt
yJVgQc+hpH37j6uj9pwVQ4mhy2u+PqgZmUYuqj2pzR0BMIS5yJCbt8oyLn39f8Pq
NKNKb9FpbZvBEIdEAvfKdpU6bMRPt71JTuHyz5gTYh7ILeQFJFS7UYbyDmA7t+m6
Bobo7YB9PLAWp8tUUTZOpxcOI89dCCMYLEGl892HLdnCCpyi5vtlaxDnvOSXApVT
bKaqUxBp0H+hobgPUkOn2OOQeb8Ec/Xl7Wkd8lxNKSRkmC5YpLsm0BKLJJ8Ao2YT
BU9dYbMkUKuUIsM/p2AKNHDfcOv/ZGE9VKovwnoDs3BG6lp6viQhwE1MVAJKBlu+
6UIctfqpVARlBDQkD9Y7hvU6HqQL6PH/yuQuujiFVyHOPgKHCW2DaQiY+jrtG+iF
1FdiGBRq
=8vxQ
-END 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: The Chromium Dilemma

[Lyes Saadi]

Le 13/04/2020 à 16:27, Peter Robinson a écrit :

People that want the Fedora version of the build, even without the
extra bits, would get rpmfusion if they happen to have rpmfusion
enabled for another reason.


Maybe a special repository only for chromium? I mean, chromium
is important enough for an exception like that. Or, distributing
two different .repo files, one of them with:

exclude=chromium

That could do the trick while keeping user's freedom.
___
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: The Chromium Dilemma

[Lennart Poettering]

On Mo, 13.04.20 09:56, Tom Callaway (tcall...@redhat.com) wrote:

> C) Chromium's build process gets...angrier. Still doable, but you have to
> do things like set ulimit -n 4096. (Fun fact: the man page section for
> ulimit says that for -n, "most systems do not allow this value to be set".
> Guess modern Linux isn't most systems.)

Hmm what precisely fails?

Note that in systemd we took the liberty to bump RLIMIT_NOFILE's hard
limit to 512K a while back, which one can effectively understand as
"there's no limit on fds anymore" (this was on suggestion of some
kernel folks, because fds are these days tracked like memory and hence
are accounted like that too and are not as expensive as hey used to
be). We would have liked to bump the matching soft limit too (i.e. the
one you tweak with ulimit -n), but that's something what we can't do
without breaking compability a litte bit too agressively: fds above
1023 are not compatible with select(), and plenty software still uses
select() (they really shouldn't, it's a terrible interface), and it's
a silent failure.

Long story short: If there are programs that are likely to deal with
large numbers of fds (like in your case, the linker I presume?) they
should probably just bump the soft limit to the hard limit early on in
their C code, and thus just get as many fds they want. Raising the
soft limit up to the hard limit is an unprivileged operation and can
be done by regular users. Programs that do that should reset the soft
limit back to 1K before forking off foreign programs again though,
again for compatibility with any such programs that use select().

Very short version: consider filing a bug against your linker tool (or
whichever other tool needed the ulimit -n above), and ask them to set
RLIMIT_NOFILE's soft value to the hard value. And then they will just
work without any manual limit bumping for regular people on modern
distros.

Lennart

--
Lennart Poettering, Berlin
___
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: The Chromium Dilemma

[Tom Callaway]

What I don't understand is _why_ RPM Fusion made that change. Not saying it
is without merit, just that I don't understand why a total rebuild is
preferred.

I would also be interested in seeing the patches where you set a specific
component to be shared while the others were static.

Thanks,
Tom

On Mon, Apr 13, 2020 at 11:54 AM Kevin Kofler 
wrote:

> Tom Callaway wrote:
> > So, you might be asking, why does Fedora build in shared mode? There are
> > two main reasons:
> > 1) To enable users to be able to swap out the media components from
> Fedora
> > with a "freeworld" version.
>
> That reason is obsolete. RPM Fusion replaced chromium-libs-media-freeworld
> with a full chromium-freeworld rebuild.
>
> > 2) To keep the size down on the chrome-remote-desktop subpackage (since
> it
> > can share the "internal libs" from chromium).
>
> That sounds valid, but is it worth the performance issues?
>
> I would recommend abandoning the component mode build. QtWebEngine has
> never
> been built that way.
>
> By the way, it is also possible to hack up the GN setup so that only some
> specific component is built as a component (which could solve point 1 if
> it
> were still needed). For QtWebEngine, I used to do that with V8 on 32-bit
> x86
> when I still had an x87 build and an SSE2 build of it. But that of course
> requires patching. And RPM Fusion no longer tries to replace the media
> component anyway (making point 1 moot).
>
> Kevin Kofler
> ___
> 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: The Chromium Dilemma

[Kevin Kofler]

Tom Callaway wrote:
> So, you might be asking, why does Fedora build in shared mode? There are
> two main reasons:
> 1) To enable users to be able to swap out the media components from Fedora
> with a "freeworld" version.

That reason is obsolete. RPM Fusion replaced chromium-libs-media-freeworld 
with a full chromium-freeworld rebuild.

> 2) To keep the size down on the chrome-remote-desktop subpackage (since it
> can share the "internal libs" from chromium).

That sounds valid, but is it worth the performance issues?

I would recommend abandoning the component mode build. QtWebEngine has never 
been built that way.

By the way, it is also possible to hack up the GN setup so that only some 
specific component is built as a component (which could solve point 1 if it 
were still needed). For QtWebEngine, I used to do that with V8 on 32-bit x86 
when I still had an x87 build and an SSE2 build of it. But that of course 
requires patching. And RPM Fusion no longer tries to replace the media 
component anyway (making point 1 moot).

Kevin Kofler
___
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: The Chromium Dilemma

[Gordon Messmer]

On 4/13/20 6:56 AM, Tom Callaway wrote:
I did a test build of a static version of Fedora's chromium and the 
benchmark performance went up to expected levels. 



This sounds similar to a discussion on this list in November, regarding 
python performance.  I think developers settled on the use of 
"-fno-semantic-interposition" with dynamic linking.  Could you try that 
to see if you get the same performance boost?


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NWPVQSKVWDKA75PDEIJNJIFL5C5SJXB2/
___
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 32 compose report: 20200413.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200412.n.0
NEW: Fedora-32-20200413.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= 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: The Chromium Dilemma

[Peter Robinson]

> Honestly, degraded performance is an expected result of doing component
> build, so I would say that's just not a bug at all, it's just how
> Chromium works. Our hand is forced here by upstream's strange and
> unusual packaging decisions. Other distros do it this way too.
>
> But you say the difference is *noticeable*, i.e. noticeable to users
> when not doing benchmarks? That sounds weird.
>
> On Mon, Apr 13, 2020 at 9:56 am, Tom Callaway 
> wrote:
> > This is my dilemma. (It is not my only dilemma, nor my most pressing,
> > but it is still mine.) That said, I would love to get input from
> > other smart Fedorans as to what I should do here.
>
> Naive proposal: chromium-freeworld could completely rebuild Chromium
> and Obsoletes the entire Fedora package? It could have an epoch ahead
> of the Fedora package such that the rpmfusion version is always
> preferred even if the Fedora package updates a bit? Then
> chromium-libs-media-freeworld can go away and the main Fedora package
> can do a static build and you get working krb5. Is there a downside to
> this approach that I'm missing?

People that want the Fedora version of the build, even without the
extra bits, would get rpmfusion if they happen to have rpmfusion
enabled for another reason.
___
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: Urgently downgrade xorg-x11-drv-intel

[Adam Williamson]

On Fri, 2020-04-10 at 12:42 -0400, Alexei Podtelezhnikov wrote:
> On Fri, Apr 10, 2020 at 11:14 AM Olivier Fourdan  wrote:
> > On Fri, Apr 10, 2020 at 4:38 PM Adam Jackson  wrote:
> > > On Fri, 2020-04-10 at 15:35 +0200, Olivier Fourdan wrote:
> > > > [...]
> > > > Adam, want me to launch an official build, just to rebuild?
> > > 
> > > Yes, please!
> > 
> > Oops, looks like I've been presumptuous on that one, I don't have the 
> > rights.
> 
> xorg-x11-drv-intel has very extensive set of BuildRequires, which
> seems rather large for a driver. I presume koji satisfies those and
> your test builds do indeed match the official ones.

There *is* a difference between most mock builds and koji builds, FWIW.
They do not use exactly the same buildroot, especially not for Branched
and Rawhide. The buildroot in Koji is re-generated with all packages
tagged 'stable' quite often, and includes buildroot overrides. mock
builds, if you just use the 'normal' targets like fedora-32-x86_64 or
fedora-rawhide-x86_64, use the current official stable repo contents as
the buildroot. This is usually somewhat "behind" the buildroot koji
uses, because it's only updated from successful daily composes, and
doesn't include buildroot overrides.

The mock target with -koji on the end - like fedora-32-x86_64-koji -
have the koji buildroot repo added alongside the 'fedora' repo, so if
you use those targets, the builds should more closely match koji
builds.
-- 
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: The Chromium Dilemma

[Tom Callaway]

https://browserbench.org/Speedometer2.0/ is the benchmark in the bug.

Tom

On Mon, Apr 13, 2020 at 10:34 AM Benson Muite 
wrote:

>
>
> On Mon, Apr 13, 2020, at 5:21 PM, Michael Catanzaro wrote:
> > Honestly, degraded performance is an expected result of doing component
> > build, so I would say that's just not a bug at all, it's just how
> > Chromium works. Our hand is forced here by upstream's strange and
> > unusual packaging decisions. Other distros do it this way too.
> >
> > But you say the difference is *noticeable*, i.e. noticeable to users
> > when not doing benchmarks? That sounds weird.
> >
> > On Mon, Apr 13, 2020 at 9:56 am, Tom Callaway 
> > wrote:
> > > This is my dilemma. (It is not my only dilemma, nor my most pressing,
> > > but it is still mine.) That said, I would love to get input from
> > > other smart Fedorans as to what I should do here.
> >
> > Naive proposal: chromium-freeworld could completely rebuild Chromium
> > and Obsoletes the entire Fedora package? It could have an epoch ahead
> > of the Fedora package such that the rpmfusion version is always
> > preferred even if the Fedora package updates a bit? Then
> > chromium-libs-media-freeworld can go away and the main Fedora package
> > can do a static build and you get working krb5. Is there a downside to
> > this approach that I'm missing?
> >
> >
>
> Are the benchmark results available somewhere?  What exactly was measured
> in those benchmarks?
> ___
> 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: The Chromium Dilemma

[Benson Muite]

On Mon, Apr 13, 2020, at 5:21 PM, Michael Catanzaro wrote:
> Honestly, degraded performance is an expected result of doing component 
> build, so I would say that's just not a bug at all, it's just how 
> Chromium works. Our hand is forced here by upstream's strange and 
> unusual packaging decisions. Other distros do it this way too.
> 
> But you say the difference is *noticeable*, i.e. noticeable to users 
> when not doing benchmarks? That sounds weird.
> 
> On Mon, Apr 13, 2020 at 9:56 am, Tom Callaway  
> wrote:
> > This is my dilemma. (It is not my only dilemma, nor my most pressing, 
> > but it is still mine.) That said, I would love to get input from 
> > other smart Fedorans as to what I should do here.
> 
> Naive proposal: chromium-freeworld could completely rebuild Chromium 
> and Obsoletes the entire Fedora package? It could have an epoch ahead 
> of the Fedora package such that the rpmfusion version is always 
> preferred even if the Fedora package updates a bit? Then 
> chromium-libs-media-freeworld can go away and the main Fedora package 
> can do a static build and you get working krb5. Is there a downside to 
> this approach that I'm missing?
> 
> 

Are the benchmark results available somewhere?  What exactly was measured in 
those benchmarks?
___
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: The Chromium Dilemma

[Michael Catanzaro]

Honestly, degraded performance is an expected result of doing component 
build, so I would say that's just not a bug at all, it's just how 
Chromium works. Our hand is forced here by upstream's strange and 
unusual packaging decisions. Other distros do it this way too.


But you say the difference is *noticeable*, i.e. noticeable to users 
when not doing benchmarks? That sounds weird.


On Mon, Apr 13, 2020 at 9:56 am, Tom Callaway  
wrote:
This is my dilemma. (It is not my only dilemma, nor my most pressing, 
but it is still mine.) That said, I would love to get input from 
other smart Fedorans as to what I should do here.


Naive proposal: chromium-freeworld could completely rebuild Chromium 
and Obsoletes the entire Fedora package? It could have an epoch ahead 
of the Fedora package such that the rpmfusion version is always 
preferred even if the Fedora package updates a bit? Then 
chromium-libs-media-freeworld can go away and the main Fedora package 
can do a static build and you get working krb5. Is there a downside to 
this approach that I'm missing?


___
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: Input Requested: revising policy for stalled EPEL requests

[Troy Dawson]

On Sat, Apr 11, 2020 at 2:37 AM Paul Howarth  wrote:
>
> On Fri, 10 Apr 2020 15:17:25 -0700
> Troy Dawson  wrote:
>
> > On Fri, Apr 3, 2020 at 3:21 PM Troy Dawson  wrote:
> > >
> > > EPEL Issue #101 [1] has pointed out that our current policy for
> > > stalled EPEL requests is fairly in-efficient and can cause some long
> > > delays.
> > >
> > > What do people think the process should be?
> > >
> > > Here is an example:
> > > * A packager opens a bugzilla requesting a package be added to EPEL.
> > > They also express that they are willing to help maintain /
> > > co-maintain that package in EPEL.
> > > * A period of time goes by with no response
> > > * They re-say that they are willing to maintain / co-maintain the
> > > package in EPEL
> > > * Another period of time goes by with no response
> > > * They file a rel-eng ticket, that points to the bugzilla,
> > > requesting appropriate privileges to be able to branch and build
> > > that package in EPELX
> > > * That happens.
> > > * They then request branch, and build the package in EPELX following
> > > normal ways.
> > >
> > > This is just an example, but it's what I picture in my head.
> > > Troy
> > >
> > > [1] - https://pagure.io/epel/issue/101
> >
> > This is the proposed policy. If people could look through it for any
> > problems, it would be appreciated.
> >
> > **Stalled EPEL Requests**
> > There are times that an EPEL / Fedora package maintainer isn't
> > responding to an EPEL package request. If a different packager would
> > like to build and maintain that package in EPEL, these are the steps
> > they take.
> >
> > * A packager opens a bugzilla requesting a package be added to EPEL.
> > They also express that they are willing to help maintain / co-maintain
> > that package in EPEL-X.
> >
> > * A week goes by with no response
> >
> > * They re-say that they are willing to maintain / co-maintain the
> > package in EPEL
> > ** This is just incase the initial message was missed.
> >
> > * A week goes by with no response
> >
> > * They file a rel-eng ticket, that points to the bugzilla, requesting
> > appropriate privileges to be able to branch and build that package in
> > EPEL-X
> > ** Currently that privilege is "admin"
> > ** This part of the policy will adjust as various features get
> > implemented in pagure and dist-git
> >
> > * The privileges are given
> > * They then request a branch, and build the package in EPEL-X
> > following normal steps.
>
> I think there's also a good case for the requester to be made the
> bugzilla contact for EPEL for that package, though it would be
> complicated if there was an existing EPEL branch, which would
> presumably have been made (and been maintained) by someone else.
>
> Paul.

That's a very good point.  I think that would be done during the "The
privileges are given.".
I think (hope) that can be done on a per-branch basis.  So it would be
something like

* The privileges are given and the packager is made the bugzilla
contact for EPEL-X

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

The Chromium Dilemma

[Tom Callaway]

Hi Fedorans,

Here's the situation:

Recently, someone filed a bug against chromium, noting that it was
benchmarking notably slower than Google Chrome or chromium-freeworld (from
rpmfusion). I tested locally and confirmed it. They suspected that Fedora's
optflags were to blame, but since chromium doesn't use them anymore, that
wasn't it. chromium-freeworld enables some media codecs we cannot, but this
shouldn't affect javascript benchmark tests. VAAPI is turned on in both
builds, but not in Google Chrome.
Ultimately, the culprit was in how chromium is built for Fedora. There are
two ways to build chromium: as a giant static binary (which is how Google
Chrome and chromium-freeworld are built) and as a collection of shared
libraries (which is how Fedora's chromium is built). I did a test build of
a static version of Fedora's chromium and the benchmark performance went up
to expected levels. It's worth noting that IMHO, the performance loss is
noticeable, but the browser is still usable.

So, you might be asking, why does Fedora build in shared mode? There are
two main reasons:
1) To enable users to be able to swap out the media components from Fedora
with a "freeworld" version.
2) To keep the size down on the chrome-remote-desktop subpackage (since it
can share the "internal libs" from chromium).

Switching to static mode gives us:
1) Fully working krb5 (because it would resolve the symbol clash caused by
the use of chromium's boringssl fork). This bug has been outstanding for a
few years now.
2) Performance improvements.

HOWEVER, switching to static mode means that:
A) It will become impossible to have an addon package from rpmfusion (or
wherever) to swap in the additional media codecs we cannot include in
Fedora. The only way to get those codecs would be to install an alternate
build of chromium (chromium-freeworld) or a different browser (Fedora).
Hypothetically, it might be possible to try to patch chromium to build
_just_ the media bits as a shared library (or to have it dlopen them), but
upstream is not in the slightest way interested in that, and untangling the
Lovecraftian nightmare that is the custom Chromium buildsystem is not my
idea of a fun quarantine activity. Full disclosure here: rpmfusion has not
really been doing builds of this addon package
(chromium-libs-media-freeworld) for quite some time now. I'm not sure why.
This means that at least for the last few months, this option hasn't really
been available to anyone outside of people doing manual rebuilds of the
chromium SRPM with the %freeworld and %shared variables enabled.
B) Per process memory utilization for chromium might go up. Not sure about
this.
C) Chromium's build process gets...angrier. Still doable, but you have to
do things like set ulimit -n 4096. (Fun fact: the man page section for
ulimit says that for -n, "most systems do not allow this value to be set".
Guess modern Linux isn't most systems.)

Now, we could make a chromium-static subpackage (just 4-6 more hours added
to the koji build), but I'm concerned that users would not understand the
purpose of it, and even if they did, they'd get unhappy when they
discovered that it had missing codecs. There are a large number of web
services that convert GIF animations to embedded videos these days, and
most of them aren't using codecs we can ship (hi Twitter).

This is my dilemma. (It is not my only dilemma, nor my most pressing, but
it is still mine.) That said, I would love to get input from other smart
Fedorans as to what I should do here.

Thanks,
Tom
___
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 1823368] New: Please add perl-Curses to EPEL8

[bugzilla]

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

Bug ID: 1823368
   Summary: Please add perl-Curses to EPEL8
   Product: Fedora EPEL
   Version: epel8
  Hardware: All
Status: NEW
 Component: perl-Curses
  Severity: low
  Assignee: steve.tray...@cern.ch
  Reporter: m...@luto.at
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
steve.tray...@cern.ch
  Target Milestone: ---
Classification: Fedora



Description of problem:
EPEL 5, 6, and 7 provide perl-Curses, EPEL8 doesn't.

Version-Release number of selected component (if applicable): N/A

Steps to Reproduce:
1. boot CentOS 8
2. enable EPEL
3. dnf install perl-Curses

Actual results:
Package does not exist.

We need perl-Curses to get "mtop" running, so we're kind of blocked. If there
is anything I can do to assist in this, please let me know. Thank you!


-- 
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: Why does Koschei not run real builds?

[Neal Gompa]

On Mon, Apr 13, 2020 at 5:15 AM Fabio Valentini  wrote:
>
> On Mon, Apr 13, 2020 at 10:55 AM Dan Čermák
>  wrote:
> >
> > Hi list,
> >
> > my question is pretty much $subject: Why doesn't Koschei kick of
> > real builds off packages on dependency changes? From my naive POV that
> > looks like the missing piece to give us the "OBS-experience". Having
> > that at least in Rawhide sounds like a good thing to me.
>
> It *might* be a good idea to help deal with rebuilds, but I see some
> problems with that.
>
> - koschei would need to add "rebuilt by koschei" commits to dist-git
> for this (OBS doesn't have a real VCS, so it's not a problem there)
> - those changes would add a lot of churn to .spec files, possibly
> angering a lot of packagers, and would also create possible conflicts
> between local changes and koschei builds
> - the builds add a lot of load to koji already (although at lower
> priority), which will probably be a problem when there's reduced
> capacity (e.g. the upcoming datacenter move)
>

I think the fundamental premise here is that rebuilds this way
requires commits into Dist-Git. With what Pierre-Yves and his group
released last week for testing[1], that may no longer be an issue.

[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LWE4URIRWVTEZKXKP7QOK5JXFNVJRUNW/



--
真実はいつも一つ！/ Always, there's only one truth!
___
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-20200413.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (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: Firefox related unbundle?

[Kevin Kofler]

Jeremy Newton wrote:
> Looks like cubeb is apart of the Firefox source tree (./meda/libcubeb/).

Firefox also bundles the library, but the real upstream is:
https://github.com/kinetiknz/cubeb

If you want to unbundle the library, you should package it from there, and 
then maybe get Firefox to use the system version as well.

(That said, for better or for worse, the packaging guidelines no longer 
require unbundling libraries.)

Kevin Kofler
___
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: Outage: Migration of Copr servers - 2020-02-23 06:00 UTC

[Jun Aruga]

> > Fedora Infrastructure are in the middle of 2 data center moves currently
> > with a COVID-19 lockdown affecting our ability to give any timelines of
> > when things will be available. I do not think the servers will be available
> > until May at the earliest and they will be a lower priority than keeping
> > koji or other core Fedora services going.
>
> Yeah, this sounds OK.  Good luck with the movement.

Yeah, OK. Thanks for the work.

> > Currently copr is running out of amazon and does not have emulation
> > capabilities either.
>
> We already enabled emulated armhfp (on x86_64) builders in copr (that's 
> probably
> what Jun meant)... it's the software emulation by qemu-user-static (mock
> --forcearch).

Yes, that is what I meant. The software emulation by qemu-user-static.

> @Jun wrote:
> > Any update for Copr ppc64le chroots?
>
> People were used to use native machines for ppc64le targets, so the
> temporary switch to emulated variant could cause more harm then good here.
> I'd rather wait till May for the native builders then mix-up.

I agree with you. I am okay to wait rather than starting
qemu-user-static emulation for ppc64le targets now.

-- 
Jun | He - His - Him
___
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: Why does Koschei not run real builds?

[Fabio Valentini]

On Mon, Apr 13, 2020 at 10:55 AM Dan Čermák
 wrote:
>
> Hi list,
>
> my question is pretty much $subject: Why doesn't Koschei kick of
> real builds off packages on dependency changes? From my naive POV that
> looks like the missing piece to give us the "OBS-experience". Having
> that at least in Rawhide sounds like a good thing to me.

It *might* be a good idea to help deal with rebuilds, but I see some
problems with that.

- koschei would need to add "rebuilt by koschei" commits to dist-git
for this (OBS doesn't have a real VCS, so it's not a problem there)
- those changes would add a lot of churn to .spec files, possibly
angering a lot of packagers, and would also create possible conflicts
between local changes and koschei builds
- the builds add a lot of load to koji already (although at lower
priority), which will probably be a problem when there's reduced
capacity (e.g. the upcoming datacenter move)

Fabio

> Cheers,
>
> Dan
> ___
> 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

Why does Koschei not run real builds?

[Dan Čermák]

Hi list,

my question is pretty much $subject: Why doesn't Koschei kick of
real builds off packages on dependency changes? From my naive POV that
looks like the missing piece to give us the "OBS-experience". Having
that at least in Rawhide sounds like a good thing to me.


Cheers,

Dan


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

[Test-Announce] Fedora Kernel 5.6 Test Week Changes

[Sumantro Mukherjee]

Hey All,

The Fedora Kernel  5.6 Test Week[0] is underway. The communishift -
where the test day app resided is now going through downtown and
Fedora QA folks have moved the app to a different location to survive
this downtime. if, for some reason you get an error, please let me
know and bear with us. It will be up shortly.
For the time being, everyone can edit the wiki (an example for
reference is given)[1].
Don't forget to submit your logs after running the regression test
cases[2]. The steps to test kernel for regression have been well
documented in the wiki as well as here[3].
Also we are testing for non x86-64, if you are one who is using and
have some free bandwidth,please test and submit the logs [4]

[0] https://fedoraproject.org/wiki/Test_Day:2020-04-13_Kernel_5.6_Test_Week
[1] 
https://fedoraproject.org/wiki/Test_Day:2020-04-13_Kernel_5.6_Test_Week#Regression_Test
[2] https://fedoraproject.org/wiki/QA:Testcase_kernel_regression
[3] https://docs.fedoraproject.org/en-US/quick-docs/kernel/howto-kernel-testday/
[4] 
https://jforbes.fedorapeople.org/testweek/fedora-coreos-5.6-testweek-qemu.x86_64.qcow2

-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
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

Fedora-Cloud-30-20200413.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (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: Self Introduction: Dev Singh

[Benson Muite]

On Sun, Apr 12, 2020, at 7:12 PM, Dev Singh wrote:
> Hello everyone,
> My name is Dev Singh and I am a student developer in the Chicagoland area in 
> the US. I have worked in various open-source applications and in FRC 
> robotics. I am hoping to be the package manager for the `thinkpad-tools` 
> package which allows the user manage various Lenovo ThinkPad laptop 
> properties. I am also the upstream developer for this project. I have filed a 
> review request here . 
> 
> I can be found on GitHub as devksingh4, and my GPG fingerprint is: 62DC 96FF 
> 5DA4 7C02 D90D 3EB9 AA2E 907F 4513 25A6.
> 
> I look forward to working with you all at some point. I hope you all have a 
> wonderful day and are staying healthy!
> 
> 
> Best, 
> Dev Singh
> 
> 

Hello Dev and welcome to Fedora. We hope Lenovo users can have a more 
productive experience because of you.

Regards,
Benson
___
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