Re: The Future of the Java Stack (also regarding ELN and RHEL)
by Guido Aulisi
> Il giorno 10 set 2020, alle ore 16:53, Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org> ha scritto:
>
> On 10.09.2020 16:10, Aleksandar Kurtakov wrote:
>> Flatpak is way better suited for our use case and in addition gives us
>> access to a way bigger install base.
>
> Flathub is a third-party repository and not related to Fedora at all.
>
>> And the involvement on Java packaging in Fedora is so low that we literally have to maintain whole other stacks including jetty, lucene and etc. - not feasible work in any way.
>
> Fedora Modularity team destroyed the entire Java stack in Fedora after
> moving ant/maven to modules.
>
> I think FESCo should completely forbid modules without packaged
> non-modular versions.
I totally agree
> --
> Sincerely,
> Vitaly Zaitsev (vitaly(a)easycoding.org)
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.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
Ciao
Guido
3 years, 7 months
Re: maybe a path forward for java and modules? [was Re: The Future
of the Java Stack (also regarding ELN and RHEL)]
by Petr Pisar
On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> Sooooo: RH Java packagers, what if you build these packages as non-modular
> (maybe using some scripting to make it happen at the same time as modular
> builds?) and add a readme explaining their maintenance state?
Do you mean literally a README file under /usr/share/doc/${PACAKGE}/
directory? That won't work, because nobody looks there.
Either the package should be moved into a separate repository that an end user
have to explicitly enable and later can inspect an origin of the package with
"dnf info $PACKAGE", or the package should not be distributed at all. Pungi
tool that produces the distribution composes supports it. It's only a matter
of configuration.
(Or we can invent a new RPM tag for a support level of the package.)
-- Petr
3 years, 7 months
Re: maybe a path forward for java and modules? [was Re: The Future
of the Java Stack (also regarding ELN and RHEL)]
by Dominik 'Rathann' Mierzejewski
On Friday, 18 September 2020 at 11:22, Petr Pisar wrote:
> On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> > Sooooo: RH Java packagers, what if you build these packages as non-modular
> > (maybe using some scripting to make it happen at the same time as modular
> > builds?) and add a readme explaining their maintenance state?
>
> Do you mean literally a README file under /usr/share/doc/${PACAKGE}/
> directory? That won't work, because nobody looks there.
I do. :)
What about https://src.fedoraproject.org/rpms/<name>/blob/master/f/README.md ?
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
3 years, 7 months
Re: maybe a path forward for java and modules? [was Re: The Future
of the Java Stack (also regarding ELN and RHEL)]
by Petr Pisar
On Fri, Sep 18, 2020 at 12:21:15PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 18 September 2020 at 11:22, Petr Pisar wrote:
> > On Thu, Sep 17, 2020 at 12:51:46PM -0400, Matthew Miller wrote:
> > > Sooooo: RH Java packagers, what if you build these packages as non-modular
> > > (maybe using some scripting to make it happen at the same time as modular
> > > builds?) and add a readme explaining their maintenance state?
> >
> > Do you mean literally a README file under /usr/share/doc/${PACAKGE}/
> > directory? That won't work, because nobody looks there.
>
> I do. :)
>
> What about https://src.fedoraproject.org/rpms/<name>/blob/master/f/README.md ?
>
Do you think that package users consult dist-git before reporting a bug?
I think the idea with a template in Bugzilla was better.
Moreover that file was supposed to display a source package description on all
possible places (and originally was supposed to automatically updated from SRPM
packages, but that was never implemented).
At the end a packager can put the notice into %description of the spec file.
I sometimes document there how the files are distributed among the subpcackages.
-- Petr
3 years, 7 months
Fedora 33 compose report: 20201015.n.0 changes
by Fedora Rawhide Report
OLD: Fedora-33-20201014.n.0
NEW: Fedora-33-20201015.n.0
===== SUMMARY =====
Added images: 0
Dropped images: 0
Added packages: 0
Dropped packages: 0
Upgraded packages: 2
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages: 0 B
Size of upgraded packages: 562.04 KiB
Size of downgraded packages: 0 B
Size change of upgraded packages: 5.16 KiB
Size change of downgraded packages: 0 B
===== ADDED IMAGES =====
===== DROPPED IMAGES =====
===== ADDED PACKAGES =====
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
Package: fedora-release-33-1
Old package: fedora-release-33-0.15
Summary: Fedora release files
RPMs: fedora-release fedora-release-cinnamon fedora-release-cloud fedora-release-common fedora-release-container fedora-release-coreos fedora-release-designsuite fedora-release-identity-basic fedora-release-identity-cinnamon fedora-release-identity-cloud fedora-release-identity-container fedora-release-identity-coreos fedora-release-identity-designsuite fedora-release-identity-iot fedora-release-identity-kde fedora-release-identity-matecompiz fedora-release-identity-server fedora-release-identity-silverblue fedora-release-identity-snappy fedora-release-identity-soas fedora-release-identity-workstation fedora-release-identity-xfce fedora-release-iot fedora-release-kde fedora-release-matecompiz fedora-release-server fedora-release-silverblue fedora-release-snappy fedora-release-soas fedora-release-workstation fedora-release-xfce
Size: 381.78 KiB
Size change: -9.07 KiB
Changelog:
* Wed Oct 14 2020 Mohan Boddu <mboddu(a)bhujji.com> - 33-1
- Setup for F33 Final
Package: fedora-repos-33-1
Old package: fedora-repos-33-0.13
Summary: Fedora package repositories
RPMs: fedora-gpg-keys fedora-repos fedora-repos-archive fedora-repos-eln fedora-repos-modular fedora-repos-ostree fedora-repos-rawhide fedora-repos-rawhide-modular
Added RPMs: fedora-repos-archive
Size: 180.26 KiB
Size change: 14.23 KiB
Changelog:
* Mon Oct 05 2020 Dusty Mabe <dusty(a)dustymabe.com> - 33-0.14
- Add the fedora-repos-archive subpackage.
* Tue Oct 13 2020 Stephen Gallagher <sgallagh(a)redhat.com> - 33-0.15
- Update the ELN repos for the BaseOS and AppStream split
* Tue Oct 13 2020 Stephen Gallagher <sgallagh(a)redhat.com> - 33-0.16
- Ensure that the ELN GPG key always points at the Rawhide key
* Tue Oct 13 2020 Mohan Boddu <mboddu(a)bhujji.com> - 33-0.17
- Disable eln repos on non rawhide release (sgallagh)
* Wed Oct 14 2020 Mohan Boddu <mboddu(a)bhujji.com> - 33-1
- Setup for F33 Final
- Disable testing repos
===== DOWNGRADED PACKAGES =====
3 years, 6 months
Re: EOL and Obsoletes in Modularity
by Petr Pisar
On Wed, Oct 28, 2020 at 12:13:27PM +0100, Martin Curlej wrote:
> On Tue, Oct 27, 2020 at 3:53 PM Petr Pisar <ppisar(a)redhat.com> wrote:
> > What are the other means which the 3rd parties use?
> >
>
> Your imagination is the limit. ;) Just joking. Now seriously. For example,
> Redhat and Fedora. The information about EOL and Obsoletes will be used and
> distributed differently.
I know Fedora and RHEL. Fedora has EOL burried in PDC and nobody (with the
exception of a Rawhide compose process) uses it.
RHEL lists the EOLs on a web page
<https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-c...>
so probably no tool uses the data.
> Also it depends to whom you serve your content. If you build modules just
> for your company and distribute it on your intranet it's different from
> a community driven opensource linux distribution.
>
But how do they distribute the EOL data?
You wrote that many people shared with you the datails. I'm curious how they
do that or whether they do that at all. Can you give us some examples?
-- Petr
3 years, 6 months
Re: EOL and Obsoletes in Modularity
by Zbigniew Jędrzejewski-Szmek
On Thu, Oct 29, 2020 at 12:43:05PM +0100, Petr Pisar wrote:
> Currently EOL is defined per stream in PDC. The initial value is provided by
> packagers with "fedpkg request-branch --sl" command. Then the value can be
> edited by relengs based on a ticket.
In general, a big +1 to keeping this decentralized. First, releng is overworked
already, and second, releng does not understand this is any better than the
packagers.
We need to a clear policy and a clear implementation, i.e. syntax
which is easy to write and read. I'm sure this will go a long way
towards the policy being correctly followed much more than another choke
point requiring manual action from a small group of people.
Zbyszek
3 years, 6 months
Re: EOL and Obsoletes in Modularity
by Miro Hrončok
On 10/29/20 12:43 PM, Petr Pisar wrote:
>> OTOH If the EOL date is informational only (Anna keeps postgresql:9.5 but
>> sees a warning during dnf upgrades) and the obsoletes only actually happen
>> on a specific user action (and on release boundary), great.
>
> That's how it is suspposed to work. Read "Proposed dnf behavior" in
> <https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL>.
Indeed, in that case a mid-release EOL makes sense, sorry for the confusion.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 6 months
Re: EOL and Obsoletes in Modularity
by Neal Gompa
On Thu, Oct 29, 2020 at 8:17 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> On 10/29/20 12:43 PM, Petr Pisar wrote:
> >> OTOH If the EOL date is informational only (Anna keeps postgresql:9.5 but
> >> sees a warning during dnf upgrades) and the obsoletes only actually happen
> >> on a specific user action (and on release boundary), great.
> >
> > That's how it is suspposed to work. Read "Proposed dnf behavior" in
> > <https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL>.
>
> Indeed, in that case a mid-release EOL makes sense, sorry for the confusion.
>
Ideally, DNF could have different policy modes for EOLs. By default
it could throw warnings about using EOL content and still let you
install it, but in a mass-managed scenario, the policy could be
switched to enforcing (if you haven't already installed it, you
can't).
--
真実はいつも一つ！/ Always, there's only one truth!
3 years, 6 months
Re: EOL and Obsoletes in Modularity
by Miro Hrončok
On 11/2/20 12:33 PM, Daniel Mach wrote:
> Then there's a question how to get the documents into modules.yaml. From my
> perspective, it's up to Fedora infra/releng/packaging people. Whether it should
> be in dist-git, git repo (similar to modulemd-defaults or comps), PDC, Bodhi
> (similar to updateinfo) or somewhere else - that's entirely their call.
I understand this perspective, but unless we have Fedora infra/releng/packaging
people who would own this and drive this, it won't happen. I consider myself
"packaging people" and I certainly won't. Do we have at least an idea if we have
such people?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 6 months
