[389-devel] 389 DS nightly 2020-09-12 - 94% PASS

[vashirov]

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

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Christopher]

On Fri, Sep 11, 2020 at 2:02 PM Adam Williamson
 wrote:
>
> On Fri, 2020-09-11 at 12:44 +0300, Aleksandar Kurtakov wrote:
> > On Fri, Sep 11, 2020 at 11:54 AM Tomasz Torcz  wrote:
> >
> > > On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> > > > You get a side tag in Koji where you can have private build-only
> > > > dependencies that are discarded (filtered) once they are no longer
> > > > needed, after module build is done. For build-only packages most of
> > > > security vulnerabilities are not exploitable easily, or at all,
> > > > therefore are low-severity, which greatly limits maintenance work
> > > > required to address them. For example, if upstream tests are ran on an
> > > > obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> > > > but I can package old Tomcat and run the tests.
> > >
> > >   Whoha! Let's step back for a minute and look at this example.
> > > What are the reasons to run tests?  To make sure the package will run
> > > correctly..
> > > Why run tests on 12-years old version instead of on current one?
> > > Probably because tests fail on current version?
> > >
> > >   Will the end user run the package on obsolete Tomcat or on the current
> > > one?
> > > Of course on the current one. The one on which tests fail.
> > > Tests in this case are worthless, they are not testing the real
> > > situation. Disabling tests is no worse than testing on obsolete version.
> > > Relying on such tests is a disservice for the end user.
> > >
> > >   The point of testing is to validate code in real situation.
> > > Crafting special, unrealistic environment (12 years old Tomcat) just to
> > > have
> > > test pass is missing the point of tests.
> > >
> >
> > Well, you do realize how much not feasible it is for the Fedora maintainer
> > of hundred packages to go out and not only fix the builds, bugs, CVEs and
> > etc. but even the tests for all these packages. The unrealistic
> > expectations for what package maintainer should do is really not helping
> > growing that number.
>
> I've been struggling with how to make this point without sounding
> cynical, but hey, let's just lay it out there:
>
> If one of the issues here can be stated as "we want buildroot-only
> packages because we don't want to maintain those packages to a high
> standard", it is demonstrably a viable choice within Fedora to just
> *not maintain those packages to a high standard*. Maybe we wish it
> wasn't the case, but this is a thing that happens all the time. We have
> lots of packages that are, by any reasonable standard, rather badly
> maintained. It would be lovely if all Fedora packages had all their
> bugs aggressively addressed and had great test suites and had CVE
> issues jumped on immediately. But, well, the evidence suggests quite
> strongly that this is not the case. For e.g., I did a very sloppy
> search yesterday for Fedora bugs with "CVE" in the topic which were
> opened before June 2 and are still open:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=__open__=%5BBug%20creation%5D=2020-06-01=Fedora_id=11345766_format=advanced_desc=CVE_desc_type=allwordssubstr
>
> it is capped at 1000 results. Which, you know, doesn't *scream* that
> all our packages are being diligently maintained from a CVE point of
> view, which implies at least some of them aren't being diligently
> maintained from any point of view. Even if some or many of those CVEs
> happen to have been fixed by version updates and it's just that the
> bugs weren't closed - the very fact that the bugs aren't being handled
> is a maintenance issue.
>
> So here is my cynical point: if you want to have poorly-maintained
> packages, isn't it still better that they be poorly-maintained distro
> packages where at least everyone understands how the process works and
> proven packagers can fix stuff up if they are inclined to, than that
> they be hidden buildroot-only poorly maintained packages?

Thank you for making these points. These are my thoughts *exactly*. As
a newcomer to packaging, I was willing to start helping out with those
packages that I depended on, to bring them up to speed, and it was
relatively easy to take on a few, because everything was out in the
open. But once things started getting retired (at a pace I couldn't
keep up with), even though they were still technically maintained in
some hidden world that I didn't understand, I was completely turned
off from helping out with more of the dependencies that my Java
projects required and had to retire my Java packages as well.

I would go further to suggest that poorly-maintained libs like these
are perfect opportunities for mentoring new people and community
growth.
FWIW, every year in October, for the past several years, Digital Ocean
and GitHub have teamed up to sponsor "Hacktoberfest" (I've
participated, but am not affiliated with either of them at all).
Projects label their issues with a "Hacktoberfest" or "Good first
issue" 

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

[Adam Williamson]

# F33 Blocker Review meeting
# Date: 2020-09-14
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 11 proposed Beta freeze exceptions and 3 proposed
Final blockers to review, so let's have a Fedora 33 blocker review
meeting on Monday! Above numbers are subject to change...

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

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

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

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

Have a good weekend and see you on Monday!

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

[Test-Announce] 2020-09-14 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2020-09-14
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We didn't meet for a few weeks, so let's get together and check in.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 33 status
3. Outstanding criteria proposals
4. Test Day / community event status
5. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 / Rawhide user heads up: did a recent update pull in a bunch of packages you don't really want?

[Adam Williamson]

On Fri, 2020-09-11 at 23:13 +0100, Sérgio Basto wrote:
> On Fri, 2020-09-11 at 14:40 -0700, Adam Williamson wrote:
> > Just figured a heads-up here might help people. If you recently
> > updated
> > your system and got a whole bunch (~90, depending on how many were
> > already installed) of packages pulled in by...something - including
> > scala, vtk and a bunch of other odd things - I can tell you why: it
> > was
> > caused by a change to gstreamer1-plugins-bad-free . Its opencv
> > support
> > was enabled, but that gives it a dep on opencv-core, and opencv-core
> > pulls in all that other stuff.
> > 
> > We have now rebuilt gstreamer1-plugins-bad-free without opencv
> > support
> > again for Rawhide and F33, and edited the F33 update:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-ac045d6620
> > if you update to gstreamer1-plugins-bad-free-1.18.0-2 , you should be
> > able to get rid of all that stuff again. Just removing the opencv
> > packages may trigger dnf to remove all the others as unneeded deps,
> > or
> > one of the dnf cleanup commands may get rid of it for you, or you can
> > figure the list out from the dnf history.
> 
> Hi, as you wrote and I agree "I suppose we could also look into whether
> opencv-core actually needs all those deps, or if it could be split up a
> bit" 
>  
> 
> I think we can do gstreamer1-plugins-bad-free-opencv sub-package 
> and opencv maybe should have one vtk sub-package. I guess vtk needs a
> lot of packages. vtk is a package that takes more than 8 hours to
> compile on koji ...

I've filed a bug for opencv:
https://bugzilla.redhat.com/show_bug.cgi?id=1878320

I feel like we could just do what Debian does and give each opencv lib
its own subpackage. That'd certainly isolate the deps so anything that
uses opencv only pulls in the deps of the opencv lib(s) it actually
uses.
-- 
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

[EPEL-devel] Re: Proposing an EPEL packaging SIG

[Michel Alexandre Salim]

We discussed the proposal a bit at today's EPEL SC meeting; here's a
revised proposal taking into account the suggestions from the meeting
and earlier in this list.

## The SIG
- bstinson pointed out that epel-wranglers was started to address the
same issue, we can resurrect that
- we want to limit the access to epel* branches only, not all branches,
as suggested both here and at the meeting. Any change the epel-
wranglers want to make to the Rawhide branch can be done as a PR
  - the EPEL branch will likely diverge from master over time anyway
- the collaborator permission (available since August, yay) can be used
for such granular access
  - nirik pointed out that collaborators can't yet request new
branches, if the proposal is approved we can work on making the `fedpkg
request-branch` flow support this
  - carlwgeorge suggested getting the group up and running first, and
working on automation later

## Workflow
- no objection that I recall to having epel-wranglers automatically get
access if the Fedora maintainers do not respond (so we can circumvent
needing to do a non-responsive maintainer request)
  - we probably won't have this automated at the beginning, see above
- down the line, epel-wranglers need to decide on what to do with
releases they no longer want to support (e.g. when everyone involved
only cares about epel10 and epel9 and there's a CVE affecting epel8).
the normal orphan process probably works - we announce the package is
being orphaned by the group on epel-devel

Let's continue discussing the proposal in this thread, as suggested
during the meeting.

Thanks all,

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


signature.asc
Description: This is a digitally signed message part
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] Re: Proposing an EPEL packaging SIG

[Michel Alexandre Salim]

We discussed the proposal a bit at today's EPEL SC meeting; here's a
revised proposal taking into account the suggestions from the meeting
and earlier in this list.

## The SIG
- bstinson pointed out that epel-wranglers was started to address the
same issue, we can resurrect that
- we want to limit the access to epel* branches only, not all branches,
as suggested both here and at the meeting. Any change the epel-
wranglers want to make to the Rawhide branch can be done as a PR
  - the EPEL branch will likely diverge from master over time anyway
- the collaborator permission (available since August, yay) can be used
for such granular access
  - nirik pointed out that collaborators can't yet request new
branches, if the proposal is approved we can work on making the `fedpkg
request-branch` flow support this
  - carlwgeorge suggested getting the group up and running first, and
working on automation later

## Workflow
- no objection that I recall to having epel-wranglers automatically get
access if the Fedora maintainers do not respond (so we can circumvent
needing to do a non-responsive maintainer request)
  - we probably won't have this automated at the beginning, see above
- down the line, epel-wranglers need to decide on what to do with
releases they no longer want to support (e.g. when everyone involved
only cares about epel10 and epel9 and there's a CVE affecting epel8).
the normal orphan process probably works - we announce the package is
being orphaned by the group on epel-devel

Let's continue discussing the proposal in this thread, as suggested
during the meeting.

Thanks all,

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


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

Re: Modules without packaged non-modular versions (Was Re: The Future of the Java Stack (also regarding ELN and RHEL))

[Miro Hrončok]

On 11. 09. 20 22:55, Jie Kang wrote:

On Thu, Sep 10, 2020 at 11:10 AM Miro Hrončok  wrote:


On 10. 09. 20 16:53, Vitaly Zaitsev via devel wrote:

I think FESCo should completely forbid modules without packaged
non-modular versions.


It did.


Hi,

Can you share the ticket/issue for this restriction with me?


https://pagure.io/fesco/issue/2406

Modular-only packages are not allowed and modular versions are only allowed as 
alternatives to non-modular packages. There is an exception to this rule: if the 
package does not function in non-modular Fedora (with reasonable amount of 
work), it is permitted to have it in module only. As an example if non-modular 
Fedora has dnf 4, and there is module with dnf 5, a package that only works with 
dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora. 
For the time being, such exceptions can be granted by FESCo.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modules without packaged non-modular versions (Was Re: The Future of the Java Stack (also regarding ELN and RHEL))

[Fabio Valentini]

On Fri, Sep 11, 2020 at 10:56 PM Jie Kang  wrote:
>
> On Thu, Sep 10, 2020 at 11:10 AM Miro Hrončok  wrote:
> >
> > On 10. 09. 20 16:53, Vitaly Zaitsev via devel wrote:
> > > I think FESCo should completely forbid modules without packaged
> > > non-modular versions.
> >
> > It did.
>
> Hi,
>
> Can you share the ticket/issue for this restriction with me?
>
>
> Thank you,
> Jie

The FESCo ticket is here:
https://pagure.io/fesco/issue/2406

Specifically, the decisions are documented in this comment:
https://pagure.io/fesco/issue/2406#comment-658315

The relevant one being the unanimous decision to ban modular-only packages:

"AGREED: Modular-only packages are not allowed and modular versions
are only [to] be allowed as alternatives to non-modular packages. (+9, 0, -0)"

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

Re: F33 / Rawhide user heads up: did a recent update pull in a bunch of packages you don't really want?

[Sérgio Basto]

On Fri, 2020-09-11 at 14:40 -0700, Adam Williamson wrote:
> Just figured a heads-up here might help people. If you recently
> updated
> your system and got a whole bunch (~90, depending on how many were
> already installed) of packages pulled in by...something - including
> scala, vtk and a bunch of other odd things - I can tell you why: it
> was
> caused by a change to gstreamer1-plugins-bad-free . Its opencv
> support
> was enabled, but that gives it a dep on opencv-core, and opencv-core
> pulls in all that other stuff.
> 
> We have now rebuilt gstreamer1-plugins-bad-free without opencv
> support
> again for Rawhide and F33, and edited the F33 update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-ac045d6620
> if you update to gstreamer1-plugins-bad-free-1.18.0-2 , you should be
> able to get rid of all that stuff again. Just removing the opencv
> packages may trigger dnf to remove all the others as unneeded deps,
> or
> one of the dnf cleanup commands may get rid of it for you, or you can
> figure the list out from the dnf history.

Hi, as you wrote and I agree "I suppose we could also look into whether
opencv-core actually needs all those deps, or if it could be split up a
bit" 
 
I think we can do gstreamer1-plugins-bad-free-opencv sub-package 
and opencv maybe should have one vtk sub-package. I guess vtk needs a
lot of packages. vtk is a package that takes more than 8 hours to
compile on koji ...

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

Re: F33 update stuck for past 6 days in request for testing->stable

[Kevin Fenzi]

On Fri, Sep 11, 2020 at 04:35:03PM -0500, Tony Asleson wrote:
> This release:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b
> 
> has been stuck waiting to get moved to stable.  Is some error going on
> that isn't evident?

We are in Beta freeze. Only packages that fix accepted blocker bugs or
freeze break exceptions can go stable. 

https://fedoraproject.org/wiki/Milestone_freezes

> 
> This was a release that I did to hopefully correct what is discussed here:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N5Y6J4MBBA5IKAHWG4CIS644WAHYVCZC/

You can request a freeze break if you like: 
https://fedoraproject.org/wiki/Milestone_freezes#How_are_freeze_exceptions_proposed_and_granted.3F
or just wait until after Beta is signed off on and updates will start
flowing to stable again (until final freeze). 

kevin


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

Re: What is the status of this F33 update?

[Jerry James]

On Fri, Sep 11, 2020 at 2:19 PM Richard W.M. Jones  wrote:
> On Fri, Sep 11, 2020 at 10:15:06PM +0200, Miro Hrončok wrote:
> > This worked (and pushed the update to testing automatically).
>
> Ah great, thanks Miro!

Just to set Richard's mind at ease: I'm not going to do any OCaml
builds for F33 until Beta is out AND this update has gone stable.  I'm
afraid I'll break something. :-)
-- 
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

F33 / Rawhide user heads up: did a recent update pull in a bunch of packages you don't really want?

[Adam Williamson]

Just figured a heads-up here might help people. If you recently updated
your system and got a whole bunch (~90, depending on how many were
already installed) of packages pulled in by...something - including
scala, vtk and a bunch of other odd things - I can tell you why: it was
caused by a change to gstreamer1-plugins-bad-free . Its opencv support
was enabled, but that gives it a dep on opencv-core, and opencv-core
pulls in all that other stuff.

We have now rebuilt gstreamer1-plugins-bad-free without opencv support
again for Rawhide and F33, and edited the F33 update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-ac045d6620
if you update to gstreamer1-plugins-bad-free-1.18.0-2 , you should be
able to get rid of all that stuff again. Just removing the opencv
packages may trigger dnf to remove all the others as unneeded deps, or
one of the dnf cleanup commands may get rid of it for you, or you can
figure the list out from the dnf history.

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

F33 update stuck for past 6 days in request for testing->stable

[Tony Asleson]

This release:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-4da598e74b

has been stuck waiting to get moved to stable.  Is some error going on
that isn't evident?

This was a release that I did to hopefully correct what is discussed here:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/N5Y6J4MBBA5IKAHWG4CIS644WAHYVCZC/

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

regression: Xen boot entries ask for non-exisiting grub2 module2.mod

[PGNet Dev]

on

grep PRETTY /etc/os-release
PRETTY_NAME="Fedora 32 (Server Edition)"

uname -rm
5.8.7-200.fc32.x86_64 x86_64

with

rpm -qa | grep xen
xen-4.13.1-4.fc32.x86_64
xen-hypervisor-4.13.1-4.fc32.x86_64
xen-libs-4.13.1-4.fc32.x86_64
xen-licenses-4.13.1-4.fc32.x86_64
xen-runtime-4.13.1-4.fc32.x86_64

rpm -qa | grep grub
grub2-common-2.04-21.fc32.noarch
grub2-efi-x64-2.04-21.fc32.x86_64
grub2-efi-x64-modules-2.04-21.fc32.noarch
grub2-tools-2.04-21.fc32.x86_64
grub2-tools-extra-2.04-21.fc32.x86_64
grub2-tools-minimal-2.04-21.fc32.x86_64
grubby-8.40-40.fc32.x86_64
grubby-deprecated-8.40-40.fc32.x86_64

on boot-to-Xen

...
Loading Xen 4.13.1 ...
error: ../../grub-core/fs/fshelp.c:257:file
`/EFI/fedora/x86_64-efi/module2.mod' not
found.
Loading Linux 5.8.7-200.fc32.x86_64 ...
Loading initial ramdisk ...
error: ../../grub-core/fs/fshelp.c:257:file
`/EFI/fedora/x86_64-efi/module2.mod' not
found.

Press any key to continue...
...

waits 10-20 seconds, then continues

0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0xa14d0018
0x:0x04:0x00.0x0: ROM: 0x8000 bytes at 0xa14c7018
0x:0x10:0x00.0x0: ROM: 0x10800 bytes at 0xa14a5018
 Xen 4.13.1
(XEN) [0011c8b7c914] Xen version 4.13.1 (mockbuild@[unknown]) (gcc 
(GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)) debug=n  Tu0
(XEN) [0011cb3cbe4f] Latest ChangeSet: 
(XEN) [0011cbfaf8f8] build-id: 
131db801fd9d8ed1fbc017e12b9a13570043e404
...

to successful boot, xen start,

xl list
NameID   Mem VCPUs  
State   Time(s)
Domain-0 0  4016 4 
r-  34.8
Xenstore 131 1 
-b   0.0

this issue has been raised multiple times

https://bodhi.fedoraproject.org/updates/FEDORA-2017-bd36ce6cfd
https://bugzilla.redhat.com/show_bug.cgi?id=1486002
https://bugzilla.redhat.com/show_bug.cgi?id=1858364

atm, it remains unresolved

where does this correctly need to get addressed?
grub2/xen?
fedora/upstream?
new bug/reopened old?
___
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: Proposing an EPEL packaging SIG

[Michel Alexandre Salim]

On Fri, 2020-09-11 at 15:44 -0400, Neal Gompa wrote:
> On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood 
> wrote:
> > Michel Alexandre Salim  writes:
> > 
> > > * Have an expedited flow where this SIG can request EPEL branches
> > > and
> > > admin access to packages if there are no response from package
> > > maintainers for a set period (3 days? 1 week?)
> > >   * whether it should be full admin access or whether such access
> > > should be scoped to epel* branches can be discussed. Full admin
> > > would
> > > make it possible to adjust the spec in Rawhide to be more EPEL
> > > friendly, for example
> > 
> > Unless I've missed something, we still don't have per-branch ACLs
> > in
> > dist-git.
> > 
> > I don't think it's okay to force maintainers to give you admin or
> > commit
> > to their packages just because you want them in EPEL.
> > 
Fair enough, I think if the maintainer does not explicitly grant
permission, any automatic grant should be limited to epel-* branches.

> > (I'm also not one of the kind of people who really like having one
> > spec
> > file for all versions of the package, but I know others disagree
> > with me
> > on this.  Certainly if hypothetically I didn't want to maintain an
> > EPEL
> > package I wouldn't want its logic /also/ foisted on me in rawhide.)
> > 
Yeah. I'm in-between on this, I try to get changes into the Rawhide
branch if they are not too intrusive, and keep them in the EPEL
branches if they are. EPEL maintainers can always just submit a PR
against the Rawhide branch so not having automatic access is no big
deal.

> 
> We have per-branch ACLs in Dist-Git since early August. The
> collaborator role in Pagure lets you grant people commit access for
> specific branches.
> 
Yeah, the collaborator role is what I had in mind but I didn't remember
the exact name when writing it (should have just looked it up in
src.fedoraproject.org). Thanks Neal!

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


signature.asc
Description: This is a digitally signed message part
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Proposing an EPEL packaging SIG

[Michel Alexandre Salim]

On Fri, 2020-09-11 at 15:44 -0400, Neal Gompa wrote:
> On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood 
> wrote:
> > Michel Alexandre Salim  writes:
> > 
> > > * Have an expedited flow where this SIG can request EPEL branches
> > > and
> > > admin access to packages if there are no response from package
> > > maintainers for a set period (3 days? 1 week?)
> > >   * whether it should be full admin access or whether such access
> > > should be scoped to epel* branches can be discussed. Full admin
> > > would
> > > make it possible to adjust the spec in Rawhide to be more EPEL
> > > friendly, for example
> > 
> > Unless I've missed something, we still don't have per-branch ACLs
> > in
> > dist-git.
> > 
> > I don't think it's okay to force maintainers to give you admin or
> > commit
> > to their packages just because you want them in EPEL.
> > 
Fair enough, I think if the maintainer does not explicitly grant
permission, any automatic grant should be limited to epel-* branches.

> > (I'm also not one of the kind of people who really like having one
> > spec
> > file for all versions of the package, but I know others disagree
> > with me
> > on this.  Certainly if hypothetically I didn't want to maintain an
> > EPEL
> > package I wouldn't want its logic /also/ foisted on me in rawhide.)
> > 
Yeah. I'm in-between on this, I try to get changes into the Rawhide
branch if they are not too intrusive, and keep them in the EPEL
branches if they are. EPEL maintainers can always just submit a PR
against the Rawhide branch so not having automatic access is no big
deal.

> 
> We have per-branch ACLs in Dist-Git since early August. The
> collaborator role in Pagure lets you grant people commit access for
> specific branches.
> 
Yeah, the collaborator role is what I had in mind but I didn't remember
the exact name when writing it (should have just looked it up in
src.fedoraproject.org). Thanks Neal!

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


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

Modules without packaged non-modular versions (Was Re: The Future of the Java Stack (also regarding ELN and RHEL))

[Jie Kang]

On Thu, Sep 10, 2020 at 11:10 AM Miro Hrončok  wrote:
>
> On 10. 09. 20 16:53, Vitaly Zaitsev via devel wrote:
> > I think FESCo should completely forbid modules without packaged
> > non-modular versions.
>
> It did.

Hi,

Can you share the ticket/issue for this restriction with me?


Thank you,
Jie

>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 blocker status , with CALL FOR TESTING on abrt/libreport

[Adam Williamson]

On Fri, 2020-09-11 at 15:50 -0400, Ben Cotton wrote:
> 
> Accepted blockers
> -
> 1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — ON_QA
> abrt-server errors when processing zstd compressed core dumps produced
> by systemd-246~rc1-1.fc33
> 
> FEDORA-2020-59e144acee contains a potential fix, but appears to
> introduce a new blocker (BZ 1873029). It may be moot until the retrace
> server is brought back online. The infra team has provisioned a basic
> instance, which msuchy is working to get ready for use.

So yeah: it would really help if other folks could try installing the
update and see if they are able to successfully file a crash bug or
not. Please report your findings to the bug report(s).

Reporting bugs *is* supposed to work even if using the retrace server
doesn't. In that case abrt should fall back on installing debuginfo
locally and generating the backtrace locally (after confirming with the
user that this is OK). If that doesn't happen currently, that also
could be considered a bug.

My basic thought here is that for Beta release it would be acceptable
if we can file crash bugs successfully, even if the retrace server
isn't up. Obviously the faster we can get the retrace server up the
better.
> 
> 3. distribtution — https://bugzilla.redhat.com/show_bug.cgi?id=1849430
> — ASSIGNED
> Everything boot x86_64 image exceeds maximum size
> 
> Latest compose does not significantly shrink the image size. Given the
> similar nature of the overages, I believe fixing the Server image
> size, which sgallagh is working on, will fix this as well.
> 
> 4. distribtution — https://bugzilla.redhat.com/show_bug.cgi?id=1849431
> — ASSIGNED
> Server boot x86_64 image exceeds maximum size
> 
> We need to slim it down by ~14 MB.

I've been working on this. One PR was merged to Rawhide already:
https://github.com/weldr/lorax/pull/1070
but not yet to the F33 branch. I have an equivalent for F33 pending:
https://github.com/weldr/lorax/pull/1073
Plus a couple of further changes currently proposed for Rawhide but
which I will also submit for F33:
https://github.com/weldr/lorax/pull/1075
https://github.com/weldr/lorax/pull/1076
I have one more to go on top of 1075 when/if it's merged. If we take
all these changes, the images should be 20-30MB or so under the limit.
We can also take any combination of whichever people think are the
safest to try and get under the limit.
-- 
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: Proposing an EPEL packaging SIG

[Robbie Harwood]

Neal Gompa  writes:

> On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood  wrote:
>>
>> Michel Alexandre Salim  writes:
>>
>> > * Have an expedited flow where this SIG can request EPEL branches and
>> > admin access to packages if there are no response from package
>> > maintainers for a set period (3 days? 1 week?)
>> >   * whether it should be full admin access or whether such access
>> > should be scoped to epel* branches can be discussed. Full admin would
>> > make it possible to adjust the spec in Rawhide to be more EPEL
>> > friendly, for example
>>
>> Unless I've missed something, we still don't have per-branch ACLs in
>> dist-git.
>>
>> I don't think it's okay to force maintainers to give you admin or commit
>> to their packages just because you want them in EPEL.
>>
>> (I'm also not one of the kind of people who really like having one spec
>> file for all versions of the package, but I know others disagree with me
>> on this.  Certainly if hypothetically I didn't want to maintain an EPEL
>> package I wouldn't want its logic /also/ foisted on me in rawhide.)
>
> We have per-branch ACLs in Dist-Git since early August. The
> collaborator role in Pagure lets you grant people commit access for
> specific branches.

Excellent!

Thanks,
--Robbie


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

Re: What is the status of this F33 update?

[Richard W.M. Jones]

On Fri, Sep 11, 2020 at 10:15:06PM +0200, Miro Hrončok wrote:
> On 11. 09. 20 22:11, Richard W.M. Jones wrote:
> >On Fri, Sep 11, 2020 at 10:03:11PM +0200, Miro Hrončok wrote:
> >>On 11. 09. 20 21:57, Richard W.M. Jones wrote:
> >>>I built libnbd against the side tag (libnbd-1.4.1-1.fc33.1) but can't
> >>>work out how to add it to the update.  There seems to be no way to
> >>>edit the list of packages AFAICT.
> >>
> >>That is https://github.com/fedora-infra/bodhi/issues/4122
> >>
> >>Using the CLI worked for me.
> >
> >$ bodhi updates edit --addbuilds libnbd-1.4.1-1.fc33.1 FEDORA-2020-3f6760cc65
> >Cannot find release associated with build: libnbd-1.4.1-1.fc33.1, tags: 
> >['f33-build-side-29131']
> >
> >I thought this might work after reading the --help output, but it
> >doesn't appear to:
> >
> >$ bodhi updates edit --from-tag f33-build-side-29131 FEDORA-2020-3f6760cc65
> >Usage: bodhi updates edit [OPTIONS] UPDATE
> >
> >Error: Invalid value for 'UPDATE': Please provide an Update ID
> 
> $ bodhi updates edit --removebuilds libnbd-1.4.0-2.fc33.1 
> FEDORA-2020-3f6760cc65
> $ koji tag f33-updates-candidate libnbd-1.4.1-1.fc33.1
> $ bodhi updates edit --addbuilds libnbd-1.4.1-1.fc33.1 FEDORA-2020-3f6760cc65
> 
> This worked (and pushed the update to testing automatically).

Ah great, thanks Miro!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: What is the status of this F33 update?

[Miro Hrončok]

On 11. 09. 20 22:11, Richard W.M. Jones wrote:

On Fri, Sep 11, 2020 at 10:03:11PM +0200, Miro Hrončok wrote:

On 11. 09. 20 21:57, Richard W.M. Jones wrote:

I built libnbd against the side tag (libnbd-1.4.1-1.fc33.1) but can't
work out how to add it to the update.  There seems to be no way to
edit the list of packages AFAICT.


That is https://github.com/fedora-infra/bodhi/issues/4122

Using the CLI worked for me.


$ bodhi updates edit --addbuilds libnbd-1.4.1-1.fc33.1 FEDORA-2020-3f6760cc65
Cannot find release associated with build: libnbd-1.4.1-1.fc33.1, tags: 
['f33-build-side-29131']

I thought this might work after reading the --help output, but it
doesn't appear to:

$ bodhi updates edit --from-tag f33-build-side-29131 FEDORA-2020-3f6760cc65
Usage: bodhi updates edit [OPTIONS] UPDATE

Error: Invalid value for 'UPDATE': Please provide an Update ID


$ bodhi updates edit --removebuilds libnbd-1.4.0-2.fc33.1 FEDORA-2020-3f6760cc65
$ koji tag f33-updates-candidate libnbd-1.4.1-1.fc33.1
$ bodhi updates edit --addbuilds libnbd-1.4.1-1.fc33.1 FEDORA-2020-3f6760cc65

This worked (and pushed the update to testing automatically).

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What is the status of this F33 update?

[Adam Williamson]

On Fri, 2020-09-11 at 22:04 +0200, Miro Hrončok wrote:
> On 11. 09. 20 22:01, Adam Williamson wrote:
> > When you hit edit, it shows the builds in the update already, and there
> > *should*  be a button to remove each, but indeed I don't see it on that
> > update. Not sure why not.
> 
> https://github.com/fedora-infra/bodhi/issues/4122

Yeah thanks, I saw - didn't realize it was a side tag thing.
-- 
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: What is the status of this F33 update?

[Richard W.M. Jones]

On Fri, Sep 11, 2020 at 10:03:11PM +0200, Miro Hrončok wrote:
> On 11. 09. 20 21:57, Richard W.M. Jones wrote:
> >I built libnbd against the side tag (libnbd-1.4.1-1.fc33.1) but can't
> >work out how to add it to the update.  There seems to be no way to
> >edit the list of packages AFAICT.
> 
> That is https://github.com/fedora-infra/bodhi/issues/4122
> 
> Using the CLI worked for me.

$ bodhi updates edit --addbuilds libnbd-1.4.1-1.fc33.1 FEDORA-2020-3f6760cc65  
Cannot find release associated with build: libnbd-1.4.1-1.fc33.1, tags: 
['f33-build-side-29131']

I thought this might work after reading the --help output, but it
doesn't appear to:

$ bodhi updates edit --from-tag f33-build-side-29131 FEDORA-2020-3f6760cc65  
Usage: bodhi updates edit [OPTIONS] UPDATE

Error: Invalid value for 'UPDATE': Please provide an Update ID

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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

Is there a Qt5 rebuild in progress?

[Miro Hrončok]

Hello,

dozens of my packages suddenly fail to resolve build dependencies with things 
like the ones below.


Is there a Qt5 rebuild in progress?

This build seem to be tagged in a side tag and also in f34:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1608618

Is that on purpose?



Problem: package qt5-qtscript-devel-5.14.2-4.fc33.x86_64 requires 
qt5-qtscript(x86-64) = 5.14.2-4.fc33, but none of the providers can be installed
- package qt5-qtscript-devel-5.14.2-4.fc33.x86_64 requires 
libQt5Script.so.5()(64bit), but none of the providers can be installed
- package qt5-qtscript-devel-5.14.2-4.fc33.x86_64 requires 
libQt5ScriptTools.so.5()(64bit), but none of the providers can be installed

- conflicting requests
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtscript-5.14.2-4.fc33.x86_64
- nothing provides libQt5Widgets.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtscript-5.14.2-4.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtscript-5.14.2-4.fc33.x86_64
Problem: package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
qt5-qtxmlpatterns(x86-64) = 5.14.2-3.fc33, but none of the providers can be 
installed
- package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
libQt5XmlPatterns.so.5()(64bit), but none of the providers can be installed
- package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
libQt5XmlPatterns.so.5(Qt_5)(64bit), but none of the providers can be installed

- conflicting requests
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64
- nothing provides libQt5Qml.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64


Problem: conflicting requests
- nothing provides libQt5Gui.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qttools-devel-5.14.2-3.fc33.x86_64
Problem: package pcl-devel-1.11.0-4.fc33.x86_64 requires vtk-devel, but none of 
the providers can be installed
- package vtk-devel-8.2.0-23.fc34.x86_64 requires cmake(Qt5UiPlugin), but none 
of the providers can be installed

- conflicting requests
- nothing provides libQt5Gui.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qttools-devel-5.14.2-3.fc33.x86_64
Problem: package qt5-qtsvg-devel-5.14.2-3.fc33.x86_64 requires qt5-qtsvg(x86-64) 
= 5.14.2-3.fc33, but none of the providers can be installed
- package qt5-qtsvg-devel-5.14.2-3.fc33.x86_64 requires libQt5Svg.so.5()(64bit), 
but none of the providers can be installed

- conflicting requests
- nothing provides libQt5Gui.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtsvg-5.14.2-3.fc33.x86_64
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtsvg-5.14.2-3.fc33.x86_64
- nothing provides libQt5Widgets.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtsvg-5.14.2-3.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtsvg-5.14.2-3.fc33.x86_64
Problem: package qt5-qttools-static-5.14.2-3.fc33.x86_64 requires 
qt5-qttools-devel(x86-64) = 5.14.2-3.fc33, but none of the providers can be 
installed

- conflicting requests
- nothing provides libQt5Gui.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qttools-devel-5.14.2-3.fc33.x86_64
Problem: package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
qt5-qtxmlpatterns(x86-64) = 5.14.2-3.fc33, but none of the providers can be 
installed
- package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
libQt5XmlPatterns.so.5()(64bit), but none of the providers can be installed
- package qt5-qtxmlpatterns-devel-5.14.2-3.fc33.x86_64 requires 
libQt5XmlPatterns.so.5(Qt_5)(64bit), but none of the providers can be installed

- conflicting requests
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64
- nothing provides libQt5Qml.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtxmlpatterns-5.14.2-3.fc33.x86_64


Problem: package qt5-qtgamepad-devel-5.14.2-3.fc33.x86_64 requires 
libQt5Gamepad.so.5()(64bit), but none of the providers can be installed
- package qt5-qtgamepad-devel-5.14.2-3.fc33.x86_64 requires 
qt5-qtgamepad(x86-64) = 5.14.2-3.fc33, but none of the providers can be installed

- conflicting requests
- nothing provides libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit) needed by 
qt5-qtgamepad-5.14.2-3.fc33.x86_64
- nothing provides qt5-qtbase(x86-64) = 5.14.2 needed by 
qt5-qtgamepad-5.14.2-3.fc33.x86_64
Problem: package qt5-qtmultimedia-devel-5.14.2-3.fc33.x86_64 requires 
libQt5Multimedia.so.5()(64bit), but none of the providers can be installed
- package qt5-qtmultimedia-devel-5.14.2-3.fc33.x86_64 requires 
libQt5MultimediaWidgets.so.5()(64bit), but none of the providers can be installed
- package 

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Hans de Goede]

Hi,

On 9/11/20 6:08 PM, Fabio Valentini wrote:

On Fri, Sep 11, 2020 at 1:06 PM Hans de Goede  wrote:


Hi,

On 9/11/20 12:47 PM, Vít Ondruch wrote:


Dne 11. 09. 20 v 11:03 Hans de Goede napsal(a):



On 9/11/20 10:16 AM, Mikolaj Izdebski wrote:


Another, more concrete example: core Ant doesn't have any dependencies
beyond JDK. It is easy to build and maintain, yet very functional. On
the other hand, full Ant with all the optional tasks depends on more
than 200 Java packages. For the purpose of building all packages that
I am interested in, core Ant with JUnit tasks (total of 3 packages) is
sufficient. Functionalities of Ant like sending emails or image
processing are obviously not needed in this case. If building other
packages is the only use of Ant then it can be maintained much more
easily (3 instead of ~250 packages). But when Ant is ursine package in
Fedora then it should be the full Ant - we can't claim to deliver Ant
to users while it is just part of it. Eclipse in Fedora requires full
Ant too.


So if you say that you only need the minimal Ant, and I guess many
packages only need the minimal Ant to build, then why not have
an ant-minimal package, like we have a vim-minimal ?

Now I guess that vim-minimal and "proper" vim are both build from the
same source-rpm; and normally we never allow 2 srpms with the same
upstream sources in them. But I think that in this case we could make
an exemption where there is a separate pkg-git and srpm for an
ant-minimal
which you would maintain.

And then the community / java-sig can maintain the full Ant as I believe
is already happening since we do have an ant packaged in Fedora 33 atm.



How this reduce the workload?


It doesn't the purpose of my email was to look for ways to get
the modular ant/maven repos work moved back into ursine without
increasing the workload for the maintainers of those modular
repos.

So the way to look at this, is does it increase workload,
and AFAICT it does not increase workload, while it would allow
us to fold the work being done in the modular repos back
into the ursine repo (for the ant example at least).

Alternatively if we fold that work back into the ursine repos,
then the modular builds could start relying on the full-blown
ant build maintained by the java-SIG in the ursine repos and
drop their own ant-minimal, at which point it would reduce the
workload for the maintainers of the modular repos.

My idea behind having a separate ant-minimal is that they
then can ensure that that is new enough and otherwise matches
their needs without relying on the full-blown version, but
actually somply switching to the full-blown java-SIG maintained
version might be better.

Regards,

Hans


(snip)


p.s.

I would not mind picking up maintenance of 1 or 2 of the
less frequently changing java packages (*) if that helps.
I wonder how much more people there are like me who care
enough about java to be willing to put some work in
(but not lots of work) ?

Perhaps it would be a good idea for the java-SIG to make
a list of easy to maintain (for an experienced packager)
pkgs which could use a new primary maintainer. I realize
maintaining the entire stack is a team effort, so the rest of
the java-SIG will of course be/stay a co-maintainer of these.
But having things like rebasing to latest upstream, or just
addressing bugzillas taken care of mostly by a new
primary maintainer who is willing to pick up some packages
might help reduce the load ?

The idea here is for someone (e.g.) me to NOT jump in now,
do a bunch of work to help out and then disappear again.
Instead I would invest say 1-2 hours every 2 weeks, which
may not seem much but over time adds up and if we can
get more people to do this, then maybe we can spread the
load of the java packages in the ursine repos better ?


That would be great, any help is appreciated.
I can try to come up with a list of often-used-but-simple-to-maintain
Java packages?


Yes that sounds great. I would be happy to pick up a few of
those to help and if a bunch of us do that hopefully we can
lighten the load a bit.

Regards,

Hans
___
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: What is the status of this F33 update?

[Miro Hrončok]

On 11. 09. 20 22:01, Adam Williamson wrote:

When you hit edit, it shows the builds in the update already, and there
*should*  be a button to remove each, but indeed I don't see it on that
update. Not sure why not.


https://github.com/fedora-infra/bodhi/issues/4122

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What is the status of this F33 update?

[Miro Hrončok]

On 11. 09. 20 21:57, Richard W.M. Jones wrote:

I built libnbd against the side tag (libnbd-1.4.1-1.fc33.1) but can't
work out how to add it to the update.  There seems to be no way to
edit the list of packages AFAICT.


That is https://github.com/fedora-infra/bodhi/issues/4122

Using the CLI worked for me.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1802607] perl-Net-DNS-1.27 is available

[bugzilla]

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



--- Comment #15 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-DNS-1.27-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=51245495


-- 
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: What is the status of this F33 update?

[Adam Williamson]

On Fri, 2020-09-11 at 20:57 +0100, Richard W.M. Jones wrote:
> On Fri, Sep 11, 2020 at 09:41:09PM +0200, Fabio Valentini wrote:
> > On Fri, Sep 11, 2020 at 9:38 PM Richard W.M. Jones  
> > wrote:
> > > 
> > > 
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65
> > > 
> > > I'm confused about what state this update it is.  "Pending" - pending
> > > what exactly?  What we really want to know is how long before it ends
> > > up in F33 and Jerry can build more OCaml packages against it.
> > > 
> > > Rich.
> > 
> > It's "pending" - updates created from side tags need to be pushed to
> > testing manually by pushing the "Push to testing" action button.
> > I just tried to do that, but it fails with this error message:
> > 
> > Cannot submit libnbd ('0', '1.4.0', '2.fc33.1') to testing since it is
> > older than ('0', '1.4.1', '1.fc33')
> > 
> > Looks like this package was updated outside the side tag.
> > 
> > I think you'll need to rebuild that package in your side tag and
> > re-edit the update, then you should be able to push it to testing.
> 
> I built libnbd against the side tag (libnbd-1.4.1-1.fc33.1) but can't
> work out how to add it to the update.  There seems to be no way to
> edit the list of packages AFAICT.

When you hit edit, it shows the builds in the update already, and there
*should* be a button to remove each, but indeed I don't see it on that
update. Not sure why not. Might be to do with it having 166 builds. You
may be able to do it with the CLI client.
-- 
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: What is the status of this F33 update?

[Richard W.M. Jones]

On Fri, Sep 11, 2020 at 08:57:20PM +0100, Richard W.M. Jones wrote:
> On Fri, Sep 11, 2020 at 09:41:09PM +0200, Fabio Valentini wrote:
> > On Fri, Sep 11, 2020 at 9:38 PM Richard W.M. Jones  
> > wrote:
> > >
> > >
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65
> > >
> > > I'm confused about what state this update it is.  "Pending" - pending
> > > what exactly?  What we really want to know is how long before it ends
> > > up in F33 and Jerry can build more OCaml packages against it.
> > >
> > > Rich.
> > 
> > It's "pending" - updates created from side tags need to be pushed to
> > testing manually by pushing the "Push to testing" action button.
> > I just tried to do that, but it fails with this error message:
> > 
> > Cannot submit libnbd ('0', '1.4.0', '2.fc33.1') to testing since it is
> > older than ('0', '1.4.1', '1.fc33')
> > 
> > Looks like this package was updated outside the side tag.
> > 
> > I think you'll need to rebuild that package in your side tag and
> > re-edit the update, then you should be able to push it to testing.
> 
> I built libnbd against the side tag (libnbd-1.4.1-1.fc33.1) but can't
> work out how to add it to the update.  There seems to be no way to
> edit the list of packages AFAICT.

And creating a new update fails with:

From_tag : Update already exists using this side tag

Delete the old update?  I really don't want to lose these builds since
they took a day or more to complete.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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 1802607] perl-Net-DNS-1.27 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Net-DNS-1.26 is|perl-Net-DNS-1.27 is
   |available   |available



--- Comment #13 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.27
Current version/release in rawhide: 1.21-5.fc33
URL: http://search.cpan.org/dist/Net-DNS/

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

--- Comment #14 from Upstream Release Monitoring 
 ---
Created attachment 1714601
  --> https://bugzilla.redhat.com/attachment.cgi?id=1714601=edit
[patch] Update to 1.27 (#1802607)


-- 
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: What is the status of this F33 update?

[Richard W.M. Jones]

On Fri, Sep 11, 2020 at 09:41:09PM +0200, Fabio Valentini wrote:
> On Fri, Sep 11, 2020 at 9:38 PM Richard W.M. Jones  wrote:
> >
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65
> >
> > I'm confused about what state this update it is.  "Pending" - pending
> > what exactly?  What we really want to know is how long before it ends
> > up in F33 and Jerry can build more OCaml packages against it.
> >
> > Rich.
> 
> It's "pending" - updates created from side tags need to be pushed to
> testing manually by pushing the "Push to testing" action button.
> I just tried to do that, but it fails with this error message:
> 
> Cannot submit libnbd ('0', '1.4.0', '2.fc33.1') to testing since it is
> older than ('0', '1.4.1', '1.fc33')
> 
> Looks like this package was updated outside the side tag.
> 
> I think you'll need to rebuild that package in your side tag and
> re-edit the update, then you should be able to push it to testing.

I built libnbd against the side tag (libnbd-1.4.1-1.fc33.1) but can't
work out how to add it to the update.  There seems to be no way to
edit the list of packages AFAICT.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 blocker status

[Ben Cotton]

Fedora 33 Beta was no-go by default due to outstanding blockers. Let's
try again this week!

Action summary


Accepted blockers
-
1. libreport — abrt-server errors when processing zstd compressed core
dumps produced by systemd-246~rc1-1.fc33 — ON_QA
ACTION: testers needed to see if BZ 1873029 is reproducible

2. dbus-broker — login stuck when changing users repeatedly (log out,
log in a different one) — NEW
ACTION: Someone (anyone!) figure out what causes this behavior.

3. distribution — Everything boot x86_64 image exceeds maximum size — ASSIGNED
ACTION: none. Fixing Server boot should fix this, too

4. distribution — Server boot x86_64 image exceeds maximum size — NEW
ACTION: Server WG to determine whether or not to remove packages or
increase size limit.

5.  libpreport — bugs can't be reported: "No matching actions found
for this event" — NEW
ACTION: abrt maintainers to diagnose and fix issue

6. anaconda — Booting Server DVD then selecting a mirrorlist
repository does not work — VERIFIED
ACTION: None!

7. systemd — resolv.conf misconfigured on fresh install — ASSIGNED
ACTION: systemd maintainers to add a removal of existing
/etc/resolv.conf when not an upgrade


Bug-by-bug detail
=

Accepted blockers
-
1. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1860616 — ON_QA
abrt-server errors when processing zstd compressed core dumps produced
by systemd-246~rc1-1.fc33

FEDORA-2020-59e144acee contains a potential fix, but appears to
introduce a new blocker (BZ 1873029). It may be moot until the retrace
server is brought back online. The infra team has provisioned a basic
instance, which msuchy is working to get ready for use.

2. dbus-broker — https://bugzilla.redhat.com/show_bug.cgi?id=1861700 — NEW
login stuck when changing users repeatedly (log out, log in a different one)

User processes linger after logout which blocks logging in when
another user has logged in between the two sessions. Or when the
second user logs back in. Or when a single user logs in repeatedly.
Using KillUserProcesses=Yes helps the first problem, but raises on of
its own. It appears to be a race condition of some kind as the
behavior is not fully consistent. Nobody really knows what the problem
is.

3. distribtution — https://bugzilla.redhat.com/show_bug.cgi?id=1849430
— ASSIGNED
Everything boot x86_64 image exceeds maximum size

Latest compose does not significantly shrink the image size. Given the
similar nature of the overages, I believe fixing the Server image
size, which sgallagh is working on, will fix this as well.

4. distribtution — https://bugzilla.redhat.com/show_bug.cgi?id=1849431
— ASSIGNED
Server boot x86_64 image exceeds maximum size

We need to slim it down by ~14 MB.

5. libreport — https://bugzilla.redhat.com/show_bug.cgi?id=1873029 — NEW
bugs can't be reported: "No matching actions found for this event"

No crashes can be reported. abrt shows "no matching event" error
message. This appears to be introduced by the fix for 1860616.

6. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=1872056 — VERIFIED
Booting Server DVD then selecting a mirrorlist repository does not work

The Server DVD openQA installation tests fail when using a mirrorlist
URL. They do not fail with a direct repository URL.
FEDORA-2020-daac40f3d3 fixes this.

7. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=1873856 — ASSIGNED
resolv.conf misconfigured on fresh install

/etc/resolv.conf is a file, not a symlink, which causes DNS problems
in some cases. FEDORA-2020-2255b438a2 fixed it in Worskation, but the
behavior apparently still exists in the netinstall. Removing the
existing file created by NetworkManager when not an upgrade should fix
this.



-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
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: Proposing an EPEL packaging SIG

[Neal Gompa]

On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > * Have an expedited flow where this SIG can request EPEL branches and
> > admin access to packages if there are no response from package
> > maintainers for a set period (3 days? 1 week?)
> >   * whether it should be full admin access or whether such access
> > should be scoped to epel* branches can be discussed. Full admin would
> > make it possible to adjust the spec in Rawhide to be more EPEL
> > friendly, for example
>
> Unless I've missed something, we still don't have per-branch ACLs in
> dist-git.
>
> I don't think it's okay to force maintainers to give you admin or commit
> to their packages just because you want them in EPEL.
>
> (I'm also not one of the kind of people who really like having one spec
> file for all versions of the package, but I know others disagree with me
> on this.  Certainly if hypothetically I didn't want to maintain an EPEL
> package I wouldn't want its logic /also/ foisted on me in rawhide.)
>

We have per-branch ACLs in Dist-Git since early August. The
collaborator role in Pagure lets you grant people commit access for
specific branches.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Proposing an EPEL packaging SIG

[Neal Gompa]

On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > * Have an expedited flow where this SIG can request EPEL branches and
> > admin access to packages if there are no response from package
> > maintainers for a set period (3 days? 1 week?)
> >   * whether it should be full admin access or whether such access
> > should be scoped to epel* branches can be discussed. Full admin would
> > make it possible to adjust the spec in Rawhide to be more EPEL
> > friendly, for example
>
> Unless I've missed something, we still don't have per-branch ACLs in
> dist-git.
>
> I don't think it's okay to force maintainers to give you admin or commit
> to their packages just because you want them in EPEL.
>
> (I'm also not one of the kind of people who really like having one spec
> file for all versions of the package, but I know others disagree with me
> on this.  Certainly if hypothetically I didn't want to maintain an EPEL
> package I wouldn't want its logic /also/ foisted on me in rawhide.)
>

We have per-branch ACLs in Dist-Git since early August. The
collaborator role in Pagure lets you grant people commit access for
specific branches.



-- 
真実はいつも一つ！/ 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: What is the status of this F33 update?

[Adam Williamson]

On Fri, 2020-09-11 at 20:37 +0100, Richard W.M. Jones wrote:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65
> 
> I'm confused about what state this update it is.  "Pending" - pending
> what exactly?  What we really want to know is how long before it ends
> up in F33 and Jerry can build more OCaml packages against it.

It's not exactly pending anything *in particular*. It's just...pending.
:) It has not been submitted to testing, so it's just sort of...there.
The update exists but as things stand the package will never actually
go to the testing repo.

It may have been created during a period when there was, IIRC, a bug in
Bodhi or something which meant newly-created updates weren't
automatically submitted to testing as they usually are. You can submit
it to testing manually by clicking 'Actions' at top right.

It will not get to F33 stable now until after Beta release, because
we're in Beta freeze. If you want to do rebuilds against it you can
submit a buildroot override, but of course be careful with unintended
consequences of that. Any rebuilds done should, I guess, be added to
the update itself, too.
-- 
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: What is the status of this F33 update?

[Kalev Lember]

On Fri, Sep 11, 2020 at 9:38 PM Richard W.M. Jones 
wrote:

>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65
>
> I'm confused about what state this update it is.  "Pending" - pending
> what exactly?  What we really want to know is how long before it ends
> up in F33 and Jerry can build more OCaml packages against it.
>

Try clicking on Actions -> Push to Testing which should queue it to be
pushed to testing in the next updates-testing push. I believe it's a Bodhi
bug that this doesn't happen automatically for side-tag updates.

Hope this helps,
Kalev
___
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: Proposing an EPEL packaging SIG

[Troy Dawson]

On Fri, Sep 11, 2020 at 12:10 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > * Have an expedited flow where this SIG can request EPEL branches and
> > admin access to packages if there are no response from package
> > maintainers for a set period (3 days? 1 week?)
> >   * whether it should be full admin access or whether such access
> > should be scoped to epel* branches can be discussed. Full admin would
> > make it possible to adjust the spec in Rawhide to be more EPEL
> > friendly, for example
>
> Unless I've missed something, we still don't have per-branch ACLs in
> dist-git.
>
> I don't think it's okay to force maintainers to give you admin or commit
> to their packages just because you want them in EPEL.
>
> (I'm also not one of the kind of people who really like having one spec
> file for all versions of the package, but I know others disagree with me
> on this.  Certainly if hypothetically I didn't want to maintain an EPEL
> package I wouldn't want its logic /also/ foisted on me in rawhide.)
>

This does sound a bit over-the-top as far as permissions go.
As Robbie said, some people/groups don't like having all sorts of
conditions in their spec files.  Having a SIG being able to put in,
and change, %if statements in Rawhide spec files whenever they want is
not a good situation.  If they want to open pull requests, for those
changes, fine.  But giving them permissions to put them in with no
oversite, I don't like.
Do we have any idea on the timeframe of having per-branch ACLs in dist-git?

Troy
___
epel-devel mailing list -- epel-de...@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-de...@lists.fedoraproject.org

Re: What is the status of this F33 update?

[Fabio Valentini]

On Fri, Sep 11, 2020 at 9:38 PM Richard W.M. Jones  wrote:
>
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65
>
> I'm confused about what state this update it is.  "Pending" - pending
> what exactly?  What we really want to know is how long before it ends
> up in F33 and Jerry can build more OCaml packages against it.
>
> Rich.

It's "pending" - updates created from side tags need to be pushed to
testing manually by pushing the "Push to testing" action button.
I just tried to do that, but it fails with this error message:

Cannot submit libnbd ('0', '1.4.0', '2.fc33.1') to testing since it is
older than ('0', '1.4.1', '1.fc33')

Looks like this package was updated outside the side tag.

I think you'll need to rebuild that package in your side tag and
re-edit the update, then you should be able to push it to testing.

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

What is the status of this F33 update?

[Richard W.M. Jones]

https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65

I'm confused about what state this update it is.  "Pending" - pending
what exactly?  What we really want to know is how long before it ends
up in F33 and Jerry can build more OCaml packages against it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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: Proposing an EPEL packaging SIG

[Robbie Harwood]

Michel Alexandre Salim  writes:

> * Have an expedited flow where this SIG can request EPEL branches and
> admin access to packages if there are no response from package
> maintainers for a set period (3 days? 1 week?)
>   * whether it should be full admin access or whether such access
> should be scoped to epel* branches can be discussed. Full admin would
> make it possible to adjust the spec in Rawhide to be more EPEL
> friendly, for example

Unless I've missed something, we still don't have per-branch ACLs in
dist-git.

I don't think it's okay to force maintainers to give you admin or commit
to their packages just because you want them in EPEL.

(I'm also not one of the kind of people who really like having one spec
file for all versions of the package, but I know others disagree with me
on this.  Certainly if hypothetically I didn't want to maintain an EPEL
package I wouldn't want its logic /also/ foisted on me in rawhide.)

Thanks,
--Robbie


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

Proposing an EPEL packaging SIG

[Michel Alexandre Salim]

Hello all,

Following up from last week's EPEL Steering Committee meeting, I'm
presenting a proposal to create a dedicated SIG to make it easier to
get Fedora packages into EPEL and keep them maintained.

Using the Fedora Changes Process template for this to help structure
the proposal, though this is not really a Fedora Change.

== Summary ==

Have a dedicated SIG for packagers who are interested in making more
Fedora packages available for EPEL releases.

== Owner ==
* Name: [[User:salimma|Michel Salim]]
* Email: 

== Detailed Description ==

RHEL/CentOS releases are branched off from Fedora; since RHEL 8 this
happens every 3 years. Only a subset of Fedora packages get shipped as
part of RHEL, as Red Hat provides support on these packages for their
paying customers; EPEL (Extra Packages for Enterprise Linux) fills in
the gap; this is similar to the old split between Fedora Core and
Extras.

EPEL packages are maintained in dist-git as additional branches on
Fedora packages; however, unlike with Fedora releases, where by default
a package gets branched for any new Fedora release, EPEL branches are
only created if one of the package maintainers request it (it's opt-
in).

The rationale is that many Fedora packagers do not specifically care
about EL, and with their long release cycles the maintenance burden is
higher (e.g. upgrading to fix a security vulnerability might not be
possible if the newer fixed version has unmet dependencies, so
backporting the fix might be required). EL is more often used server
side too, so the average Fedora packager is not expected to be an EL
user.

This poses a problem for those of us who rely on packages in EPEL --
e.g. Fedora Infrastructure, and many corporate deployments. Right now
the process is as such:

* An org starts rolling out the new version of EL
* It turns out a given package is not available in EPEL
* Bug filed requesting that package be branched and built
* Worst case scenario, no response and we need to use the non-
responsive maintainer flow
* That package might have other unmet dependencies, so repeat this
cycle several times
* Wait for each of these packages to go through the update system
* For organizations that have their own internal mirrors, they now need
to sync the new packages

There are several changes we can make to both streamline the process,
and not increase the maintenance burden on the (other) maintainers of
these packages:

* Have an EPEL SIG modeled after the SIGs centered around programming
language stacks (e.g. Python, Haskell, Java)
* Have an expedited flow where this SIG can request EPEL branches and
admin access to packages if there are no response from package
maintainers for a set period (3 days? 1 week?)
  * whether it should be full admin access or whether such access
should be scoped to epel* branches can be discussed. Full admin would
make it possible to adjust the spec in Rawhide to be more EPEL
friendly, for example
* Members of the EPEL SIG can then branch these packages early when the
next EL release is branched
* The member of the SIG doing the branching should be designated as the
primary EPEL assignee for that package

One deviation we might want to have from how Python SIG works is... we
probably don't want to encourage packagers to add this EPEL SIG as a
comaintainer preemptively, but only as needed.

== Benefit to Fedora ==
=== Smoother infra upgrades ===
Upgrading the Fedora infrastructure will get easier over time, as more
of the necessary EPEL packages become co-maintained by the EPEL SIG,
which reduces the amount of time needed to get these packages available
on new releases.

=== Packager experience ===
Reduced burden on Fedora package maintainers who are not interested in
EPEL - the choice is now either:
* One of the existing maintainers does the work of branching and
building
* The requestee gets added as a maintainer and does it
* The request stalls because the requestee is not a packager

=== More involvement by CentOS-using organizations ===
With the EPEL SIG, we should encourage organizations with a long-term
need for EPEL to get their members / employees added to this SIG, so
scenarios #2 and #3 basically becomes this:

* EPEL SIG gets added as co-maintainer of this package

This might encourage more contributions from companies that
traditionally just consume RHEL/CentOS + EPEL, and as RHEL/CentOS is
increasingly developed in the open with CentOS-Stream, eventually also
make it easier to get these companies' input into the EL development
process.

== Scope ==

* Proposal Owners
  * Ask Infra to set up EPEL SIG ACL and mailing list (for Bugzilla)
  * Announce this in epel-devel
  * Have documentation for the SIG as part of the EPEL documentation
  * Help onboard people to this SIG

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


signature.asc
Description: This is a digitally 

[EPEL-devel] Proposing an EPEL packaging SIG

[Michel Alexandre Salim]

Hello all,

Following up from last week's EPEL Steering Committee meeting, I'm
presenting a proposal to create a dedicated SIG to make it easier to
get Fedora packages into EPEL and keep them maintained.

Using the Fedora Changes Process template for this to help structure
the proposal, though this is not really a Fedora Change.

== Summary ==

Have a dedicated SIG for packagers who are interested in making more
Fedora packages available for EPEL releases.

== Owner ==
* Name: [[User:salimma|Michel Salim]]
* Email: 

== Detailed Description ==

RHEL/CentOS releases are branched off from Fedora; since RHEL 8 this
happens every 3 years. Only a subset of Fedora packages get shipped as
part of RHEL, as Red Hat provides support on these packages for their
paying customers; EPEL (Extra Packages for Enterprise Linux) fills in
the gap; this is similar to the old split between Fedora Core and
Extras.

EPEL packages are maintained in dist-git as additional branches on
Fedora packages; however, unlike with Fedora releases, where by default
a package gets branched for any new Fedora release, EPEL branches are
only created if one of the package maintainers request it (it's opt-
in).

The rationale is that many Fedora packagers do not specifically care
about EL, and with their long release cycles the maintenance burden is
higher (e.g. upgrading to fix a security vulnerability might not be
possible if the newer fixed version has unmet dependencies, so
backporting the fix might be required). EL is more often used server
side too, so the average Fedora packager is not expected to be an EL
user.

This poses a problem for those of us who rely on packages in EPEL --
e.g. Fedora Infrastructure, and many corporate deployments. Right now
the process is as such:

* An org starts rolling out the new version of EL
* It turns out a given package is not available in EPEL
* Bug filed requesting that package be branched and built
* Worst case scenario, no response and we need to use the non-
responsive maintainer flow
* That package might have other unmet dependencies, so repeat this
cycle several times
* Wait for each of these packages to go through the update system
* For organizations that have their own internal mirrors, they now need
to sync the new packages

There are several changes we can make to both streamline the process,
and not increase the maintenance burden on the (other) maintainers of
these packages:

* Have an EPEL SIG modeled after the SIGs centered around programming
language stacks (e.g. Python, Haskell, Java)
* Have an expedited flow where this SIG can request EPEL branches and
admin access to packages if there are no response from package
maintainers for a set period (3 days? 1 week?)
  * whether it should be full admin access or whether such access
should be scoped to epel* branches can be discussed. Full admin would
make it possible to adjust the spec in Rawhide to be more EPEL
friendly, for example
* Members of the EPEL SIG can then branch these packages early when the
next EL release is branched
* The member of the SIG doing the branching should be designated as the
primary EPEL assignee for that package

One deviation we might want to have from how Python SIG works is... we
probably don't want to encourage packagers to add this EPEL SIG as a
comaintainer preemptively, but only as needed.

== Benefit to Fedora ==
=== Smoother infra upgrades ===
Upgrading the Fedora infrastructure will get easier over time, as more
of the necessary EPEL packages become co-maintained by the EPEL SIG,
which reduces the amount of time needed to get these packages available
on new releases.

=== Packager experience ===
Reduced burden on Fedora package maintainers who are not interested in
EPEL - the choice is now either:
* One of the existing maintainers does the work of branching and
building
* The requestee gets added as a maintainer and does it
* The request stalls because the requestee is not a packager

=== More involvement by CentOS-using organizations ===
With the EPEL SIG, we should encourage organizations with a long-term
need for EPEL to get their members / employees added to this SIG, so
scenarios #2 and #3 basically becomes this:

* EPEL SIG gets added as co-maintainer of this package

This might encourage more contributions from companies that
traditionally just consume RHEL/CentOS + EPEL, and as RHEL/CentOS is
increasingly developed in the open with CentOS-Stream, eventually also
make it easier to get these companies' input into the EL development
process.

== Scope ==

* Proposal Owners
  * Ask Infra to set up EPEL SIG ACL and mailing list (for Bugzilla)
  * Announce this in epel-devel
  * Have documentation for the SIG as part of the EPEL documentation
  * Help onboard people to this SIG

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


signature.asc
Description: This is a digitally 

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Adam Williamson]

On Fri, 2020-09-11 at 12:44 +0300, Aleksandar Kurtakov wrote:
> On Fri, Sep 11, 2020 at 11:54 AM Tomasz Torcz  wrote:
> 
> > On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> > > You get a side tag in Koji where you can have private build-only
> > > dependencies that are discarded (filtered) once they are no longer
> > > needed, after module build is done. For build-only packages most of
> > > security vulnerabilities are not exploitable easily, or at all,
> > > therefore are low-severity, which greatly limits maintenance work
> > > required to address them. For example, if upstream tests are ran on an
> > > obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> > > but I can package old Tomcat and run the tests.
> > 
> >   Whoha! Let's step back for a minute and look at this example.
> > What are the reasons to run tests?  To make sure the package will run
> > correctly..
> > Why run tests on 12-years old version instead of on current one?
> > Probably because tests fail on current version?
> > 
> >   Will the end user run the package on obsolete Tomcat or on the current
> > one?
> > Of course on the current one. The one on which tests fail.
> > Tests in this case are worthless, they are not testing the real
> > situation. Disabling tests is no worse than testing on obsolete version.
> > Relying on such tests is a disservice for the end user.
> > 
> >   The point of testing is to validate code in real situation.
> > Crafting special, unrealistic environment (12 years old Tomcat) just to
> > have
> > test pass is missing the point of tests.
> > 
> 
> Well, you do realize how much not feasible it is for the Fedora maintainer
> of hundred packages to go out and not only fix the builds, bugs, CVEs and
> etc. but even the tests for all these packages. The unrealistic
> expectations for what package maintainer should do is really not helping
> growing that number.

I've been struggling with how to make this point without sounding
cynical, but hey, let's just lay it out there:

If one of the issues here can be stated as "we want buildroot-only
packages because we don't want to maintain those packages to a high
standard", it is demonstrably a viable choice within Fedora to just
*not maintain those packages to a high standard*. Maybe we wish it
wasn't the case, but this is a thing that happens all the time. We have
lots of packages that are, by any reasonable standard, rather badly
maintained. It would be lovely if all Fedora packages had all their
bugs aggressively addressed and had great test suites and had CVE
issues jumped on immediately. But, well, the evidence suggests quite
strongly that this is not the case. For e.g., I did a very sloppy
search yesterday for Fedora bugs with "CVE" in the topic which were
opened before June 2 and are still open:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=__open__=%5BBug%20creation%5D=2020-06-01=Fedora_id=11345766_format=advanced_desc=CVE_desc_type=allwordssubstr

it is capped at 1000 results. Which, you know, doesn't *scream* that
all our packages are being diligently maintained from a CVE point of
view, which implies at least some of them aren't being diligently
maintained from any point of view. Even if some or many of those CVEs
happen to have been fixed by version updates and it's just that the
bugs weren't closed - the very fact that the bugs aren't being handled
is a maintenance issue.

So here is my cynical point: if you want to have poorly-maintained
packages, isn't it still better that they be poorly-maintained distro
packages where at least everyone understands how the process works and
proven packagers can fix stuff up if they are inclined to, than that
they be hidden buildroot-only poorly maintained packages?
-- 
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 Future of the Java Stack (also regarding ELN and RHEL)

[Alexander Scheel]

What Fabio just mentioned was that the current use case for a
build-time only package is invalid. A lot of packages Mikolaj is
trying to get build-time only (via modules) are still maintained by
the Java Maintenance SIG because they're required by other packages.

Allowing them to be build-time only results in the entire ecosystem
crumbling. If they're retired, the ecosystem crumbles too. Same result
either way.


That's why the Java Maintenance SIG was built: so that it can be more
than one person working on these packages.


- Alex

On Fri, Sep 11, 2020 at 12:44 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Sep 11, 2020 at 06:01:11PM +0200, Fabio Valentini wrote:
> > On Fri, Sep 11, 2020 at 5:52 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Fri, Sep 11, 2020 at 11:03:39AM +0200, Hans de Goede wrote:
> > > > An other more generic approach which has been brought up once or
> > > > twice, but which not really has been discussed in much detail yet
> > > > I believe is creating a fedora-builddep repository.
> > > >
> > > > ATM a normal user has 3 ursine Fedora repos installed:
> > > >
> > > > fedora
> > > > fedora-updates
> > > > fedora-updates-testing (disabled by default)
> > > >
> > > > What if we add a 4th repo called fedora-builddep:
> > > >
> > > > fedora
> > > > fedora-updates
> > > > fedora-updates-testing (disabled by default)
> > > > fedora-builddep (rolling (within a release), disabled by default)
> > > >
> > > > So the idea is that all the maven deps which you need, but
> > > > do not want to offer any end-user support on would go to
> > > > fedora-builddep.
> > >
> > > If we absolutely must have build-only packages, we can do it more simply:
> > > insert
> > >   Requires: fedora-unmaintained-package
> > > or
> > >   Requires: fedora-buildonly-package
> > > (name TBD), and beef up dnf a bit to explain that "this package cannot
> > > be installed because it's only maintained at the level appropriate for
> > > building packages...". I think there are two advantages: first, no need
> > > for a separate repo, so there'll be less infra change and churn. Second,
> > > this tag can easily set on each subrpm, without any central list to 
> > > manage.
> >
> > I'm not sure making things available only at build-time is going to
> > help things. It's just "Modularity under a different name" ...
> > Most Java packages are either directly or indirectly depended on by
> > non-build-tool packages as well.
> > You'd be surprised. Most of the distro directly or indirectly depends
> > on the Java stack already - including the libvirt stack, libreoffice,
> > some GNOME components, KDE components, etc. So most of those Java
> > packages can't be built-time-only packages because they're actually
> > required at runtime.
> > The number of packages that are *really only ever needed to build
> > other RPM packages and for no other reasons* is rather small.
>
> You are probably right. Still, this would be useful to actually have this
> surfaced. If a package marked build-time-only would be needed by anything
> else, we would need to either unmark it (and have somebody on the hook
> for maintaince) or drop the dependency somehow. And this would be vastly
> better than build-time-only packages in modules.
>
> I'm not enthusiastic about build-time-only packages, but if the choice
> is between that and retiring the packages (or hiding them in modules
> which has the same effect), I'll take it.
>
> Zbyszek
> ___
> 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: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Michael Catanzaro]

On Fri, Sep 11, 2020 at 10:21 am, Kamil Paral  wrote:
I did edit /etc/nsswitch.conf manually, because obviously I needed a 
working system :) The confusing part here is that the error message 
claims that **/etc/authselect/nsswitch.conf** has unexpected content. 
So this doesn't seem to be related to /etc/nsswitch.conf having been 
edited by hand. Is it?


I think it's probably related. It's unexpected for it to not match your 
/etc/nsswitch.conf.


If it is, what is the proper way to revert back to upstream defaults 
in this case? Should I append "--force" to the command? (I don't want 
to destroy my system, that's why I'm not simply trying it. All of 
this seems awfully complex and fragile).


Yes, use --force. That tells authselect that it is OK to overwrite your 
manual configuration. Otherwise, authselect is careful to not overwrite 
files that have been edited manually.


___
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 Future of the Java Stack (also regarding ELN and RHEL)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 11, 2020 at 06:01:11PM +0200, Fabio Valentini wrote:
> On Fri, Sep 11, 2020 at 5:52 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Sep 11, 2020 at 11:03:39AM +0200, Hans de Goede wrote:
> > > An other more generic approach which has been brought up once or
> > > twice, but which not really has been discussed in much detail yet
> > > I believe is creating a fedora-builddep repository.
> > >
> > > ATM a normal user has 3 ursine Fedora repos installed:
> > >
> > > fedora
> > > fedora-updates
> > > fedora-updates-testing (disabled by default)
> > >
> > > What if we add a 4th repo called fedora-builddep:
> > >
> > > fedora
> > > fedora-updates
> > > fedora-updates-testing (disabled by default)
> > > fedora-builddep (rolling (within a release), disabled by default)
> > >
> > > So the idea is that all the maven deps which you need, but
> > > do not want to offer any end-user support on would go to
> > > fedora-builddep.
> >
> > If we absolutely must have build-only packages, we can do it more simply:
> > insert
> >   Requires: fedora-unmaintained-package
> > or
> >   Requires: fedora-buildonly-package
> > (name TBD), and beef up dnf a bit to explain that "this package cannot
> > be installed because it's only maintained at the level appropriate for
> > building packages...". I think there are two advantages: first, no need
> > for a separate repo, so there'll be less infra change and churn. Second,
> > this tag can easily set on each subrpm, without any central list to manage.
> 
> I'm not sure making things available only at build-time is going to
> help things. It's just "Modularity under a different name" ...
> Most Java packages are either directly or indirectly depended on by
> non-build-tool packages as well.
> You'd be surprised. Most of the distro directly or indirectly depends
> on the Java stack already - including the libvirt stack, libreoffice,
> some GNOME components, KDE components, etc. So most of those Java
> packages can't be built-time-only packages because they're actually
> required at runtime.
> The number of packages that are *really only ever needed to build
> other RPM packages and for no other reasons* is rather small.

You are probably right. Still, this would be useful to actually have this
surfaced. If a package marked build-time-only would be needed by anything
else, we would need to either unmark it (and have somebody on the hook
for maintaince) or drop the dependency somehow. And this would be vastly
better than build-time-only packages in modules.

I'm not enthusiastic about build-time-only packages, but if the choice
is between that and retiring the packages (or hiding them in modules
which has the same effect), I'll take it.

Zbyszek
___
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 Future of the Java Stack (also regarding ELN and RHEL)

[Fabio Valentini]

On Fri, Sep 11, 2020 at 1:06 PM Hans de Goede  wrote:
>
> Hi,
>
> On 9/11/20 12:47 PM, Vít Ondruch wrote:
> >
> > Dne 11. 09. 20 v 11:03 Hans de Goede napsal(a):
> >>
> >>
> >> On 9/11/20 10:16 AM, Mikolaj Izdebski wrote:
> >>
> >>> Another, more concrete example: core Ant doesn't have any dependencies
> >>> beyond JDK. It is easy to build and maintain, yet very functional. On
> >>> the other hand, full Ant with all the optional tasks depends on more
> >>> than 200 Java packages. For the purpose of building all packages that
> >>> I am interested in, core Ant with JUnit tasks (total of 3 packages) is
> >>> sufficient. Functionalities of Ant like sending emails or image
> >>> processing are obviously not needed in this case. If building other
> >>> packages is the only use of Ant then it can be maintained much more
> >>> easily (3 instead of ~250 packages). But when Ant is ursine package in
> >>> Fedora then it should be the full Ant - we can't claim to deliver Ant
> >>> to users while it is just part of it. Eclipse in Fedora requires full
> >>> Ant too.
> >>
> >> So if you say that you only need the minimal Ant, and I guess many
> >> packages only need the minimal Ant to build, then why not have
> >> an ant-minimal package, like we have a vim-minimal ?
> >>
> >> Now I guess that vim-minimal and "proper" vim are both build from the
> >> same source-rpm; and normally we never allow 2 srpms with the same
> >> upstream sources in them. But I think that in this case we could make
> >> an exemption where there is a separate pkg-git and srpm for an
> >> ant-minimal
> >> which you would maintain.
> >>
> >> And then the community / java-sig can maintain the full Ant as I believe
> >> is already happening since we do have an ant packaged in Fedora 33 atm.
> >
> >
> > How this reduce the workload?
>
> It doesn't the purpose of my email was to look for ways to get
> the modular ant/maven repos work moved back into ursine without
> increasing the workload for the maintainers of those modular
> repos.
>
> So the way to look at this, is does it increase workload,
> and AFAICT it does not increase workload, while it would allow
> us to fold the work being done in the modular repos back
> into the ursine repo (for the ant example at least).
>
> Alternatively if we fold that work back into the ursine repos,
> then the modular builds could start relying on the full-blown
> ant build maintained by the java-SIG in the ursine repos and
> drop their own ant-minimal, at which point it would reduce the
> workload for the maintainers of the modular repos.
>
> My idea behind having a separate ant-minimal is that they
> then can ensure that that is new enough and otherwise matches
> their needs without relying on the full-blown version, but
> actually somply switching to the full-blown java-SIG maintained
> version might be better.
>
> Regards,
>
> Hans

(snip)

> p.s.
>
> I would not mind picking up maintenance of 1 or 2 of the
> less frequently changing java packages (*) if that helps.
> I wonder how much more people there are like me who care
> enough about java to be willing to put some work in
> (but not lots of work) ?
>
> Perhaps it would be a good idea for the java-SIG to make
> a list of easy to maintain (for an experienced packager)
> pkgs which could use a new primary maintainer. I realize
> maintaining the entire stack is a team effort, so the rest of
> the java-SIG will of course be/stay a co-maintainer of these.
> But having things like rebasing to latest upstream, or just
> addressing bugzillas taken care of mostly by a new
> primary maintainer who is willing to pick up some packages
> might help reduce the load ?
>
> The idea here is for someone (e.g.) me to NOT jump in now,
> do a bunch of work to help out and then disappear again.
> Instead I would invest say 1-2 hours every 2 weeks, which
> may not seem much but over time adds up and if we can
> get more people to do this, then maybe we can spread the
> load of the java packages in the ursine repos better ?

That would be great, any help is appreciated.
I can try to come up with a list of often-used-but-simple-to-maintain
Java packages?

Side note: I just checked, and the *whole* Java stack that was
previously maintained by the Stewardship SIG and was now moved into a
dedicated Java SIG group - @java-maint-sig -  has only 2 (in words:
TWO) open CVE bugs associated with it. One was filed against log4j12
(which we're actively trying to get rid of), and the other was filed
against resteasy, where a fix is blocked by getting the package
updated to a newer version (with lots of new dependencies). So I have
no idea where that "big burden of fixing CVE issues" is for Java
packages actually is ...

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

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Fabio Valentini]

On Fri, Sep 11, 2020 at 5:52 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Sep 11, 2020 at 11:03:39AM +0200, Hans de Goede wrote:
> > An other more generic approach which has been brought up once or
> > twice, but which not really has been discussed in much detail yet
> > I believe is creating a fedora-builddep repository.
> >
> > ATM a normal user has 3 ursine Fedora repos installed:
> >
> > fedora
> > fedora-updates
> > fedora-updates-testing (disabled by default)
> >
> > What if we add a 4th repo called fedora-builddep:
> >
> > fedora
> > fedora-updates
> > fedora-updates-testing (disabled by default)
> > fedora-builddep (rolling (within a release), disabled by default)
> >
> > So the idea is that all the maven deps which you need, but
> > do not want to offer any end-user support on would go to
> > fedora-builddep.
>
> If we absolutely must have build-only packages, we can do it more simply:
> insert
>   Requires: fedora-unmaintained-package
> or
>   Requires: fedora-buildonly-package
> (name TBD), and beef up dnf a bit to explain that "this package cannot
> be installed because it's only maintained at the level appropriate for
> building packages...". I think there are two advantages: first, no need
> for a separate repo, so there'll be less infra change and churn. Second,
> this tag can easily set on each subrpm, without any central list to manage.

I'm not sure making things available only at build-time is going to
help things. It's just "Modularity under a different name" ...
Most Java packages are either directly or indirectly depended on by
non-build-tool packages as well.
You'd be surprised. Most of the distro directly or indirectly depends
on the Java stack already - including the libvirt stack, libreoffice,
some GNOME components, KDE components, etc. So most of those Java
packages can't be built-time-only packages because they're actually
required at runtime.
The number of packages that are *really only ever needed to build
other RPM packages and for no other reasons* is rather small.

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

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 11, 2020 at 11:03:39AM +0200, Hans de Goede wrote:
> An other more generic approach which has been brought up once or
> twice, but which not really has been discussed in much detail yet
> I believe is creating a fedora-builddep repository.
> 
> ATM a normal user has 3 ursine Fedora repos installed:
> 
> fedora
> fedora-updates
> fedora-updates-testing (disabled by default)
> 
> What if we add a 4th repo called fedora-builddep:
> 
> fedora
> fedora-updates
> fedora-updates-testing (disabled by default)
> fedora-builddep (rolling (within a release), disabled by default)
> 
> So the idea is that all the maven deps which you need, but
> do not want to offer any end-user support on would go to
> fedora-builddep.

If we absolutely must have build-only packages, we can do it more simply:
insert
  Requires: fedora-unmaintained-package
or 
  Requires: fedora-buildonly-package
(name TBD), and beef up dnf a bit to explain that "this package cannot
be installed because it's only maintained at the level appropriate for
building packages...". I think there are two advantages: first, no need
for a separate repo, so there'll be less infra change and churn. Second,
this tag can easily set on each subrpm, without any central list to manage.

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

[HEADS UP] Breaking version change: php-email-address-validation

[Artur Frenszek-Iwicki]

The php-email-address-validation package [1] has been built using code fetched 
from the now-defunct Google Code, which dated back to 2009. The package 
received no updates since then. I plan to switch the package to build from a 
forked version of the library [2], which is still maintained (last "proper" 
release in 2017, last git activity in 2019). This would introduce some breaking 
changes to the API.

I checked with "dnf repoquery --whatrequires php-email-address-validation" and 
it seems that the only consumer of this package is dokuwiki [3] - which I 
maintain, and for which the forked version would be preferred.

If anyone has any objections to this, please let me know. We could always leave 
the old package as-is and introduce the forked version as a separate package.

Cheers,
A.FI.

[1] https://src.fedoraproject.org/rpms/php-email-address-validation
[2] https://github.com/aziraphale/email-address-validator
[3] https://src.fedoraproject.org/rpms/dokuwiki
___
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: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Thomas Haller]

On Thu, 2020-09-10 at 10:28 +, Mikhail Gavrilov wrote:
> From here https://bugzilla.redhat.com/show_bug.cgi?id=1863041#c46 I
> have expected what newly-created connection would work properly
> without manually changing ipv4.dns-search to ~. on the specific VPN
> connection.

Hi,


I think you need

   nmcli connection modify "$VPN_PROFILE" +ipv4.dns-search "~."


It doesn't matter whether you newly create a profile. What only matters
are the settings (the content) of the connection profile, as you see it
with `nmcli connection show "$PROFILE"`. Now how you created it.


You have a wrong configuration ("wrong" least with respect to how
NetworkManager currently behaves):

  - with split DNS enabled
  - the VPN has DNS servers configured (either manually or pushed by 
server).
  - a VPN profile that has no search domains (neither manually nor 
pushed by server)
  - the VPN is not configured to route all traffic.

Consequently, that DNS server isn't gonna get used.


There is a possibility that NetworkManager could improve to
automatically add the search domain "~." in such cases. But until that
is happens, you have to adjust your connection profile (or your VPN
server to announce the proper search domain).
https://bugzilla.redhat.com/show_bug.cgi?id=1863041#c49


Without systemd-resolved (without split DNS support), NetworkManager
behaves differently because it configures all DNS servers in
/etc/resolv.conf -- regardless of the search domains. That's why
switching to systemd-resolved breaks your previously working setup. In
the end, the behavior is different whether split-DNS or not is enabled,
so this might just be expected, albeit it's very unfortunate to break
previously working setups.



best,
Thomas


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

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[David Cantrell]

On Thu, Sep 10, 2020 at 06:30:05PM +0100, Daniel P. Berrangé wrote:

On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:

On Thu, Sep 10, 2020 at 02:35:13PM +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
>
> > 4.  The benefit we want to preserve from modules is to maintain packages
> > with varying expectation of quality, specifically separating the
> > build-time-only vs runtime dependencies.  e.g. in that case that a web
> > server like Eclipse Jetty is required as a dep for testing another
> > component during the build, we want to be able to use and build that
> > component, without being indefinitely on the hook for security errata. 
> > (The build dependency tree is particularly complex for Maven and
> > involves many examples of packages with frequent and high severity
> > vulnerabilies)
>
> What are you doing different in terms of supporting deps in the module
> that reduces the security errata burden, compared to non-modular builds ?
>
> It feels like if we have some policy that is creating unsustainable
> maint burden wrt non-modular packaging, we should re-examine this
> policy rather than trying to workaround it by going modular, which
> creates a different kind of maint burden.
>
In non-modular Fedora all packages that we have in Fedora build system (Koji)
are tagged into Fedora repositories and made available to all users on their
computers for any purpose. That implies that all packages in Fedora build system
must be fully supported including addressing all security issues.

In modular Fedora that's (effectively) not true. Packages that only exist
for the sake of building other packages (i.e. build-only dependencies) can be
retained in the Fedora build system and never left it. That means those
packages are never made available to Fedora users and thus a service level for
them is significantly lower. E.g. no security fixes, not bug fixes, no
integration, not tests, no API/ABI stability. The only requirement is that
they can be built and used for building other packages.


So conceptually, one way we can solve this problem by implementing a way
to mark certain non-modular RPMs as "build root only" packages and thus
composing them into a separate "build root" yum repo, that is not enabled
by default except in the build system.

Modularity is being used because it is the only solution that is available
today, not because it is a good/desired solution.


+1

The ability to hide/not-distribute build-only packages is frequently
cited as a benefit of modularity, but it breaks down when you have
multiple packages across modules share build-only packages.  If
moduleA and moduleB both have a build-only package named BuildTool
then those module developers should work together to either jointly
maintain BuildTool -or- duplicate BuildTool across both modules.
Since the advantage stated is being to hide build-only packages, this
makes it impossible to discover what build-only packages might exist
that you could use in your module.  With this example, modularity
leads to the bundling problem we've [Fedora] been very public about
disliking in the past.

The buildroot tries to solve that, but we already had a solution for
that and it was the repo.  Labeling packages as build-only or grouping
them as build tools only or otherwise marking them as packages that
exist to build other packages could be done in numerous ways that
still makes those tools discoverable to other package maintainers and
developers.

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[David Kaufmann]

On Fri, Sep 11, 2020 at 01:36:38PM +0200, Björn Persson wrote:
> So where is a global pool of volunteer-provided DNS resolvers similar
> to pool.ntp.org? I've never heard of one, and I suspect it's not
> advisable to do that with DNS.

There is currently no such thing that I know of, but lacking that the
next best thing is to also add other providers as FallbackDNS, so that
no single provider has all the requests for the machine.

e.g.:
FallbackDNS=8.8.8.8,9.9.9.10,1.1.1.1,208.67.222.222

I've included one address for the four big providers I know of, and (if
possible) the non-censoring variant.
I'm not sure if systemd uses them in a random order, but if it can this
would be preferable.

All the best,
David


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

Re: Package fixed: seq24

[ycollette . nospam]

I have already 2 packages in review:

lv2lint: https://bugzilla.redhat.com/show_bug.cgi?id=1844120
jamulus: https://bugzilla.redhat.com/show_bug.cgi?id=1840865

- Mail original -
De: "ycollette nospam" 
À: "Jerry James" 
Cc: "Development discussions related to Fedora" 
Envoyé: Vendredi 11 Septembre 2020 16:22:30
Objet: Re: Package fixed: seq24

Yes, I am really interested :)


- Mail original -
De: "Jerry James" 
À: "Development discussions related to Fedora" 
Cc: "ycollette nospam" 
Envoyé: Vendredi 11 Septembre 2020 16:18:40
Objet: Re: Package fixed: seq24

On Fri, Sep 11, 2020 at 8:08 AM Scott Talbert  wrote:
> Unfortunately, it appears that package has been retired for some time due
> to having failed to build.  It will require a new maintainer to step up
> and the package will have to go through a re-review.

Yann, are you interested in maintaining the seq24 package?  If so, we
can help you through the process of becoming maintainer.
-- 
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
___
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: Package fixed: seq24

[ycollette . nospam]

Yes, I am really interested :)


- Mail original -
De: "Jerry James" 
À: "Development discussions related to Fedora" 
Cc: "ycollette nospam" 
Envoyé: Vendredi 11 Septembre 2020 16:18:40
Objet: Re: Package fixed: seq24

On Fri, Sep 11, 2020 at 8:08 AM Scott Talbert  wrote:
> Unfortunately, it appears that package has been retired for some time due
> to having failed to build.  It will require a new maintainer to step up
> and the package will have to go through a re-review.

Yann, are you interested in maintaining the seq24 package?  If so, we
can help you through the process of becoming maintainer.
-- 
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: Package fixed: seq24

[Jerry James]

On Fri, Sep 11, 2020 at 8:08 AM Scott Talbert  wrote:
> Unfortunately, it appears that package has been retired for some time due
> to having failed to build.  It will require a new maintainer to step up
> and the package will have to go through a re-review.

Yann, are you interested in maintaining the seq24 package?  If so, we
can help you through the process of becoming maintainer.
-- 
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: Package fixed: seq24

[Scott Talbert]

On Fri, 11 Sep 2020, ycollette.nos...@free.fr wrote:


Just a mail to say I fixed the seq24 spec file.
It works fine on Fedora 31 / 32 for now.

Here is the bug report where I put the links to the fixed spec file:
https://bugzilla.redhat.com/show_bug.cgi?id=1675986#c14


Hi,

Unfortunately, it appears that package has been retired for some time due 
to having failed to build.  It will require a new maintainer to step up 
and the package will have to go through a re-review.


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: The Future of the Java Stack (also regarding ELN and RHEL)

[Stephen John Smoogen]

On Fri, 11 Sep 2020 at 07:27, Mario Torre  wrote:

> On Fri, Sep 11, 2020 at 11:04 AM Hans de Goede 
> wrote:
>
> > So for this tomcat needed for testing problem, I'm thinking that we
> > might solve this in a very non Fedora way. Why not bundle the old
> > tomcat-sources with the sources which need it for their test-suite
> > (and build it before running the tests).
>
> To be honest, when I look at this example, I think we shouldn't have
> that library/application packaged at all.
>
> If something can't even run the tests without requiring a 12+ year old
> obsoleted code/infrastructure, what chances are that it's maintained
> correctly?
>
>
The issue is that like https://xkcd.com/2347/ you need that software for a
couple dozen other things which may have no obvious relation to it. You
start pulling a large number of packages and people start screaming that
you are killing their need for using Fedora. that then puts pressure on
someone else to try a herculian task of keeping that package in. Or you
find out that this java package is getting pulled in for say a test suite
in rust and you have to pull the browser, mail client and dozen other
things out because of that. You might say "well I will maintain it until
that test gets pulled out" and then you find out a dozen other software
tools now need it because they saw Mozilla used it so it must be ok. As the
back of the bottle says "rinse, lather, repeat".

The bigger problem is that the software we ship has gotten more complicated
and interdependent over the last decade while the number of packagers who
can deal with that complexity has not grown. You can't bring in a newbie to
take over part of some of these stacks because it reverberates through a
hundred other packages without knowing it.

Personally I think the real problem are we are constantly trying to square
the circle.
1. we insist on trying to keep everything in one repository and hope that
some patched up depsolver can 'theoretically fix it for us' so we never
have an Extras/Core debacle again.
2. we put incredible pressure on maintainers and the project as a whole to
have ALL the software and not dropping anything even when it is clear it
doesn't work in a bundled with the OS format.
3. Never admitting that we messed up in the past but keep pushing through
assuming that by god our mighty brains can eventually solve these
conundrums.  This may sound like a dig about modularity but it is much more
about admitting that the Java maintainer complaints in 2006-> 2009? about
treating Java like C in packaging was going to lead to no one maintaining
it and it falling apart. The same problem is running through the Node
community, the Erlang community, etc etc. In the end we have a bunch of
rules to try and make a camel like a horse and then wonder why we keep
getting spat on by our 'horses'.



> Cheers,
> Mario
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH 
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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

Package fixed: seq24

[ycollette . nospam]

Hello,

Just a mail to say I fixed the seq24 spec file.
It works fine on Fedora 31 / 32 for now.

Here is the bug report where I put the links to the fixed spec file:
https://bugzilla.redhat.com/show_bug.cgi?id=1675986#c14

Best regards,

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

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

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/181 (x86_64)

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

ID: 662424  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/662424

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

ID: 662399  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/662399
ID: 662428  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/662428

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

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

ID: 662433  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/662433
ID: 662454  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/662454

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

ID: 662324  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/662324
ID: 662343  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/662343
ID: 662370  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/662370
ID: 662383  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/662383
ID: 662403  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/662403
ID: 662406  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/662406
ID: 662420  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/662420
ID: 662432  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/662432
ID: 662457  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/662457

Passed openQA tests: 167/181 (x86_64)

New passes (same test not passed in Fedora-33-20200910.n.0):

ID: 662476  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/662476
ID: 662495  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/662495

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.47 to 0.16
Previous test data: https://openqa.fedoraproject.org/tests/660712#downloads
Current test data: https://openqa.fedoraproject.org/tests/662322#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.26 to 0.12
Previous test data: https://openqa.fedoraproject.org/tests/660722#downloads
Current test data: https://openqa.fedoraproject.org/tests/662332#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.33 to 0.06
Previous test data: https://openqa.fedoraproject.org/tests/660724#downloads
Current test data: https://openqa.fedoraproject.org/tests/662334#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.24 to 0.10
Previous test data: https://openqa.fedoraproject.org/tests/660754#downloads
Current test data: https://openqa.fedoraproject.org/tests/662364#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 27 MiB to 31 MiB
System load changed from 1.01 to 0.79
Previous test data: https://openqa.fedoraproject.org/tests/660757#downloads
Current test data: https://openqa.fedoraproject.org/tests/662367#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 27 MiB to 34 MiB
System load changed from 0.52 to 1.12
Average CPU usage changed from 10.90476190 to 22.7333
Previous test data: https://openqa.fedoraproject.org/tests/660759#downloads
Current test data: https://openqa.fedoraproject.org/tests/662369#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used swap changed from 10 MiB to 12 MiB
1 packages(s) added since previous compose: comps-extras
System load changed from 1.59 to 1.21
Previous test data: https://openqa.fedoraproject.org/tests/660776#downloads
Current test data: https://openqa.fedoraproject.org/tests/662386#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used swap changed from 9 MiB to 11 MiB
1 packages(s) added since previous compose: comps-extras
System load changed from 0.93 to 1.05
Previous test data: https://openqa.fedoraproject.org/tests/660777#downloads
Current test data: 

[Bug 1878142] New: perl-Catalyst-Runtime-5.90128 is available

[bugzilla]

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

Bug ID: 1878142
   Summary: perl-Catalyst-Runtime-5.90128 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Catalyst-Runtime
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 5.90128
Current version/release in rawhide: 5.90126-5.fc33
URL: http://search.cpan.org/dist/Catalyst-Runtime/

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


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

Fedora 33 compose report: 20200911.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-33-20200910.n.0
NEW: Fedora-33-20200911.n.0

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

Size of added packages:  0 B
Size of dropped packages:22.41 KiB
Size of upgraded packages:   146.55 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -42.19 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

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

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: python-multio-0.2.4-8.fc33
Summary: Unified async library for curio and trio
RPMs:python3-multio
Size:22.41 KiB


= UPGRADED PACKAGES =
Package:  dnfdragora-2.0.4-2.fc33
Old package:  dnfdragora-2.0.4-1.fc33
Summary:  DNF package-manager based on libYui abstraction
RPMs: dnfdragora dnfdragora-updater
Size: 425.91 KiB
Size change:  220 B
Changelog:
  * Tue Aug 25 2020 Neal Gompa  - 2.0.4-2
  - Add missing dep on comps-extras for comps group icons (#1872359)


Package:  pki-core-10.9.2-3.fc33
Old package:  pki-core-10.9.2-2.fc33
Summary:  Dogtag PKI Core Package
RPMs: pki-base pki-base-java pki-ca pki-console pki-javadoc pki-kra 
pki-ocsp pki-server pki-symkey pki-tks pki-tools pki-tps python3-pki
Size: 16.54 MiB
Size change:  2.38 KiB
Changelog:
  * Tue Sep 08 2020 Dogtag PKI Team  - 10.9.2-3
  - Fix Fedora 31/32 to Fedora 33/rawhide upgrade path
Resolves: rh-bz#1871990


Package:  python-graph-tool-2.33-1.fc33
Old package:  python-graph-tool-2.29-3.fc33
Summary:  Efficient network analysis tool written in Python
RPMs: python3-graph-tool
Size: 120.66 MiB
Size change:  -42.21 MiB
Changelog:
  * Tue May 26 2020 Miro Hron??ok  - 2.29-4
  - Rebuilt for Python 3.9

  * Sat May 30 2020 Jonathan Wakely  - 2.29-5
  - Rebuilt for Boost 1.73
  - Simplify shell command to determine number of threads to use

  * Wed Jul 29 2020 Fedora Release Engineering  - 
2.29-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

  * Sat Aug 01 2020 Fedora Release Engineering  - 
2.29-7
  - Second attempt - Rebuilt for
https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

  * Fri Sep 04 2020 Ankur Sinha  - 2.33-1
  - Update to latest release
  - Disable LTO
  - update COPYING file name
  - Update license


Package:  toolbox-0.0.95-1.fc33
Old package:  toolbox-0.0.94-1.fc33
Summary:  Unprivileged development environment
RPMs: toolbox toolbox-experience toolbox-support toolbox-tests
Size: 8.93 MiB
Size change:  19.34 KiB
Changelog:
  * Sun Aug 30 2020 Debarshi Ray  - 0.0.95-1
  - Update to 0.0.95



= 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

[Vít Ondruch]

Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a):
> * Tom Hughes via devel:
>
>> On 11/09/2020 07:13, Ondrej Dubaj wrote:
>>
>>> There seemed to be no big reason for moving the libraries to the
>>> main package in the past, so I consider f34 as a good candidate for
>>> such a change. It would be great, if  you share your opinions and
>>> concerns for this topic.
>> Tom Lane has explained the reason on the ticket, it's because the
>> library is often dlopened by a client application instead of being
>> linked to.


"often" is relative. I see this mentioned for following packages:


java-1.5.0-ibm-jdbc

java-1.6.0-sun-jdbc

java-1.5.0-bea-jdbc


Which probably shares common history and at least one of them admitted
the mistake [1] and started to use the versioned .so file.

So are there any other cases?


> Yes, that is sufficient reason not to do the move.  Third-party
> applications will break.


And they should be fixed. I understand there is never the right time to
fix this, but if not now, then when?


> Some people also really dislike installing
> *-devel packages in production, so there might not be an easy fix for
> them.
>
> The library probably should not have a versioned soname in the first
> place, with backwards compatibility achieved by different means.  But
> that does not matter now.
>
> Thanks,
> Florian


Vít


[1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24

___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Björn Persson]

John M. Harris Jr wrote:
> On Thursday, September 10, 2020 11:56:25 PM MST alcir...@posteo.net wrote:
> > But systemd in Fedora is built to use 
> > FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
> > 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org  
> 
> Sounds like a good change, which should be made for DNS as well.

So where is a global pool of volunteer-provided DNS resolvers similar
to pool.ntp.org? I've never heard of one, and I suspect it's not
advisable to do that with DNS.

Björn Persson


pgpOgqC0Qs2k_.pgp
Description: OpenPGP digital signatur
___
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-20200911.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 4/170 (x86_64)

Old failures (same test failed in Fedora-Rawhide-20200910.n.0):

ID: 662184  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/662184
ID: 662186  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/662186
ID: 662213  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/662213
ID: 662271  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/662271

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

Old soft failures (same test soft failed in Fedora-Rawhide-20200910.n.0):

ID: 662138  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/662138
ID: 662157  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/662157
ID: 662197  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/662197
ID: 662223  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/662223
ID: 662236  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/662236
ID: 662257  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/662257

Passed openQA tests: 160/170 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20200910.n.0):

ID: 662212  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/662212

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
8 packages(s) added since previous compose: bubblewrap, flashrom, fwupd, 
libftdi, libgcab1, libjcat, libsmbios, libxmlb
1 packages(s) removed since previous compose: dbxtool
1 services(s) removed since previous compose: dbxtool.service
Previous test data: https://openqa.fedoraproject.org/tests/661668#downloads
Current test data: https://openqa.fedoraproject.org/tests/662137#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
System load changed from 0.10 to 0.21
Previous test data: https://openqa.fedoraproject.org/tests/661709#downloads
Current test data: https://openqa.fedoraproject.org/tests/662178#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
23 packages(s) added since previous compose: ModemManager-glib, 
abattis-cantarell-fonts, adobe-source-code-pro-fonts, bubblewrap, dmidecode, 
flashrom, fwupd, glib-networking, gsettings-desktop-schemas, json-glib...
1 packages(s) removed since previous compose: dbxtool
1 services(s) removed since previous compose: dbxtool.service
Previous test data: https://openqa.fedoraproject.org/tests/661710#downloads
Current test data: https://openqa.fedoraproject.org/tests/662179#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 21 MiB to 17 MiB
System load changed from 0.49 to 0.67
Previous test data: https://openqa.fedoraproject.org/tests/661850#downloads
Current test data: https://openqa.fedoraproject.org/tests/662181#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 19 MiB to 15 MiB
Previous test data: https://openqa.fedoraproject.org/tests/661714#downloads
Current test data: https://openqa.fedoraproject.org/tests/662183#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 0.53 to 0.97
Previous test data: https://openqa.fedoraproject.org/tests/661732#downloads
Current test data: https://openqa.fedoraproject.org/tests/662201#downloads

Installed system changes in test x86_64 universal install_package_set_minimal: 
System load changed from 0.05 to 0.19
Previous test data: https://openqa.fedoraproject.org/tests/661839#downloads
Current test data: https://openqa.fedoraproject.org/tests/662297#downloads


-- 
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 Future of the Java Stack (also regarding ELN and RHEL)

[Mario Torre]

On Fri, Sep 11, 2020 at 11:04 AM Hans de Goede  wrote:

> So for this tomcat needed for testing problem, I'm thinking that we
> might solve this in a very non Fedora way. Why not bundle the old
> tomcat-sources with the sources which need it for their test-suite
> (and build it before running the tests).

To be honest, when I look at this example, I think we shouldn't have
that library/application packaged at all.

If something can't even run the tests without requiring a 12+ year old
obsoleted code/infrastructure, what chances are that it's maintained
correctly?

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
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-34-20200911.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

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

Old soft failures (same test soft failed in Fedora-IoT-34-20200907.0):

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

Passed openQA tests: 15/16 (x86_64)

New passes (same test not passed in Fedora-IoT-34-20200907.0):

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

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
1 services(s) removed since previous compose: clevis-luks-askpass.service
System load changed from 0.12 to 0.36
Previous test data: https://openqa.fedoraproject.org/tests/657454#downloads
Current test data: https://openqa.fedoraproject.org/tests/662307#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
2 services(s) removed since previous compose: clevis-luks-askpass.service, 
dbxtool.service
System load changed from 0.04 to 0.23
Previous test data: https://openqa.fedoraproject.org/tests/657456#downloads
Current test data: https://openqa.fedoraproject.org/tests/662309#downloads
-- 
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 Future of the Java Stack (also regarding ELN and RHEL)

[Hans de Goede]

Hi,

On 9/11/20 12:47 PM, Vít Ondruch wrote:


Dne 11. 09. 20 v 11:03 Hans de Goede napsal(a):



On 9/11/20 10:16 AM, Mikolaj Izdebski wrote:


Another, more concrete example: core Ant doesn't have any dependencies
beyond JDK. It is easy to build and maintain, yet very functional. On
the other hand, full Ant with all the optional tasks depends on more
than 200 Java packages. For the purpose of building all packages that
I am interested in, core Ant with JUnit tasks (total of 3 packages) is
sufficient. Functionalities of Ant like sending emails or image
processing are obviously not needed in this case. If building other
packages is the only use of Ant then it can be maintained much more
easily (3 instead of ~250 packages). But when Ant is ursine package in
Fedora then it should be the full Ant - we can't claim to deliver Ant
to users while it is just part of it. Eclipse in Fedora requires full
Ant too.


So if you say that you only need the minimal Ant, and I guess many
packages only need the minimal Ant to build, then why not have
an ant-minimal package, like we have a vim-minimal ?

Now I guess that vim-minimal and "proper" vim are both build from the
same source-rpm; and normally we never allow 2 srpms with the same
upstream sources in them. But I think that in this case we could make
an exemption where there is a separate pkg-git and srpm for an
ant-minimal
which you would maintain.

And then the community / java-sig can maintain the full Ant as I believe
is already happening since we do have an ant packaged in Fedora 33 atm.



How this reduce the workload?


It doesn't the purpose of my email was to look for ways to get
the modular ant/maven repos work moved back into ursine without
increasing the workload for the maintainers of those modular
repos.

So the way to look at this, is does it increase workload,
and AFAICT it does not increase workload, while it would allow
us to fold the work being done in the modular repos back
into the ursine repo (for the ant example at least).

Alternatively if we fold that work back into the ursine repos,
then the modular builds could start relying on the full-blown
ant build maintained by the java-SIG in the ursine repos and
drop their own ant-minimal, at which point it would reduce the
workload for the maintainers of the modular repos.

My idea behind having a separate ant-minimal is that they
then can ensure that that is new enough and otherwise matches
their needs without relying on the full-blown version, but
actually somply switching to the full-blown java-SIG maintained
version might be better.

Regards,

Hans


p.s.

I would not mind picking up maintenance of 1 or 2 of the
less frequently changing java packages (*) if that helps.
I wonder how much more people there are like me who care
enough about java to be willing to put some work in
(but not lots of work) ?

Perhaps it would be a good idea for the java-SIG to make
a list of easy to maintain (for an experienced packager)
pkgs which could use a new primary maintainer. I realize
maintaining the entire stack is a team effort, so the rest of
the java-SIG will of course be/stay a co-maintainer of these.
But having things like rebasing to latest upstream, or just
addressing bugzillas taken care of mostly by a new
primary maintainer who is willing to pick up some packages
might help reduce the load ?

The idea here is for someone (e.g.) me to NOT jump in now,
do a bunch of work to help out and then disappear again.
Instead I would invest say 1-2 hours every 2 weeks, which
may not seem much but over time adds up and if we can
get more people to do this, then maybe we can spread the
load of the java packages in the ursine repos better ?



*) But definitely not the entire stack
___
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: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Vít Ondruch]

Dne 10. 09. 20 v 17:32 Michael Catanzaro napsal(a):
>
> On Thu, Sep 10, 2020 at 9:24 am, Vít Ondruch  wrote:
>> Hi Michael,
>>
>> Could you please provide more details? This is content of my
>> nsswitch.conf:
>>
>>
>> ~~~
>>
>> $ grep mdns4_minimal /etc/authselect/user-nsswitch.conf
>> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
>> ~~~
>>
>>
>> How that happened? From what version of what package it happened? Why
>> should I do some changes manually and they are not handled
>> automatically?
>
> You're completely missing resolved from your hosts line, so you'll get
> legacy name resolution behavior via nss-dns (which is what Ubuntu does).
>
> There were multiple different bugs here, so it's a bit hard to keep
> track of them all. systemd package was being too cautious about
> deleting /etc/resolv.conf, so some users wound up with
> /etc/resolv.conf managed by NetworkManager even though systemd is
> running, which was not what I had intended. Plus we originally planned
> for resolved to handle mDNS resolution instead of avahi, but we
> discovered that it doesn't work as expected. We have hacky scripts in
> the systemd and nss-mdns packages to manage the hosts line, plus it's
> managed by authselect itself. They all have to agree on expected
> configuration and it's all a bit fragile. The systemd package script
> is careful to only touch this line if the order matches the previous
> Fedora default configuration, so we have to choose between
> automatically reordering the nss modules to fix this for users of F33
> pre-beta, vs. clobbering intentional configuration changes for users
> who actually wanted the hosts line to be different. If this had
> reached stable releases, then we'd really have to do that clobbering,
> but it didn't, so seems best to be more conservative here. These
> scripts would not be needed if we could add systemd nss modules and
> nss-mdns to the nsswitch.conf provided by the glibc package.


Thank you for the details.

And now I wonder, is there a way to restore the pristine state of these
files without touching them directly (with exception of deleting them)?
E.g.:

~~~

$ rm /etc/authselect/user-nsswitch.conf

$ sudo dnf reinstall authselect

~~~

Also I don't understand why I have files on my system which are not
owned by anything:

~~~

$ rpm -qf /etc/authselect/user-nsswitch.conf
file /etc/authselect/user-nsswitch.conf is not owned by any package

~~~

How are these files created for fresh system?

And also, is there long term vision to prevent issues, that nobody
really knows who edited which configuration file? I understand that
there is some legacy, multiple projects involved, etc. but I don't want
to care about random configuration files in /etc.


Vít

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

Re: question about ELN builds of glusterfs and ceph?

[Josh Boyer]

On Tue, Sep 8, 2020, 9:16 AM Kaleb Keithley  wrote:

> I confess I'm a bit ignorant about how the ELN builds are going to be
> used. Especially the ELN builds of glusterfs and ceph.
>
> That aside—
>
> Red Hat ships GlusterFS and Ceph (RHGS and RHCS respectively) as products,
> and generally speaking glusterfs and ceph packages are not included in
> RHEL; at least they haven't been so far. There are special builds of RHGS
> in the RHEL base that are a subset of the RHGS product packages. And I'm
> not sure what, if any, subset of RHCS product packages are provided in the
> RHEL base.
>
> And at RHEL 8.0 (actually before 8.0) there were issues with RHEL 8 having
> inherited the Fedora glusterfs packages into the RHEL base which conflicted
> with what the product team was going to be providing — incorrect version,
> no subset, etc.
>
> I'd like to avoid a repeat of those issues. I hope the people working on
> ELN are coordinating with RHGS and RHCS product teams to avoid a
> recurrence of them.
>

Generally speaking, whatever is in Fedora at the branch time is what would
be used.  There are config files in eln that pull in various bits and ceph
and gluster can edit those to pick up the right subpackages.

So it's all mostly up to ceph and gluster to land things in Fedora but we
can of course discuss internally.

josh
___
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 Future of the Java Stack (also regarding ELN and RHEL)

[Vít Ondruch]

Dne 11. 09. 20 v 11:03 Hans de Goede napsal(a):
>
>
> On 9/11/20 10:16 AM, Mikolaj Izdebski wrote:
>
>> Another, more concrete example: core Ant doesn't have any dependencies
>> beyond JDK. It is easy to build and maintain, yet very functional. On
>> the other hand, full Ant with all the optional tasks depends on more
>> than 200 Java packages. For the purpose of building all packages that
>> I am interested in, core Ant with JUnit tasks (total of 3 packages) is
>> sufficient. Functionalities of Ant like sending emails or image
>> processing are obviously not needed in this case. If building other
>> packages is the only use of Ant then it can be maintained much more
>> easily (3 instead of ~250 packages). But when Ant is ursine package in
>> Fedora then it should be the full Ant - we can't claim to deliver Ant
>> to users while it is just part of it. Eclipse in Fedora requires full
>> Ant too.
>
> So if you say that you only need the minimal Ant, and I guess many
> packages only need the minimal Ant to build, then why not have
> an ant-minimal package, like we have a vim-minimal ?
>
> Now I guess that vim-minimal and "proper" vim are both build from the
> same source-rpm; and normally we never allow 2 srpms with the same
> upstream sources in them. But I think that in this case we could make
> an exemption where there is a separate pkg-git and srpm for an
> ant-minimal
> which you would maintain.
>
> And then the community / java-sig can maintain the full Ant as I believe
> is already happening since we do have an ant packaged in Fedora 33 atm.


How this reduce the workload? As far as I understand, there is currently
Ant minimal in module and full featured Ant as ursine package and both
companies complain (more or less) that they want to do less.

And of course one of the ideas of modularity were that you have one
repository, actually one branch, and from there you build Ant for module
and the same Ant as a ursine package, but apparently, there are
different needs. Therefore Ant has to be maintained twice.


Vít

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

Fedora rawhide compose report: 20200911.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200910.n.0
NEW: Fedora-Rawhide-20200911.n.0

= SUMMARY =
Added images:0
Dropped images:  6
Added packages:  75
Dropped packages:4
Upgraded packages:   73
Downgraded packages: 0

Size of added packages:  91.43 MiB
Size of dropped packages:30.10 MiB
Size of upgraded packages:   1.02 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200910.n.0.x86_64.vagrant-libvirt.box
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20200910.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20200910.n.0.iso
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20200910.n.0.iso
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200910.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20200910.n.0.iso

= ADDED PACKAGES =
Package: golang-github-agext-levenshtein-1.2.3-1.fc34
Summary: Levenshtein distance and similarity metrics
RPMs:golang-github-agext-levenshtein-devel
Size:20.17 KiB

Package: golang-github-alecthomas-kong-hcl-2-2.0.0-1.fc34
Summary: A Kong configuration loader for HCL
RPMs:golang-github-alecthomas-kong-hcl-2-devel
Size:16.35 KiB

Package: golang-github-apparentlymart-dump-0-0.1.20200905git042adf3.fc34
Summary: Utility for formatting Go values in a pretty-printed way
RPMs:golang-github-apparentlymart-dump-devel
Size:15.81 KiB

Package: golang-github-apparentlymart-textseg-12-12.0.0-2.fc34
Summary: Go implementation of Unicode Text Segmentation
RPMs:golang-github-apparentlymart-textseg-12-devel
Size:63.86 KiB

Package: golang-github-aws-lambda-1.19.1-1.fc34
Summary: Libraries, samples and tools to help Go developers develop AWS Lambda 
functions
RPMs:golang-github-aws-lambda golang-github-aws-lambda-devel
Size:6.27 MiB

Package: golang-github-bketelsen-crypt-0.0.3-1.fc34
Summary: Store and retrieve encrypted configs from etcd or consul
RPMs:golang-github-bketelsen-crypt-devel
Size:22.89 KiB

Package: golang-github-bonitoo-io-sql-bigquery-0.3.4-1.fc34
Summary: Go database/sql driver for Google BigQuery
RPMs:golang-github-bonitoo-io-sql-bigquery-devel
Size:17.66 KiB

Package: golang-github-chris-ramon-douceur-0.2.0-1.20200910gitf346305.fc34
Summary: Simple CSS parser and inliner in Go
RPMs:golang-github-chris-ramon-douceur 
golang-github-chris-ramon-douceur-devel
Size:6.20 MiB

Package: golang-github-cncf-udpa-0.0.1-1.fc34
Summary: Universal Data Plane API Working Group (UDPA-WG)
RPMs:golang-github-cncf-udpa-devel
Size:44.41 KiB

Package: golang-github-cockroachdb-datadriven-1.0.0-1.fc34
Summary: Data-Driven Testing for Go
RPMs:golang-github-cockroachdb-datadriven-devel
Size:22.81 KiB

Package: golang-github-cockroachdb-errors-1.7.4-1.fc34
Summary: Go error library with error portability over the network
RPMs:golang-github-cockroachdb-errors-devel
Size:108.76 KiB

Package: golang-github-cockroachdb-logtags-0-0.1.20200908giteb05cc2.fc34
Summary: Key/value annotations for Go contexts
RPMs:golang-github-cockroachdb-logtags-devel
Size:16.68 KiB

Package: golang-github-cockroachdb-pebble-0-0.1.20200908git069f1e1.fc34
Summary: RocksDB/LevelDB inspired key-value database in Go
RPMs:golang-github-cockroachdb-pebble golang-github-cockroachdb-pebble-devel
Size:15.85 MiB

Package: golang-github-cockroachdb-redact-1.0.5-1.fc34
Summary: Utilities to redact Go strings for confidentiality
RPMs:golang-github-cockroachdb-redact-devel
Size:42.34 KiB

Package: golang-github-cockroachdb-sentry-0.6.1-1.fc34
Summary: Official Sentry SDK for Go
RPMs:golang-github-cockroachdb-sentry-devel
Size:67.44 KiB

Package: golang-github-cucumber-gherkin-15.0.2-1.fc34
Summary: Gherkin parser/compiler for Go
RPMs:compat-golang-github-cucumber-gherkin-15-devel 
golang-github-cucumber-gherkin-devel
Size:45.93 KiB

Package: golang-github-cucumber-godog-0.10.0-1.fc34
Summary: Cucumber for golang
RPMs:golang-github-cucumber-godog golang-github-cucumber-godog-devel
Size:12.86 MiB

Package: golang-github-cucumber-messages-13.0.1-1.fc34
Summary: Cucumber Messages for Go (Protocol Buffers)
RPMs:compat-golang-github-cucumber-messages-13-devel 
golang-github-cucumber-messages-devel
Size:50.25 KiB

Package: golang-github-envoyproxy-control-plane-0.9.6-1.fc34
Summary: Go implementation of data-plane-api
RPMs:golang-github-envoyproxy-control-plane-devel
Size:893.28 KiB

Package: golang-github-envoyproxy-protoc-gen

Re: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 11, 2020 at 01:55:54AM -0700, John M. Harris Jr wrote:
> On Thursday, September 10, 2020 10:38:51 PM MST Zbigniew Jędrzejewski-Szmek 
> wrote:
> > On Thu, Sep 10, 2020 at 06:37:56PM -0700, John M. Harris Jr wrote:
> > 
> > > On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek
> > > 
>  wrote:
> > > 
> > > > On Thu, Sep 10, 2020 at 01:27:30PM +0200, alcir...@posteo.net wrote:
> > > > 
> > > > 
> > > > > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > > > > 
> > > > > 
> > > > > > > 
> > > > > > > These DNS addresses are bundled upstream in systemd. And they are
> > > > > > > used
> > > > > > > in the event of a misconfiguration of your network settings,
> > > > > > > isn't
> > > > > > > it?
> > > > > > > However they are easily customizable in
> > > > > > > /etc/systemd/resolved.conf
> > > > > > > (FallbackDNS option)
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > It's about the distribution's default setting, not a configuration
> > > > > > possibility.
> > > > > 
> > > > > 
> > > > > 
> > > > > "Which servers are used (or any at all) as a fallback is a
> > > > > compile-time
> > > > > as well as a runtime option. If you don't like the upstream defaults,
> > > > > then please work with downstream to pick different options or make
> > > > > the
> > > > > choices locally in your configuration files."
> > > > > 
> > > > > As a concerned user, you can configure the FallbackDNS option in
> > > > > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google
> > > > > and
> > > > > so on will never be contacted.
> > > > > 
> > > > > Obviously the distribution can put different DNS in systemd at
> > > > > compile
> > > > > time, or provide a default resolved.conf file where FallbackDNS is
> > > > > uncommented and filled.
> > > > 
> > > > 
> > > > 
> > > > Exactly. With my maintainer hat on: this is a non-issue. We consider
> > > > current defaults (a working fallback configuration out of the box that
> > > > has a very minor information leak) better than the proposed (a
> > > > non-working
> > > > fallback configuration). If you need to, provide the trivial two-line
> > > > dropin file to override this locally.
> > > 
> > > 
> > > Zbyszek,
> > > 
> > > I'm definitely not suggesting something that is "non-working". That said,
> > > not  having any DNS servers configured indicates that remote lookup
> > > should not be used, not that a random DNS server should be picked by the
> > > resolver itself. When there are no DNS servers, the expected behavior is
> > > that no external servers are used for lookup.
> > 
> > 
> > There are no environments where remote lookup SHOULD NOT not be used. There
> > are remote environments where it MUST NOT be used, and environments where
> > it is expected to work. For the former, just emptying /etc/resolv.conf is a
> > halfway measure that doesn't do enough so strong filtering with namespaces
> > or routing must be provided anyway. In the second case, we want to have
> > working networking (even if your local crappy dns router forgets to attach
> > a dns server to the dhcp lease or such).
> 
> When you have no configured DNS servers, remote lookup SHOULD NOT be used. 
> Only local domain resolution should be used. This is how it has been for 
> decades, and there's no reason to change this. That's expected functionality.
> 
> We have working networking even without DNS. If there are no DNS servers 
> configured, no remote DNS servers should ever be contacted by the resolver.

You position is very clear. Let's agree to disagree.

Zbyszek
___
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 Future of the Java Stack (also regarding ELN and RHEL)

[Mikolaj Izdebski]

On Fri, Sep 11, 2020 at 11:01 AM Miro Hrončok  wrote:
>
> Thank you for describing the entire story from your pov, I think it's very 
> helpful!
>
> On 11. 09. 20 9:34, Mikolaj Izdebski wrote:
> > I can't drop my
> > packages and move back to co-maintaining ursine packages as it would
> > mean losing 2 years of my work and the features I developed.
>
> I guess there are two sides of this:
>
>   - the lost features
>
> Can you work together with the new Java maint SIG to have those features
> integrated in the nonmodular packages?

Possibly. I will think about this more.

>
>   - the lost years
>
> While sad I believe that at a certain point, we need to be able to admit that
> the years are lost in order to save ourselves from loosing even more years. 
> This
> is a very important aspect in accepting that modularity in Fedora was a 
> failure.
> If we don't do this, we'll keep failing.

I agree and I accept that.

Thanks,
--
Mikolaj

>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Mikolaj Izdebski]

On Fri, Sep 11, 2020 at 10:54 AM Tomasz Torcz  wrote:
>
> On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> > You get a side tag in Koji where you can have private build-only
> > dependencies that are discarded (filtered) once they are no longer
> > needed, after module build is done. For build-only packages most of
> > security vulnerabilities are not exploitable easily, or at all,
> > therefore are low-severity, which greatly limits maintenance work
> > required to address them. For example, if upstream tests are ran on an
> > obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> > but I can package old Tomcat and run the tests.
>
>   Whoha! Let's step back for a minute and look at this example.
> What are the reasons to run tests?  To make sure the package will run
> correctly..

To prevent RPM build from succeeding in case bugs are found and
forcing the maintainer to investigate the issue (fix the bug, disable
broken test etc.)

> Why run tests on 12-years old version instead of on current one?
> Probably because tests fail on current version?

Because at the time tests were developed that was the most recent
Tomcat version. Since then upstream did not update the perfectly
working test suite ("If it ain't broke, don't fix it"). They will not
even accept our contribution to update the test suite.

>   Will the end user run the package on obsolete Tomcat or on the current one?

Neither. The package is a HTTP client and tests merely need the server
side (Tomcat).

> Of course on the current one. The one on which tests fail.
> Tests in this case are worthless, they are not testing the real
> situation. Disabling tests is no worse than testing on obsolete version.
> Relying on such tests is a disservice for the end user.
>
>   The point of testing is to validate code in real situation.
> Crafting special, unrealistic environment (12 years old Tomcat) just to have
> test pass is missing the point of tests.
>
> --
> Tomasz Torcz   There exists no separation between gods and men:
> to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
> Herbert
> ___
> 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 Future of the Java Stack (also regarding ELN and RHEL)

[Aleksandar Kurtakov]

On Fri, Sep 11, 2020 at 11:54 AM Tomasz Torcz  wrote:

> On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> > You get a side tag in Koji where you can have private build-only
> > dependencies that are discarded (filtered) once they are no longer
> > needed, after module build is done. For build-only packages most of
> > security vulnerabilities are not exploitable easily, or at all,
> > therefore are low-severity, which greatly limits maintenance work
> > required to address them. For example, if upstream tests are ran on an
> > obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> > but I can package old Tomcat and run the tests.
>
>   Whoha! Let's step back for a minute and look at this example.
> What are the reasons to run tests?  To make sure the package will run
> correctly..
> Why run tests on 12-years old version instead of on current one?
> Probably because tests fail on current version?
>
>   Will the end user run the package on obsolete Tomcat or on the current
> one?
> Of course on the current one. The one on which tests fail.
> Tests in this case are worthless, they are not testing the real
> situation. Disabling tests is no worse than testing on obsolete version.
> Relying on such tests is a disservice for the end user.
>
>   The point of testing is to validate code in real situation.
> Crafting special, unrealistic environment (12 years old Tomcat) just to
> have
> test pass is missing the point of tests.
>

Well, you do realize how much not feasible it is for the Fedora maintainer
of hundred packages to go out and not only fix the builds, bugs, CVEs and
etc. but even the tests for all these packages. The unrealistic
expectations for what package maintainer should do is really not helping
growing that number.


>
> --
> Tomasz Torcz   There exists no separation between gods and men:
> to...@pipebreaker.pl   one blends softly casual into the other.  —
> Frank Herbert
> ___
> 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
>


-- 
Alexander Kurtakov
Red Hat Eclipse Team
___
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-32-20200911.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-32-20200910.0):

ID: 662135  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/662135

Passed openQA tests: 6/7 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] Re: 389-ds Migration to GitHub - [2020-09-12 - 2020-09-13]

[Simon Pichugin]

Hi team,
so everything is an order and ready.

Today at 3 pm EDT we disable Pagure notifications and I start the migration
process.

On Saturday, after I clone all of the issues and PRs and close Pagure
issues, I'll put 389-ds-base issue tracker on 'read-only' mode.
And during Saturday-Sunday I'll update all related Bugzillas with new Devel
Whiteboard issue numbers and links.

And finally, on Sunday, I'll recheck that everything is in order and I'll
open the new repo to the public (and I'll post the update in this mail
thread).

P.S. in case, you'll get some unwanted email notifications (you should
really not), I apologize for all inconvenience.

Sincerely,
Simon

On Wed, Sep 9, 2020 at 1:48 PM Simon Pichugin  wrote:

> Thanks!
>
> So, the final look is ready, please, check:
> https://github.com/droideck/389-ds-base
>
> The migration project that can be used by other teams:
> https://github.com/droideck/patogith
>
> Issues:
> https://github.com/droideck/389-ds-base/issues
>
> Pull requests can be found by filtering labels (I've created them as
> issues so we can store all of the valuable discussions that were held
> there):
> https://github.com/droideck/389-ds-base/issues?q=label%3APR+
>
> The pull requests that were open on the moment of migration (you can
> download the code from the last comment) are here:
> https://github.com/droideck/389-ds-base/issues?q=label%3AOpen+label%3APR
>
> Milestones:
> https://github.com/droideck/389-ds-base/milestones
>
> Tags and releases:
> https://github.com/droideck/389-ds-base/tags
> https://github.com/droideck/389-ds-base/releases
>
> The updated Bugzillas will look like this (I've changed Devel Whiteboard
> and added the link to Links table):
> https://partner-bugzilla.redhat.com/show_bug.cgi?id=1376823
>
> Pagure issues and PRs will be closed and each of them will have the
> message similar to this:
> https://pagure.io/SSSD/sssd/issue/36#comment-645569
> The code:
> https://github.com/droideck/patogith/blob/master/lib/patogith/pagure.py#L42
>
> So. please, check and we can move on this weekend if everything is good.
>
> Sincerely,
> Simon
>
> On Tue, Sep 8, 2020 at 8:21 PM Simon Pichugin  wrote:
>
>> Hi team,
>> for the last couple of weeks, I was working on the migration tool that
>> will allow us to switch 389-ds project to GitHub.
>>
>> It will be done through the weekend 2020-09-12 - 2020-09-13.
>>
>> I was testing it on a custom repo for some time but, please, review the
>> code, if you would like to:
>> https://github.com/droideck/patogith/
>>
>> I will open the example 389-ds-base [migrated] repo tomorrow when my
>> final run will finish.
>>
>> I've managed to disable Github notifications but there are two more
>> things that should be taken into the account:
>>
>> 1. Pagure notifications - as Viktor has suggested, probably, we can ask
>> Pierre-Yves Chibon  to do this for us at Friday.
>>
>> 2. Bugzilla notifications. It may be that it's not possible to disable it
>> for everyone involved. In that case, it will be one time thing that will
>> spam you with 3000 emails. :) But I hope not.
>>
>> Regards,
>> Simon
>>
>>
>>
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Vít Ondruch]

Dne 11. 09. 20 v 8:43 Petr Pisar napsal(a):
> On Thu, Sep 10, 2020 at 09:59:05PM +, Zbigniew Jędrzejewski-Szmek wrote:
>> For Maven packaging the appeal of Modularity is clearly the privatization of
>> the dependency tree, which obviously undercuts the ecosystem of packages.
>>
> You are right that bundling is one of the features of Modularity and that this
> freedom undermines an integration effort on the Fedora distribution level.
>
> But bundling is not the only appeal for Maven maintainers. If I can speek for
> Mikolaj, then another appeal is sharing a module among multiple Fedora
> releases. Because byte-compiled Java code is portable, it is possible to build
> a module on Fedora 31 and have the same module build available on Fedora 34.
> This saves the module maintainers from the burden of rebuilding the Java
> packages for each Fedora and Modularity is the first place that actuallty can
> leverage this Java feature.
>

While the idea of sharing between Fedora is nice, it won't work in
practice. There is more then just "byte-compiled Java code is portable".
This allows you to ship certain set of the packages, but it won't allow
you to easily update any single package. You have always consider the
API changes, dependency changes and if the update of the package, which
you would do on Rawhide and would be perfectly fine, won't break other
parts of F31 ecosystem. The choice is not any easier.

If on the other hand the F31 was left in the state when it was branched
+ applying fixes, the Rawhide would be free to update the packages.

Not mentioning that keeping the one set of packages is possibly against
the idea of Fedora update policy [1].


Vít



[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/




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

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Mat Booth]

On Fri, 11 Sep 2020 at 09:54, Tomasz Torcz  wrote:
>
> On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> > You get a side tag in Koji where you can have private build-only
> > dependencies that are discarded (filtered) once they are no longer
> > needed, after module build is done. For build-only packages most of
> > security vulnerabilities are not exploitable easily, or at all,
> > therefore are low-severity, which greatly limits maintenance work
> > required to address them. For example, if upstream tests are ran on an
> > obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> > but I can package old Tomcat and run the tests.
>
>   Whoha! Let's step back for a minute and look at this example.
> What are the reasons to run tests?  To make sure the package will run
> correctly..
> Why run tests on 12-years old version instead of on current one?
> Probably because tests fail on current version?

No, not at all. It's not that the tests fail on newer versions (it
probably just needs a servlet container environment) but that this is
the version of tomcat that was current when the test fixtures were
written. Tomcats' changing embedding APIs in no way invalidate tests
performed in a standards-compliant servlet container environment.

>
>   Will the end user run the package on obsolete Tomcat or on the current one?
> Of course on the current one. The one on which tests fail.
> Tests in this case are worthless, they are not testing the real
> situation. Disabling tests is no worse than testing on obsolete version.
> Relying on such tests is a disservice for the end user.
>
>   The point of testing is to validate code in real situation.
> Crafting special, unrealistic environment (12 years old Tomcat) just to have
> test pass is missing the point of tests.
>
> --
> Tomasz Torcz   There exists no separation between gods and men:
> to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
> Herbert
> ___
> 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



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

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Hans de Goede]

Hi,

First of all a big thank you to everyone involved in the
discussion for the constructive discussion.

I agree that the situation around java packaging is quite
worrying and I'm happy to see that people are trying to
come up with a pragmatic solution to the current deadlock
situation.

On 9/11/20 10:16 AM, Mikolaj Izdebski wrote:




Modularity provides not only a different way of grouping or delivering
RPM packages, but most importantly, a different way of building RPM
packages.




Allow me zoom in on some of the examples you give here. I realize
they are just examples but maybe we can extract some patterns from
them and come up with solutions to allow you to maintain the and
and maven stacks inside the ursine package collection, without
increasing your workload.


You get a side tag in Koji where you can have private build-only
dependencies that are discarded (filtered) once they are no longer
needed, after module build is done. For build-only packages most of
security vulnerabilities are not exploitable easily, or at all,
therefore are low-severity, which greatly limits maintenance work
required to address them. For example, if upstream tests are ran on an
obsolete, 12-years old version of Tomcat, I don't need to skip tests,
but I can package old Tomcat and run the tests. I don't need to update
that Tomcat or fix security issues as they are not exploitable in
buildroot - Tomcat runs in embedded mode, does not listen on the
network etc. Not something that I could with ursine Tomcat packages -
it would get delivered to users, and we have no control how they use
it - we would need to fix all important user-reported bugs and CVEs as
they are potentially exploitable.


So for this tomcat needed for testing problem, I'm thinking that we
might solve this in a very non Fedora way. Why not bundle the old
tomcat-sources with the sources which need it for their test-suite
(and build it before running the tests).

I realize that this is ugly; and if many packages need this old
tomcat it will not scale (but I hope that is not the case). Despite
those disadvantages I believe that this would be a good solution.

The reason why I'm thinking in this direction is as follows:
Like others, I'm very much against the notion of buildroot only
packages, esp. the side-tag idea is terrible as it makes rebuilding
the package from source very hard for end users. To me Fedora
would not be Fedora if users can easily rebuild their packages.

Bundling the old tomcat sources, so that the test-suite can run,
without that old tomcat ever getting installed on the users
system, to seems like a decent workaround for the issue of the
tests depending on this old tomcat.


Another, more concrete example: core Ant doesn't have any dependencies
beyond JDK. It is easy to build and maintain, yet very functional. On
the other hand, full Ant with all the optional tasks depends on more
than 200 Java packages. For the purpose of building all packages that
I am interested in, core Ant with JUnit tasks (total of 3 packages) is
sufficient. Functionalities of Ant like sending emails or image
processing are obviously not needed in this case. If building other
packages is the only use of Ant then it can be maintained much more
easily (3 instead of ~250 packages). But when Ant is ursine package in
Fedora then it should be the full Ant - we can't claim to deliver Ant
to users while it is just part of it. Eclipse in Fedora requires full
Ant too.


So if you say that you only need the minimal Ant, and I guess many
packages only need the minimal Ant to build, then why not have
an ant-minimal package, like we have a vim-minimal ?

Now I guess that vim-minimal and "proper" vim are both build from the
same source-rpm; and normally we never allow 2 srpms with the same
upstream sources in them. But I think that in this case we could make
an exemption where there is a separate pkg-git and srpm for an ant-minimal
which you would maintain.

And then the community / java-sig can maintain the full Ant as I believe
is already happening since we do have an ant packaged in Fedora 33 atm.

I hope that these 2 examples show that at least in some cases we
may be able to come up with creative solutions for the problems
involved in java packaging.

###

An other more generic approach which has been brought up once or
twice, but which not really has been discussed in much detail yet
I believe is creating a fedora-builddep repository.

ATM a normal user has 3 ursine Fedora repos installed:

fedora
fedora-updates
fedora-updates-testing (disabled by default)

What if we add a 4th repo called fedora-builddep:

fedora
fedora-updates
fedora-updates-testing (disabled by default)
fedora-builddep (rolling (within a release), disabled by default)

So the idea is that all the maven deps which you need, but
do not want to offer any end-user support on would go to
fedora-builddep.

Taking Fedora 33 as an example then:

1) The fedora-33-buildroot pkg-set would consist of fedora-33 + 

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Miro Hrončok]

Thank you for describing the entire story from your pov, I think it's very 
helpful!

On 11. 09. 20 9:34, Mikolaj Izdebski wrote:

I can't drop my
packages and move back to co-maintaining ursine packages as it would
mean losing 2 years of my work and the features I developed.


I guess there are two sides of this:

 - the lost features

Can you work together with the new Java maint SIG to have those features 
integrated in the nonmodular packages?


 - the lost years

While sad I believe that at a certain point, we need to be able to admit that 
the years are lost in order to save ourselves from loosing even more years. This 
is a very important aspect in accepting that modularity in Fedora was a failure. 
If we don't do this, we'll keep failing.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Thursday, September 10, 2020 10:38:51 PM MST Zbigniew Jędrzejewski-Szmek 
wrote:
> On Thu, Sep 10, 2020 at 06:37:56PM -0700, John M. Harris Jr wrote:
> 
> > On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek
> > 
 wrote:
> > 
> > > On Thu, Sep 10, 2020 at 01:27:30PM +0200, alcir...@posteo.net wrote:
> > > 
> > > 
> > > > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
> > > > 
> > > > 
> > > > > > 
> > > > > > These DNS addresses are bundled upstream in systemd. And they are
> > > > > > used
> > > > > > in the event of a misconfiguration of your network settings,
> > > > > > isn't
> > > > > > it?
> > > > > > However they are easily customizable in
> > > > > > /etc/systemd/resolved.conf
> > > > > > (FallbackDNS option)
> > > > > 
> > > > > 
> > > > > 
> > > > > It's about the distribution's default setting, not a configuration
> > > > > possibility.
> > > > 
> > > > 
> > > > 
> > > > "Which servers are used (or any at all) as a fallback is a
> > > > compile-time
> > > > as well as a runtime option. If you don't like the upstream defaults,
> > > > then please work with downstream to pick different options or make
> > > > the
> > > > choices locally in your configuration files."
> > > > 
> > > > As a concerned user, you can configure the FallbackDNS option in
> > > > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google
> > > > and
> > > > so on will never be contacted.
> > > > 
> > > > Obviously the distribution can put different DNS in systemd at
> > > > compile
> > > > time, or provide a default resolved.conf file where FallbackDNS is
> > > > uncommented and filled.
> > > 
> > > 
> > > 
> > > Exactly. With my maintainer hat on: this is a non-issue. We consider
> > > current defaults (a working fallback configuration out of the box that
> > > has a very minor information leak) better than the proposed (a
> > > non-working
> > > fallback configuration). If you need to, provide the trivial two-line
> > > dropin file to override this locally.
> > 
> > 
> > Zbyszek,
> > 
> > I'm definitely not suggesting something that is "non-working". That said,
> > not  having any DNS servers configured indicates that remote lookup
> > should not be used, not that a random DNS server should be picked by the
> > resolver itself. When there are no DNS servers, the expected behavior is
> > that no external servers are used for lookup.
> 
> 
> There are no environments where remote lookup SHOULD NOT not be used. There
> are remote environments where it MUST NOT be used, and environments where
> it is expected to work. For the former, just emptying /etc/resolv.conf is a
> halfway measure that doesn't do enough so strong filtering with namespaces
> or routing must be provided anyway. In the second case, we want to have
> working networking (even if your local crappy dns router forgets to attach
> a dns server to the dhcp lease or such).

When you have no configured DNS servers, remote lookup SHOULD NOT be used. 
Only local domain resolution should be used. This is how it has been for 
decades, and there's no reason to change this. That's expected functionality.

We have working networking even without DNS. If there are no DNS servers 
configured, no remote DNS servers should ever be contacted by the resolver.

-- 
John M. Harris, Jr.

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

Re: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Thursday, September 10, 2020 11:56:25 PM MST alcir...@posteo.net wrote:
> On Thu, 2020-09-10 at 18:33 -0700, John M. Harris Jr wrote:
> 
> > 
> > Why in the world would systemd have anything to do with NTP? We still
> > use 
> 
> 
> It has to do with NTP in the same degree it has to do with DNS.
> Sure, we use chronyd. But, if I'm not wrong, if a user disables chronyd
> and enable systemd-timesyncd, without configuring any NTP server,
> systemd by default would fall back to Google NTP servers. But systemd
> in Fedora is built to use 
> FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
> 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org

Sounds like a good change, which should be made for DNS as well. Still, the 
major difference here is that F33 is ditching the existing resolver for 
systemd's, so it'd be best to get it set up before shipping it..

-- 
John M. Harris, Jr.

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

Re: The Future of the Java Stack (also regarding ELN and RHEL)

[Tomasz Torcz]

On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> You get a side tag in Koji where you can have private build-only
> dependencies that are discarded (filtered) once they are no longer
> needed, after module build is done. For build-only packages most of
> security vulnerabilities are not exploitable easily, or at all,
> therefore are low-severity, which greatly limits maintenance work
> required to address them. For example, if upstream tests are ran on an
> obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> but I can package old Tomcat and run the tests.

  Whoha! Let's step back for a minute and look at this example.
What are the reasons to run tests?  To make sure the package will run
correctly..
Why run tests on 12-years old version instead of on current one?
Probably because tests fail on current version?

  Will the end user run the package on obsolete Tomcat or on the current one?
Of course on the current one. The one on which tests fail.
Tests in this case are worthless, they are not testing the real
situation. Disabling tests is no worse than testing on obsolete version.
Relying on such tests is a disservice for the end user.

  The point of testing is to validate code in real situation. 
Crafting special, unrealistic environment (12 years old Tomcat) just to have
test pass is missing the point of tests.

-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
___
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 Future of the Java Stack (also regarding ELN and RHEL)

[Mikolaj Izdebski]

On Fri, Sep 11, 2020 at 8:44 AM Petr Pisar  wrote:
>
> On Thu, Sep 10, 2020 at 09:59:05PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > For Maven packaging the appeal of Modularity is clearly the privatization of
> > the dependency tree, which obviously undercuts the ecosystem of packages.
> >
> You are right that bundling is one of the features of Modularity and that this
> freedom undermines an integration effort on the Fedora distribution level.
>
> But bundling is not the only appeal for Maven maintainers. If I can speek for
> Mikolaj, then another appeal is sharing a module among multiple Fedora
> releases. Because byte-compiled Java code is portable, it is possible to build
> a module on Fedora 31 and have the same module build available on Fedora 34.
> This saves the module maintainers from the burden of rebuilding the Java
> packages for each Fedora and Modularity is the first place that actuallty can
> leverage this Java feature.

Right. Building modules once and shipping the same packages to all
releases used to be important to me, but since then I developed a new
way of bootstrapping Maven (MBI - Maven Bootstrap Initiative) so that
now I can build Maven in a reliable, reproducible way. That modularity
feature is therefore no longer important to me.

--
Mikolaj
___
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: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Kamil Paral]

On Thu, Sep 10, 2020 at 5:54 PM Michael Catanzaro 
wrote:

> On Thu, Sep 10, 2020 at 9:36 am, Kamil Paral  wrote:
> > On Thu, Sep 10, 2020 at 8:54 AM Mikhail Gavrilov
> >  wrote:
> >> # authselect apply-changes
> >>  [error] [/etc/authselect/nsswitch.conf] has unexpected content!
> >>  [error] Unexpected changes to the configuration were detected.
> >>  [error] Refusing to activate profile unless those changes are
> >> removed or overwrite is requested.
> >>  Some unexpected changes to the configuration were detected. Use
> >> 'select' command instead.
> >
> > I see the same error.
>
> I'm a bit concerned that two different people are seeing this. I don't
> think we have any scriptlets tha writes to /etc/nsswitch.conf or
> /etc/authselect/nsswitch.conf on its own. But maybe, for non-live
> installs, that could happen if the systemd RPM gets installed before
> the authselect RPM? Then systemd would think /etc/nsswitch.conf is not
> managed by authselect. Hm
>
> Anyway, if you can find a way to get to this state from a clean
> install, without touching those files manually, then please do report a
> bug. That shouldn't be happening.
>

I did edit /etc/nsswitch.conf manually, because obviously I needed a
working system :) The confusing part here is that the error message claims
that **/etc/authselect/nsswitch.conf** has unexpected content. So this
doesn't seem to be related to /etc/nsswitch.conf having been edited by
hand. Is it? If it is, what is the proper way to revert back to upstream
defaults in this case? Should I append "--force" to the command? (I don't
want to destroy my system, that's why I'm not simply trying it. All of this
seems awfully complex and fragile).
___
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 Future of the Java Stack (also regarding ELN and RHEL)

[Mikolaj Izdebski]

On Thu, Sep 10, 2020 at 9:59 PM Matthew Miller  wrote:
>
> On Thu, Sep 10, 2020 at 01:50:55PM +0100, Joe Orton wrote:
> > maintain the non-modular packages.  We are not going to promise to
> > commit time and resources to maintain the non-modular packages.
>
> Joe, here's a part I hope you can help me understand better. Modularity
> isn't an entirely new packaging technology. It's simply a layer on top of
> RPM. Modules are made out of RPMs, and by design, their specfiles are
> exactly the same as RPMs which happen to be grouped into modules.

Modularity provides not only a different way of grouping or delivering
RPM packages, but most importantly, a different way of building RPM
packages.

You get a side tag in Koji where you can have private build-only
dependencies that are discarded (filtered) once they are no longer
needed, after module build is done. For build-only packages most of
security vulnerabilities are not exploitable easily, or at all,
therefore are low-severity, which greatly limits maintenance work
required to address them. For example, if upstream tests are ran on an
obsolete, 12-years old version of Tomcat, I don't need to skip tests,
but I can package old Tomcat and run the tests. I don't need to update
that Tomcat or fix security issues as they are not exploitable in
buildroot - Tomcat runs in embedded mode, does not listen on the
network etc. Not something that I could with ursine Tomcat packages -
it would get delivered to users, and we have no control how they use
it - we would need to fix all important user-reported bugs and CVEs as
they are potentially exploitable.

Modularity also introduced the concept of API packages - non-API
packages can have limited usability, with some non-important features
removed. For example if all I need is a small part of Tomcat, I can
reduce tomcat package to build just the tiny parts that I need, which
don't have any dependencies. Again, not something I could do with
ursine Tomcat package.

Another, more concrete example: core Ant doesn't have any dependencies
beyond JDK. It is easy to build and maintain, yet very functional. On
the other hand, full Ant with all the optional tasks depends on more
than 200 Java packages. For the purpose of building all packages that
I am interested in, core Ant with JUnit tasks (total of 3 packages) is
sufficient. Functionalities of Ant like sending emails or image
processing are obviously not needed in this case. If building other
packages is the only use of Ant then it can be maintained much more
easily (3 instead of ~250 packages). But when Ant is ursine package in
Fedora then it should be the full Ant - we can't claim to deliver Ant
to users while it is just part of it. Eclipse in Fedora requires full
Ant too.

> I understand that it's nice to have exactly one workflow, but it doesn't
> seem like it's actually all that much extra effort on top of what you
> already have to do to maintain the module to make a non-modular build. Is
> this something where triggering the non-modular builds in the same way you
> build the module would make a difference?

It's not about the workflow, it is about reducing package maintenance
work that is required. Modularity allows us to greatly reduce the
number of packages by patching-out non-API packages to remove unneeded
features and it allows us to spend less time on fixing bugs in
packages that are used merely as build dependencies and which we don't
intend to be used by end users.

>
> Or is there something else that I'm not seeing?
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

[Florian Weimer]

* Tom Hughes via devel:

> On 11/09/2020 07:13, Ondrej Dubaj wrote:
>
>> There seemed to be no big reason for moving the libraries to the
>> main package in the past, so I consider f34 as a good candidate for
>> such a change. It would be great, if  you share your opinions and
>> concerns for this topic.
>
> Tom Lane has explained the reason on the ticket, it's because the
> library is often dlopened by a client application instead of being
> linked to.

Yes, that is sufficient reason not to do the move.  Third-party
applications will break.  Some people also really dislike installing
*-devel packages in production, so there might not be an easy fix for
them.

The library probably should not have a versioned soname in the first
place, with backwards compatibility achieved by different means.  But
that does not matter now.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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 Future of the Java Stack (also regarding ELN and RHEL)

[Mikolaj Izdebski]

On Fri, Sep 11, 2020 at 12:32 AM Zbigniew Jędrzejewski-Szmek
 wrote:
> This exchange summarizes the situation nicely.
>
> Modularity can be considered an over-complicated hyped-through-the-roof
> bundling mechanism.
>
> For a long time Fedora has very strongly discouraged bundling in the sense of
> subsumming one package into another to have a custom build of a dependency.
>
> The disapproval of bundling is not because it doesn't work: it does, and in
> fact with some crappy libraries it's the least bad solution. The disapproval
> is motivated by the fact that bundling doesn't scale and that it subtracts 
> from
> the ecosystem. Instead of us all cooperating and each bugfix helping all
> users of a given dependency, a maintainer of a bundled library is only helping
> themselves and their package.
>
> Bundling is not inherently bad: currently the policy even allows it as
> a workaround if using the system-wide package is not feasible. It is a
> pragmatic choice to allow it as a last resort. But the effect of bundling
> on other packages must be minimized any conflicts or confusion with the
> system version avoided.
>
> With Modularity, we threw this accumulated wisdom away.
> In two ways: by encouraging private^Wbuild-only dependencies and by
> letting bundled^Wmodularized rpms shadow normal rpms.
>
> For Maven packaging the appeal of Modularity is clearly the privatization of
> the dependency tree, which obviously undercuts the ecosystem of packages.
>
> The Java ecosystem collapsed so quickly because it was already weak
> — hundreds of packages on the shoulders of one person. But even in a stronger
> ecosystem, with enough packages modularized, the packaging ecosystem of
> mutual cooperation would collapse.
>
> For some other modules, the appeal is the overriding of package deps, which
> means that the modular rpms don't have to worry about getting it deps 
> precisely
> declared, at the cost of breaking the deps declared in other packages.
>
> If there wasn't Modularity and instead Maven would bundle it's deps into
> one huge srpm, the effect on the ecosystem would be the same. As with
> bundling, Modularization gives short-term relief at a very high long-term
> cost. We should avoid modularization like we avoid bundling.

You summarized it really well, thanks Zbyszek. To me bundling is,
and always was, an important design feature of modularity.
There are other important aspects of it, but I dare to say that from my
PoV its form of bundling is the most important feature.

I wanted to expand on your story, present my version of the same story.

For a long time we (Java maintenance team at Red Hat) were maintaining
Fedora packages without any form of bundling because it was considered
harmful and was not allowed in any way, not without explicit exception.

Over time the number of contributors to Java packaging (number of active
Java SIG members) was decreasing, most of Java maintainers were gone,
or "unresponsive".  Making changes to our packages, like improving
packaging automation, required testing and possibly adjusting
thousands of others' packages, most of which were largely unmaintained.
Unresponsive maintainer processes would not work as it would require us
to take maintenance of orphaned packages, which we could not afford.

In the meantime our Java maintenance team was shrunk from 4 people
down to just one person, me.  I had to severely limit the time I spent
on Fedora due to other commitments - I had to spend more time on RHEL
work and other side projects, like Koschei, that I was responsible
for.  I could not afford to spend my free after-work time on Fedora
due to personal reasons (I got married, started building a house etc.)
Combined with the collapse of Java SIG, the situation was difficult.

Then a new, sophisticated way of bundling, called modularization, was
designed and came to my help. This way of bundling was no only
considered not harmful, but also approved and even made as a Fedora
objective. Since it solved the biggest issues I had with packaging, I
became a very eager early adopter and quickly built everything as
modules.

I was still maintaining non-modular packages, but I hoped that one day
non-modular packages would be completely replaced by modules.  When
modules were added to Fedora proper, I made them default streams and
waited for a solution like Ursa-Major that would allow me to retire
ursine packages, replacing them with modular packages.

RHEL enabled Ursa-Major. My javapackages-tools module was the first
ones to make use of it in RHEL and we succeeded to retire all ursine
packages in RHEL. When Fedora finally rejected Ursa-Major, I was very
frustrated as I perceived it as begin of collapse of modularity, the
great feature that promised to solve the problems I had with
packaging. I could not easily move back to ursine packages and I was
already committed to maintaining modules in RHEL, so I decided to live
with Fedora decision and orphan almost all of my ursine packages.

Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

[Ondrej Dubaj]

On Fri, Sep 11, 2020 at 9:15 AM Lukas Javorsky  wrote:

> From my point of view, it's a good idea to move them into the *-devel
> package.
>
> It's more effective and ordered for future development.
> Because if someone only needs a few libraries, they don't have to require
> the whole main package and can just require a devel package, which is the
> way we want it as far as I know.
>

That is not the case we are aiming for, as unixODBC-devel requires
unixODBC, so the devel package will pull the main package as a dependency
during installation. The aim is that the main package should not contain
the unversioned shared libraries, as they are supposed to be used during
development and not dynamic linking. But there might be a problem if client
applications dynamically load the unversioned libraries, are they actually
able to dlopen the versioned ones ? Even if using some kind of config file
to specify the version of the shared library?

Thanks,

Ondrej

>
> Lukas
>
> On Fri, Sep 11, 2020 at 8:14 AM Ondrej Dubaj  wrote:
>
>> Hello everyone,
>>
>> I would like to start a discussion about moving unversioned *.so files
>> back to unixODBC-devel package, as they are currently in the main package.
>> The reason for this discussion is primary have things in order according to
>> future rhel-9.
>>
>> There will potentially be a change of moving 5 files {libodbc.so
>> libodbcinst.so libodbcpsqlS.so libodbcmyS.so libtdsS.so} to devel
>> package, so from the maintainers/users perspective, dependent packages will
>> have to require also the devel package and should be rebuild as well. No
>> other changes will be made.
>>
>> There seemed to be no big reason for moving the libraries to the main
>> package in the past, so I consider f34 as a good candidate for such a
>> change. It would be great, if  you share your opinions and concerns for
>> this topic.
>>
>> Sharing also the official documentation [1], tracker in bugzilla [2] and
>> upcoming changes in unixODBC package [3]
>>
>> Thanks!
>>
>> Ondrej
>>
>> [1]
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1877720
>> [3]
>> https://src.fedoraproject.org/fork/odubaj/rpms/unixODBC/c/7ecddca7cfcc4e014bf65085dd9547f1c5981138
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
> S pozdravom/ Best regards
>
> Lukas Javorsky
>
> Intern, Core service - Databases
>
> Red Hat 
>
> Purkyňova 115 (TPB-C)
>
> 612 00 Brno - Královo Pole
>
> ljavo...@redhat.com
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

[Lukas Javorsky]

>From my point of view, it's a good idea to move them into the *-devel
package.

It's more effective and ordered for future development.
Because if someone only needs a few libraries, they don't have to require
the whole main package and can just require a devel package, which is the
way we want it as far as I know.

Lukas

On Fri, Sep 11, 2020 at 8:14 AM Ondrej Dubaj  wrote:

> Hello everyone,
>
> I would like to start a discussion about moving unversioned *.so files
> back to unixODBC-devel package, as they are currently in the main package.
> The reason for this discussion is primary have things in order according to
> future rhel-9.
>
> There will potentially be a change of moving 5 files {libodbc.so
> libodbcinst.so libodbcpsqlS.so libodbcmyS.so libtdsS.so} to devel
> package, so from the maintainers/users perspective, dependent packages will
> have to require also the devel package and should be rebuild as well. No
> other changes will be made.
>
> There seemed to be no big reason for moving the libraries to the main
> package in the past, so I consider f34 as a good candidate for such a
> change. It would be great, if  you share your opinions and concerns for
> this topic.
>
> Sharing also the official documentation [1], tracker in bugzilla [2] and
> upcoming changes in unixODBC package [3]
>
> Thanks!
>
> Ondrej
>
> [1]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1877720
> [3]
> https://src.fedoraproject.org/fork/odubaj/rpms/unixODBC/c/7ecddca7cfcc4e014bf65085dd9547f1c5981138
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
S pozdravom/ Best regards

Lukas Javorsky

Intern, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

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

Re: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[alciregi]

On Thu, 2020-09-10 at 18:33 -0700, John M. Harris Jr wrote:
> 
> Why in the world would systemd have anything to do with NTP? We still
> use 

It has to do with NTP in the same degree it has to do with DNS.
Sure, we use chronyd. But, if I'm not wrong, if a user disables chronyd
and enable systemd-timesyncd, without configuring any NTP server,
systemd by default would fall back to Google NTP servers. But systemd
in Fedora is built to use 
FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
2.fedora.pool.ntp.org 3.fedora.pool.ntp.org


Ciao,
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: The Future of the Java Stack (also regarding ELN and RHEL)

[Petr Pisar]

On Thu, Sep 10, 2020 at 09:59:05PM +, Zbigniew Jędrzejewski-Szmek wrote:
> For Maven packaging the appeal of Modularity is clearly the privatization of
> the dependency tree, which obviously undercuts the ecosystem of packages.
> 
You are right that bundling is one of the features of Modularity and that this
freedom undermines an integration effort on the Fedora distribution level.

But bundling is not the only appeal for Maven maintainers. If I can speek for
Mikolaj, then another appeal is sharing a module among multiple Fedora
releases. Because byte-compiled Java code is portable, it is possible to build
a module on Fedora 31 and have the same module build available on Fedora 34.
This saves the module maintainers from the burden of rebuilding the Java
packages for each Fedora and Modularity is the first place that actuallty can
leverage this Java feature.

> If there wasn't Modularity and instead Maven would bundle it's deps into
> one huge srpm, the effect on the ecosystem would be the same.

Not really. Modules are collections of packages and various modules can share
the sources of the same packages. That means that Modularity does not prevent
from sharing a maintenance cost of the packages. It only makes it more
difficult, because of worse discoverbility and a wider selection of the
choice.

> Modularization gives short-term relief at a very high long-term
> cost. We should avoid modularization like we avoid bundling.

Sarcasm: I really like how other one people order other ones that they have to
maintain the packages for them.

-- Petr


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

Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

[Tom Hughes via devel]

On 11/09/2020 07:13, Ondrej Dubaj wrote:

There seemed to be no big reason for moving the libraries to the main 
package in the past, so I consider f34 as a good candidate for such a 
change. It would be great, if  you share your opinions and concerns for 
this topic.


Tom Lane has explained the reason on the ticket, it's because the
library is often dlopened by a client application instead of being
linked to.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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

Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

[Ondrej Dubaj]

Hello everyone,

I would like to start a discussion about moving unversioned *.so files back
to unixODBC-devel package, as they are currently in the main package. The
reason for this discussion is primary have things in order according to
future rhel-9.

There will potentially be a change of moving 5 files {libodbc.so
libodbcinst.so libodbcpsqlS.so libodbcmyS.so libtdsS.so} to devel package,
so from the maintainers/users perspective, dependent packages will have to
require also the devel package and should be rebuild as well. No other
changes will be made.

There seemed to be no big reason for moving the libraries to the main
package in the past, so I consider f34 as a good candidate for such a
change. It would be great, if  you share your opinions and concerns for
this topic.

Sharing also the official documentation [1], tracker in bugzilla [2] and
upcoming changes in unixODBC package [3]

Thanks!

Ondrej

[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1877720
[3]
https://src.fedoraproject.org/fork/odubaj/rpms/unixODBC/c/7ecddca7cfcc4e014bf65085dd9547f1c5981138
___
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