Re: Review swap: wlr-sunclock - Show the sun's shadows on earth (for wayland)

[Bob Hepple]

Thanks Carson,

I'm up for that ...

See you in bugzilla ...


Cheers


Bob

On Mon, 17 Aug 2020 at 13:01, Carson Black  wrote:
>
> Ello,
>
> The review process is documented on the wiki here:
> https://fedoraproject.org/wiki/Package_Review_Process
> In short, set the fedora-review flag on the bug to ? when you're
> reviewing a package. When you approve a package, change the flag to +.
>
> I'll take this review swap. In return, I'd appreciate it if you
> reviewed https://bugzilla.redhat.com/show_bug.cgi?id=1869128, which is
> also a fairly straightforward package using meson.
>
> Thanks,
>
> -- Carson Black [ jan Pontajosi ]
>
>
> Am So., 16. Aug. 2020 um 21:16 Uhr schrieb Bob Hepple :
> >
> > Hi,
> >
> > I'm still not 100% sure that I'm able to approve a package - I have
> > "Fedora Packager GIT Commit Group (packager)", I've been through
> > sponsorship and I've had packages approved and released. If someone
> > can point out the doco on this point, I'd be grateful as my searches
> > haven't come up with anything yet.
> >
> > I'm willing to try a review swap for a simple package - I'm still new to 
> > this.
> >
> > This one has been open for 10 days, It's a simple meson package but
> > rather fun for the desktop:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1867267
> >
> >
> > Thanks
> >
> >
> > Bob
> > ___
> > 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
___
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: Strange Java package build failures (Error in scriptlet ?)

[Ondrej Dubaj]

On Fri, Aug 14, 2020 at 7:07 PM Fabio Valentini 
wrote:

> Hi everybody,
>
> Since ~2 days ago, the rawhide koji buildroot has exhibited some
> *really weird* issues when building Java packages with maven (when
> building packages locally with "mock -r fedora-rawhide-x86_64
> --enablerepo local foo.src.rpm").
>
> During installation of the build dependencies, some random (?) Java
> package will have a scriptlet failure like this: "Error in 
> scriptlet in rpm package mockito" (the package that this error occurs
> in is not always the same). This is always the last scriptlet run
> before the "Verifying" stage of "dnf install".
>
> Then, later, during execution of %build, the following errors show up,
> which make the it fail:


> /usr/share/maven/bin/mvn: Failed to set JAVACMD
> The JAVA_HOME environment variable is not defined correctly
> This environment variable is needed to run this program
> NB: JAVA_HOME should point to a JDK not a JRE
>

Experiencing the same problem. Haven;t found any usefull info about this

>
> Sometimes, scrubbing the mock buildroot makes the next build succeed,
> sometimes it doesn't. I tried entering the buildroot with "mock shell"
> but it didn't yield any useful information.
>
> I see that the scripts setting up JAVA_HOME etc. try to find a java +
> javac executable, but they're all there, and the alternatives setup
> also looks sane (no broken links in /etc/alternatives).
>
> The only Java related updates I see in the buildroot for the "critical
> time frame" are builds of java-11-openjdk, but I'm not sure how they
> could have introduced such inconsistently buggy buildroot behaviour :(
>
> Does anybody have an idea what might be the problem here? It's really
> annoying to be unable to build Java packages locally most of the time
> (curiously, I haven't seen this issue happen in any koji builds yet).
>
> 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
>
___
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

announcing libkolabxml soname bump in rawhide

[Timotheus Pokorra]

Hi all,

I will be updating libkolabxml from 1.1.6 to 1.2.0 in Rawhide in 7 days.

The only dependency is kdepim, as far as I can see.

Let me know in the bug
https://bugzilla.redhat.com/show_bug.cgi?id=1869138 if you see any issues.

I have already committed the change in git, but not built the package
for real yet.
https://src.fedoraproject.org/rpms/libkolabxml/c/811cd080af9d2255f7492917f72446f2a7a8de4f?branch=master


All the best,
  Timotheus
___
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: Review swap: wlr-sunclock - Show the sun's shadows on earth (for wayland)

[Carson Black]

Ello,

The review process is documented on the wiki here:
https://fedoraproject.org/wiki/Package_Review_Process
In short, set the fedora-review flag on the bug to ? when you're
reviewing a package. When you approve a package, change the flag to +.

I'll take this review swap. In return, I'd appreciate it if you
reviewed https://bugzilla.redhat.com/show_bug.cgi?id=1869128, which is
also a fairly straightforward package using meson.

Thanks,

-- Carson Black [ jan Pontajosi ]


Am So., 16. Aug. 2020 um 21:16 Uhr schrieb Bob Hepple :
>
> Hi,
>
> I'm still not 100% sure that I'm able to approve a package - I have
> "Fedora Packager GIT Commit Group (packager)", I've been through
> sponsorship and I've had packages approved and released. If someone
> can point out the doco on this point, I'd be grateful as my searches
> haven't come up with anything yet.
>
> I'm willing to try a review swap for a simple package - I'm still new to this.
>
> This one has been open for 10 days, It's a simple meson package but
> rather fun for the desktop:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1867267
>
>
> Thanks
>
>
> Bob
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1869060] perl-Test-Fake-HTTPD-0.09 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

Review swap: wlr-sunclock - Show the sun's shadows on earth (for wayland)

[Bob Hepple]

Hi,

I'm still not 100% sure that I'm able to approve a package - I have
"Fedora Packager GIT Commit Group (packager)", I've been through
sponsorship and I've had packages approved and released. If someone
can point out the doco on this point, I'd be grateful as my searches
haven't come up with anything yet.

I'm willing to try a review swap for a simple package - I'm still new to this.

This one has been open for 10 days, It's a simple meson package but
rather fun for the desktop:

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


Thanks


Bob
___
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: Buildroot overrides in branched pre updates-testing activation?

[Mamoru TASAKA]

Fabio Valentini wrote on 2020/08/16 23:24:

Hi everybody,

I've just noticed that bodhi allows users to create buildroot
overrides for F33 for no good reason (updates-testing is not even
active yet and updates to to stable directly). There's 41 (!) active
overrides for F33:

https://bodhi.fedoraproject.org/overrides/?search=&expired=False&releases=F33

Doesn't this screw up the builds in koji? Why does bodhi allow
creating overrides for branched pre-updates-testing activation?

Fabio



Note that f33 buildroot was frozen until first successful compose was
created.
https://pagure.io/fedora-infrastructure/issue/9224
https://fedoraproject.org/wiki/Changes/Freeze_after_branching_until_compose_is_ready

So until f33 buildroot freeze gets over, the only way to do chain-build is
to request side-tag or request override tag.

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

Fedora 33 compose report: 20200816.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-33-20200815.n.0
NEW: Fedora-33-20200816.n.0

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

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

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

= ADDED IMAGES =
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20200816.n.0.ppc64le.raw.xz
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20200816.n.0.ppc64le.vmdk
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20200816.n.0.ppc64le.qcow2

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  apache-commons-lang-2.6-32.fc33
Old package:  apache-commons-lang-2.6-31.fc33
Summary:  Provides a host of helper utilities for the java.lang API
RPMs: apache-commons-lang apache-commons-lang-javadoc
Size: 898.28 KiB
Size change:  268.81 KiB
Changelog:
  * Sat Aug 15 2020 Fabio Valentini  - 2.6-32
  - Remove unused org.apache.commons.lang.enum package.
  - Compile with Java 11, target Java 8 (instead of Java 8 targeting Java 3).
  - Remove stray encoding issues, convert to UTF-8.


Package:  blaze-3.8-1.fc33
Old package:  blaze-3.7-3.fc33
Summary:  An high-performance C++ math library for dense and sparse 
arithmetic
RPMs: blaze-devel
Size: 7.16 MiB
Size change:  155.67 KiB
Changelog:
  * Sat Aug 15 2020 Patrick Diehl   - 3.8-1
  - Update to Blaze 3.8


Package:  byte-buddy-1.10.14-1.fc33
Old package:  byte-buddy-1.9.5-9.fc33
Summary:  Runtime code generation for the Java virtual machine
RPMs: byte-buddy byte-buddy-agent byte-buddy-javadoc 
byte-buddy-maven-plugin byte-buddy-parent
Size: 6.39 MiB
Size change:  653.82 KiB
Changelog:
  * Fri Aug 14 2020 Jerry James  - 1.10.14-1
  - Version 1.10.14
  - Remove no longer needed no-unixsocket.patch
  - Add workaround for compiling tests with JDK 11


Package:  caja-extensions-1.24.1-1.fc33
Old package:  caja-extensions-1.24.0-4.fc33
Summary:  Set of extensions for caja file manager
RPMs: caja-beesu caja-extensions-common caja-image-converter 
caja-open-terminal caja-sendto caja-sendto-devel caja-share caja-wallpaper 
caja-xattr-tags
Size: 1.24 MiB
Size change:  14.49 KiB
Changelog:
  * Sun Aug 16 2020 Wolfgang Ulbrich  - 1.24.1-1
  - update to 1.24.1


Package:  ccache-3.7.11-1.fc33
Old package:  ccache-3.7.9-4.fc33
Summary:  C/C++ compiler cache
RPMs: ccache
Size: 1.10 MiB
Size change:  8.06 KiB
Changelog:
  * Sat Aug 15 2020 Orion Poplawski  - 3.7.11-1
  - Update to 3.7.11


Package:  dyninst-10.1.0-10.fc33
Old package:  dyninst-10.1.0-7.fc33
Summary:  An API for Run-time Code Generation
RPMs: dyninst dyninst-devel dyninst-doc dyninst-testsuite
Size: 33.81 MiB
Size change:  -2.48 MiB
Changelog:
  * Mon Jul 27 2020 Fedora Release Engineering  - 
10.1.0-8
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

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

  * Mon Aug 10 2020 Orion Poplawski  - 10.1.0-10
  - Use new cmake macros (FTBFS bz#1863463)
  - Add BR tex-latex for doc build


Package:  eclipse-cdt-2:9.11.1-8.fc33
Old package:  eclipse-cdt-2:9.11.1-7.fc33
Summary:  Eclipse C/C++ Development Tools (CDT) plugin
RPMs: eclipse-cdt eclipse-cdt-arduino eclipse-cdt-llvm 
eclipse-cdt-native eclipse-cdt-qt eclipse-cdt-sdk eclipse-cdt-terminal
Size: 590.14 MiB
Size change:  -21.68 KiB
Changelog:
  * Sun Aug 16 2020 Mat Booth  - 2:9.11.1-8
  - Add missing obsoletes for tm-terminal-rse


Package:  eclipse-ecf-3.14.8-5.fc33
Old package:  eclipse-ecf-3.14.8-4.fc33
Summary:  Eclipse Communication Framework (ECF) Eclipse plug-in
RPMs: eclipse-ecf-core eclipse-ecf-runtime eclipse-ecf-sdk
Size: 8.45 MiB
Size change:  6.15 KiB
Changelog:
  * Sun Aug 16 2020 Mat Booth  - 3.14.8-5
  - Fix build against ASM 8


Package:  eclipse-pydev-1:7.7.0-1.fc33
Old package:  eclipse-pydev-1:7.6.0-3.fc33
Summary:  Eclipse Python development plug-in
RPMs: eclipse-pydev
Size: 25.88 MiB
Size change:  132.80 KiB
Changelog:
  * Fri Aug 14 2020 Mat Booth  - 1:7.7.0-1
  - Update to latest upstream release


Package:  fasterxml-oss-parent-40-1.fc33
Old package:  fasterxml-oss-parent-38-4.fc33
Summary:  FasterXML parent pom
RPMs: fasterxml-oss-parent
Size: 17.93 KiB
Size change:  -87 B
Changelog:
  * Mon Aug 10 2020 Fabio Valentini  - 40-1
  - Update to version 40.


Package:  golang-github-docker-distribution-2.7.1-5.20200815git35b26de.fc33

Re: Buildroot overrides in branched pre updates-testing activation?

[Mohan Boddu]

Seems like an issue with bodhi during when we enabled gating on f33
and we enabled autosigning on f33.

For now I manually untagged them, which should fix with buildroot being wrong.

On Sun, Aug 16, 2020 at 10:24 AM Fabio Valentini  wrote:
>
> Hi everybody,
>
> I've just noticed that bodhi allows users to create buildroot
> overrides for F33 for no good reason (updates-testing is not even
> active yet and updates to to stable directly). There's 41 (!) active
> overrides for F33:
>
> https://bodhi.fedoraproject.org/overrides/?search=&expired=False&releases=F33
>
> Doesn't this screw up the builds in koji? Why does bodhi allow
> creating overrides for branched pre-updates-testing activation?
>
> 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
___
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: Proposed Modular Policy for Fedora ELN

[James Szinger]

On Thu, 6 Aug 2020 16:45:15 +0200
Miro Hrončok  wrote:

> Fedora has experimented with default modular streams for several
> releases and we seemed to be at an agreement that the experiment has
> failed:
> 
> See https://pagure.io/fesco/issue/2406 which includes links to
> relevant previous discussions on the topic. Admitting that default
> modular streams are bad took as nearly two years, despite a few loud
> and persistent individuals pointing it out since the beginning.
> 
> While I understand the original idea behind the concept of default
> modular streams concept, shipping defaults via non-modular content
> has been proven superior to default modular streams -- it has been
> proven that default modular streams cannot be better than nonmodular
> defaults and that they can only try to be as good as them, while they
> are currently technologically failing to do that:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D2LQ6C6FHDS2LMKPDGCLFJDNHAPA6Q2B/

I agree.

> The currently proposed modularity objective for Fedora admits that
> this won't be fixed until ta least Fedora 35 and later:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RF4GUWFIDIASBDKS2RUVDHTSAWCMCWL4/
> 
> The current modularity tech-lead strongly discourages default modular
> streams:
> 
> https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310
> https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122502
> 
> 
> Yet despite all this, we got a proposal to allow default modular
> streams in ELN. The messaging about this proposal suggests that
> later, default modular streams might be proposed for Fedora as well.
> 
> 
> """At present, these rules will apply only to Fedora ELN, but are
> written in such a way as to be reusable for Fedora and EPEL in the
> future through another Change Proposal.""" --
> https://fedoraproject.org/wiki/Changes/ModularPolicy

This make the policy less clear than it needs to be.  It spends too
much time talking about non-ELN Fedora and not enough time getting
into the ELN specifics.

This wording also seems like a way to sneak in modularity through the
back door.  I know it explicitly says it isn't, but it still smells
bad.

If this experiment goes ahead and proves successful, then I expect
there will be lesson learned and the policy will be changed before it
is adopted for Fedora releases.  Surely, writing the policy for Fedora
in general can wait until after some ELN experience is gained.

> Fedora has decided that default modular streams are no-go. While I
> admit that such a decision can be reverted at any time based on
> significant changes in the technology, such changes have not happened
> and are not planned. Yet strong supporters of default modular streams
> try to allow them again and again, despite the enormous amount of
> feedback they've received including the feedback from the current
> modularity team and tech lead.

I do not recall any discussion from the modularity advocates of any
design level issues, nor of any proposals to address them.  I do not
believe that any changes in the technology are forthcoming.  Indeed
the need for such changes does not even seem to be acknowledged.

> I sincerely don't understand the RHEL's need for default modular
> streams, but when I tried to query the motivation behind this, the
> answers haven't made it any better:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YIUXL2AWY3GKITU4TBUSKL2IUHDUPB26/

I anticipate great consternation in the CentOS and EPEL user
communities when RHEL decides to change some default modules.  It is
my impression that modularity has caused problems for the CentOS and
EPEL developers:

These problems have delayed the delivery of CentOS 8 and EPEL 8 and
leave a poor impression of the quality of RHEL 8.  Maybe some RHEL
customers are wildly enthusiastic about modularity, but I don't see it
in the CentOS community.

> The idea that we let the maintainers decide how they want to ship the
> default content is exactly what failed in Fedora in the first place.
> But if RHEL people feel strongly that we need default modular steams
> to succeed, so be it. What I don't understand is why do we need this
> in Fedora (ELN). It boils down to this: Is ELN part of Fedora and
> should it follow Fedora's feedback and Fedora's opinions, or is it a
> RHEL project executed in the open, with decisions made behind closed
> doors?

+1.  From here ELN looks pretty closed.  So does modularity.

> I've heard several times that we need to have default modular streams
> in Fedora ELN to have a place to test them. In my opinion, we had
> this place, it was in Fedora, we have tested them and they failed.
> Hence I don't understand what's more there to test.

Many of the modularity problems manifest themselves at Fedora version
upgrades.  I do not see how de

Re: Proposed Modular Policy for Fedora ELN

[James Szinger]

On Wed, 5 Aug 2020 15:36:53 -0400
Stephen Gallagher  wrote:

> = Policies Regarding Modules in Fedora, Fedora ELN and EPEL

I find that all the discussion of non-ELN Fedora and EPEL distract
from the subject of ELN.  The proposal would be clearer if it
restricted itself to ELN and left non-ELN fedora for a separate
proposal.  I also have several questions that the proposal does not
address.

I believe that modularity has fundamental deep and hard design
problems.  My evidence for this is the several years of FESCO tickets.
Many of these tickets were not resolved or resolved only with hacks,
eventually compelling FESCO to restrict the scope of modularity.  I am
skeptical that these issues can be solved at the policy level.  Please
go back to the drawing board and don't push modularity at us until
they're fixed.

> == Requirements for All Module Streams
> * The module maintainer *MUST* have explicit commit privileges to all
> packages included in the module stream. The provenpackager privilege
> in Fedora is not sufficient.footnote:[This ensures that the package in
> the module is being maintained by someone responsible for it.]
> * Components built into a module *MUST* be associated with a reachable
> commit in Fedora dist-git.footnote:[There are legal and licensing
> requirements for reproducibility of builds.]
> * If a stream of a module has build-time-only components, all such
> components *MUST* be marked as `buildonly: True` in the module
> metadata to avoid shipping them to users and polluting their
> repository.

I think that build-only components are antithetical to Fedora's
"Friends" foundation.  It interferes with my ability to consume,
rebuild, and modify the affected packages.  I would like to see
build-only content forbidden except for well-defined situations.
This is especially important for default modules.

Proposal: Build-only content is forbidden in default modules and is
permitted in other modules only with FESCO exception if no other
solution is possible.


> == Requirements for Default Streams
> * Default streams are not permitted in Fedora or EPEL 8. Fedora ELN
> permits defaults streams that adhere to the policy below.

This is supposed to be a policy for ELN, yet this is the last time ELN
is mentioned.  I am unsure how the following is supposed to apply to
ELN.

> * All RPMs in default module streams are required to conform to the
> same
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/[requirements
> around Conflicts] as non-modular RPMs.
> * Packages provided at runtime by the default stream of a module
> *MUST* depend only on packages provided by packages from default
> module streams or the non-modular package set. By extension, default
> streams of a module *MUST NOT* have a dependency on any non-default
> stream.footnote:[It is highly recommended that default streams have no
> module dependencies besides the platform to avoid potential future
> conflicts during upgrades.]
> * Packages provided from default streams *MAY* depend on content from
> other default streams. If they do so, this dependency *MUST* be
> encoded in the module metadata.footnote:[This is so that if the
> maintainers of either module wishes to change its default stream, it
> is easy to see what other modules would be impacted and coordinate
> it.]
> * All packages provided at runtime by the default stream of a module
> *MUST* provide all the same functionality that a downstream consumer
> would expect from a package in the non-modular package
> set.footnote:[If a package is not filtered out from the default module
> stream, it is going to be part of the default-available content and
> therefore must be treated (and supported) just like a non-modular
> package.]

> * The default stream of a module *MUST NOT* change to a different
> stream within a released Fedora version.footnote:[This is an extension
> of the
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases[stable
> updates policy].] The default stream *MAY* be changed in Rawhide or
> during Fedora upgrades. Changes to default streams *MUST* be approved
> via a
> https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process[Fedora
> Change proposal].

And what about ELN? What standards apply to judging the change
proposal?

> * Packages *MAY* convert from a non-modular package to a modular
> default stream (or the reverse) only in Rawhide or during Fedora
> upgrades.

And what about ELN?  Will this also need a change proposal with FESCO
approval?

> * Default streams *MUST NOT* provide a binary RPM with the same
> package name as a non-modular RPM in the same release except in the
> case of a transition from one to the other.footnote:[Modular packages
> shadow non-modular ones. This rule ensures that we don't have any
> shadowed packages in the default package set.]
> * Default streams *MUST NOT* provide a binary RPM with the same
> package name as an RPM in a default stream in the sam

Buildroot overrides in branched pre updates-testing activation?

[Fabio Valentini]

Hi everybody,

I've just noticed that bodhi allows users to create buildroot
overrides for F33 for no good reason (updates-testing is not even
active yet and updates to to stable directly). There's 41 (!) active
overrides for F33:

https://bodhi.fedoraproject.org/overrides/?search=&expired=False&releases=F33

Doesn't this screw up the builds in koji? Why does bodhi allow
creating overrides for branched pre-updates-testing activation?

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: failed to do fedpkg import

[Fabio Valentini]

On Sun, Aug 16, 2020, 15:49 J. Scheuirich  wrote:

> $ fedpkg co wdune
> Cloning into 'wdune'...
> remote: Enumerating objects: 4992, done.
> remote: Counting objects: 100% (4992/4992), done.
> remote: Compressing objects: 100% (3647/3647), done.
> remote: Total 4992 (delta 1323), reused 4900 (delta 1277)
> Receiving objects: 100% (4992/4992), 200.94 MiB | 503.00 KiB/s, done.
> Resolving deltas: 100% (1323/1323), done.
> [mufti@localhost ~]$ fedpkg import
> /home/mufti/rpmbuild/SRPMS/wdune-1.940-3.fc34.src.rpm
> Removing no longer used file: Untitled3.wrl
> Failed to get ns from Git url or pushurl
> Failed to get repository name from Git url or pushurl
> Could not execute import_srpm: Unable to find remote branch.  Use --release
>
>
> What is wrong ?
>

Looks like you didn't run "cd wdune" before running "fedpkg import".

Also I'm not sure why you're running import again, when the package already
exists.

Fabio


>
> so long
>
> MUFTI
> ___
> 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

failed to do fedpkg import

[J. Scheuirich]

$ fedpkg co wdune
Cloning into 'wdune'...
remote: Enumerating objects: 4992, done.
remote: Counting objects: 100% (4992/4992), done.
remote: Compressing objects: 100% (3647/3647), done.
remote: Total 4992 (delta 1323), reused 4900 (delta 1277)
Receiving objects: 100% (4992/4992), 200.94 MiB | 503.00 KiB/s, done.
Resolving deltas: 100% (1323/1323), done.
[mufti@localhost ~]$ fedpkg import
/home/mufti/rpmbuild/SRPMS/wdune-1.940-3.fc34.src.rpm
Removing no longer used file: Untitled3.wrl
Failed to get ns from Git url or pushurl
Failed to get repository name from Git url or pushurl
Could not execute import_srpm: Unable to find remote branch.  Use --release


What is wrong ?


so long

MUFTI
___
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 real value of Release and %changelog metadata?

[Björn Persson]

Till Maas wrote:
> what about other special cases when using 0.1 for the release to
> indicate pre-releases or git IDs for snapshots. How would  that look
> like with your proposal?

None of that needs to change just because a buildtag is appended.

Whenever the source code changes in any way, one or more of the current
parts of the Version and Release fields should be updated. For a
rebuild, when the source code hasn't changed, the spec wouldn't need to
change either, and only the buildtag would set the rebuilt package
apart from the previous one.

Björn Persson


pgpKgVAI1YTSr.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 compose report: 20200816.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200814.n.1
NEW: Fedora-Rawhide-20200816.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  1
Dropped packages:54
Upgraded packages:   46
Downgraded packages: 0

Size of added packages:  2.56 MiB
Size of dropped packages:285.91 MiB
Size of upgraded packages:   1.33 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: nexus-4.4.3-6.fc34
Summary: Libraries and tools for the NeXus scientific data file format
RPMs:nexus nexus-devel nexus-tools
Size:2.56 MiB


= DROPPED PACKAGES =
Package: anchorman-0.0.1-17.fc32
Summary: The recording-studio-in-a-box
RPMs:anchorman
Size:110.47 KiB

Package: apache-commons-validator-1.5.0-10.fc32
Summary: Apache Commons Validator
RPMs:apache-commons-validator apache-commons-validator-javadoc
Size:312.44 KiB

Package: beacon-0.5-21.fc33
Summary: WYSIWYG editor for docbook xml
RPMs:beacon
Size:185.85 KiB

Package: ember-media-0.7.2.1-12.fc33
Summary: Media files for the ember WorldForge client
RPMs:ember-media
Size:240.23 MiB

Package: foo2zjs-0.20170412-14.fc33
Summary: Linux printer driver for ZjStream protocol
RPMs:foo2ddst foo2hbpl foo2hiperc foo2hp foo2lava foo2oak foo2qpdl foo2slx 
foo2xqx foo2zjs
Size:6.97 MiB

Package: gallery3-openid-2.0-0.15.beta.fc33
Summary: OpenID support for Gallery3
RPMs:gallery3-openid
Size:69.17 KiB

Package: gdb-heap-0.5-38.20191013gitf3dcc53.fc33
Summary: Extensions to gdb for debugging dynamic memory allocation
RPMs:gdb-heap
Size:217.88 KiB

Package: geronimo-ejb-1.0-24.fc32
Summary: Java EE: EJB API v3.1
RPMs:geronimo-ejb geronimo-ejb-javadoc
Size:131.59 KiB

Package: glassfish-jaxb-2.2.11-18.fc33
Summary: JAXB Reference Implementation
RPMs:glassfish-jaxb glassfish-jaxb-bom glassfish-jaxb-bom-ext 
glassfish-jaxb-codemodel glassfish-jaxb-codemodel-annotation-compiler 
glassfish-jaxb-codemodel-parent glassfish-jaxb-core 
glassfish-jaxb-external-parent glassfish-jaxb-javadoc glassfish-jaxb-jxc 
glassfish-jaxb-parent glassfish-jaxb-rngom glassfish-jaxb-runtime 
glassfish-jaxb-runtime-parent glassfish-jaxb-txw-parent glassfish-jaxb-txw2 
glassfish-jaxb-txwc2 glassfish-jaxb-xjc
Size:4.04 MiB

Package: glassfish-jaxb-api-2.3.3-1.fc33
Summary: Java Architecture for XML Binding
RPMs:glassfish-jaxb-api
Size:109.57 KiB

Package: gloobus-preview-0.4.1-39.fc32
Summary: A Gnome extension to enable previews for any kind of file
RPMs:gloobus-preview
Size:831.31 KiB

Package: gnome-mud-0.11.2-26.fc32
Summary: A MUD client for GNOME
RPMs:gnome-mud
Size:1.29 MiB

Package: golang-github-aablinov-caddy-geoip-0-0.2.20190911gitc06787a.fc32
Summary: Caddy plugin to resolve user GeoIP data
RPMs:golang-github-aablinov-caddy-geoip-devel
Size:13.99 KiB

Package: golang-github-caddyserver-dnsproviders-0.3.0-2.fc32
Summary: DNS providers for Caddy to solve the ACME DNS challenge
RPMs:golang-github-caddyserver-dnsproviders-devel
Size:33.28 KiB

Package: golang-github-captncraig-caddy-realip-0-0.2.20190922git6df827e.fc32
Summary: Real-IP middleware for caddy
RPMs:golang-github-captncraig-caddy-realip-devel
Size:14.78 KiB

Package: gr-iio-0.2-11.20170705git54c86a5.fc31
Summary: GNU Radio interface for IIO
RPMs:gr-iio gr-iio-devel
Size:909.96 KiB

Package: grig-0.8.1-11.fc32
Summary: A Ham Radio Control graphical user interface
RPMs:grig
Size:728.21 KiB

Package: gspiceui-1.1.00-5.fc33
Summary: A frontend to Spice circuit similators
RPMs:gspiceui
Size:2.12 MiB

Package: gtkmathview-0.8.0-30.fc32
Summary: A MathML rendering library
RPMs:gtkmathview gtkmathview-devel
Size:4.25 MiB

Package: inception-0.4.1-17.fc33
Summary: A fireWire physical memory manipulation tool
RPMs:inception
Size:2.05 MiB

Package: iptux-0.5.1-24.fc32
Summary: A software for sharing in LAN
RPMs:iptux
Size:1.15 MiB

Package: modtools-0.0.1-14.fc33
Summary: Utilities for creating and managing modules
RPMs:modtools
Size:38.28 KiB

Package: nodejs-babel-runtime-6.23.0-8.fc33
Summary: The babel selfContained runtime
RPMs:nodejs-babel-runtime
Size:51.15 KiB

Package: nodejs-benchmark-2.0.0-9.fc32
Summary: A JavaScript benchmarking library
RPMs:nodejs-benchmark
Size:44.06 KiB

Package: nodejs-call-delayed-1.0.0-7.fc32
Summary: Like setTimeout, but with arguments reversed
RPMs:nodejs-call-delayed
Size:10.45 KiB

Package: nodejs-conventional-changelog-writer-3.0.9-5.fc32
Summary: Write logs based on conventional commits and templates
RPMs:nodejs-conventional-changelog-writer
Size:19.71 KiB

Package: nodejs-conventional-commits-parser-2.1.7-7.fc33
Summary: Parse raw conventional commits
RPMs:nodejs-conventional-commits-parser
Size:21.88 KiB

Package

Re: Strange build failures in rawhide buildroot (cont'd) - glibc 2.33 dev snapshot?

[Fabio Valentini]

On Sat, Aug 15, 2020 at 8:52 PM Chris Murphy  wrote:
>
> On Sat, Aug 15, 2020 at 9:47 AM Fabio Valentini  wrote:
> >
> > On Sat, Aug 15, 2020 at 5:30 PM Paul Howarth  wrote:
> > >
> > > On Sat, 15 Aug 2020 16:28:47 +0200
> > > Fabio Valentini  wrote:
> > > > - autoreconf fails because %build needs a newer shell (protobuf):
> > > >
> > > > /usr/bin/autoconf: This script requires a shell more modern than all
> > > > /usr/bin/autoconf: the shells that I found on your system.
> > > > /usr/bin/autoconf: Please tell bug-autoc...@gnu.org about your system,
> > > > /usr/bin/autoconf: including any error possibly output before this
> > > > /usr/bin/autoconf: message. Then install a modern shell, or manually
> > > > run /usr/bin/autoconf: the script under such a shell if you do have
> > > > one. autoreconf: /usr/bin/autoconf failed with exit status: 1
> > > >
> > > > - shell not executing stuff in backticks `command foo` but returns
> > > > empty string (tonto):
> > > > `build-classpath foo` # this doesn't work?
> > > >
> > > >
> > > > I'm getting the sinking feeling that RPM scriptlets are broken? Do
> > > > they get run in the wrong shell? sh instead of bash maybe?
> > > >
> > > > I'm grasping at straws here, but all those build failures are starting
> > > > to be really disruptive to the work that I'm actually trying to do ...
> > >
> > > I had an issue with a configure script wanting a more modern shell. I
> > > tried running mock with --isolation-simple and it stopped complaining.
> > > Maybe that would help you too?
> > >
> > > Paul.
> >
> > It does! Running mock with --isolation=simple works around the issue.
> > Looks like the glibc 2.32.9000 snapshot broke systemd-nspawn based
> > chroots with this change:
> > - Linux: Use faccessat2 to implement faccessat (bug 18683)

(snip)

> Anyone know if Anaconda chroots are nspawn based? I ask because I'm
> tracking a bug that only happens when a qemu-kvm VM uses io=io_uring
> instead of threads; but consistently it isn't triggered until the
> installation transitions from rsync phase to the chroot phase. Once in
> the chroot, it implodes. Could be entirely unrelated things but... :D

I don't know how anaconca chroots are implemented, but "implode"
*does* sound familiar.
What issues are you seeing?

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