10:36 a.m.
Today I've attempted to run "dnf upgrade".
It has the following in it:
Upgrading:
protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
Enabling module streams:
ant
eclipse
maven
I don't consider this behavior adequate for a released Fedora version.
As a maintainer of dependent packages (Cura stack) I have tested and built it
against the nonmodular protobuf. What just happened here and how do I track it down?
dnf doesn't even tell me what module is this in. I suppose eclipse.
However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:40 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On 06. 12. 19 17:36, Miro Hrončok wrote:
Today I've attempted to run "dnf upgrade".
It has the following in it:
Upgrading:
protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
Enabling module streams:
ant
eclipse
maven
I don't consider this behavior adequate for a released Fedora version.
As a maintainer of dependent packages (Cura stack) I have tested and built it
against the nonmodular protobuf. What just happened here and how do I track it
down?
dnf doesn't even tell me what module is this in. I suppose eclipse.
However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
More to it, the modular protobuf disables Python support in:
https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27e...
My packages explicitly require protobuf for Python support. This is breaking them.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:58 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On Fri, 2019-12-06 at 17:40 +0100, Miro Hrončok wrote:
On 06. 12. 19 17:36, Miro Hrončok wrote:
> Today I've attempted to run "dnf upgrade".
>
> It has the following in it:
>
> Upgrading:
> protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
>
> Enabling module streams:
> ant
> eclipse
> maven
>
>
> I don't consider this behavior adequate for a released Fedora version.
>
> As a maintainer of dependent packages (Cura stack) I have tested and built it
> against the nonmodular protobuf. What just happened here and how do I track it
> down?
>
> dnf doesn't even tell me what module is this in. I suppose eclipse.
>
> However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
More to it, the modular protobuf disables Python support in:
https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27e...
My packages explicitly require protobuf for Python support. This is breaking them.
Probably caused by this:
https://pagure.io/releng/fedora-module-defaults/c/eced70a03ad4c97987b2665...
That protobuf build is indeed in the eclipse module:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1398456 - note
its tags are all 'module-eclipse-something'.
Stephen?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:59 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On Fri, 2019-12-06 at 08:58 -0800, Adam Williamson wrote:
On Fri, 2019-12-06 at 17:40 +0100, Miro Hrončok wrote:
> On 06. 12. 19 17:36, Miro Hrončok wrote:
> > Today I've attempted to run "dnf upgrade".
> >
> > It has the following in it:
> >
> > Upgrading:
> > protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
> >
> > Enabling module streams:
> > ant
> > eclipse
> > maven
> >
> >
> > I don't consider this behavior adequate for a released Fedora version.
> >
> > As a maintainer of dependent packages (Cura stack) I have tested and built it
> > against the nonmodular protobuf. What just happened here and how do I track it
> > down?
> >
> > dnf doesn't even tell me what module is this in. I suppose eclipse.
> >
> > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
>
> More to it, the modular protobuf disables Python support in:
>
>
https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27e...
>
> My packages explicitly require protobuf for Python support. This is breaking them.
Probably caused by this:
https://pagure.io/releng/fedora-module-defaults/c/eced70a03ad4c97987b2665...
That protobuf build is indeed in the eclipse module:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1398456 - note
its tags are all 'module-eclipse-something'.
Stephen?
Just found Stephen's reply in Pagure :P
https://pagure.io/releng/fedora-module-defaults/pull-request/187
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:59 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On Fri, 2019-12-06 at 08:58 -0800, Adam Williamson wrote:
On Fri, 2019-12-06 at 17:40 +0100, Miro Hrončok wrote:
> On 06. 12. 19 17:36, Miro Hrončok wrote:
> > Today I've attempted to run "dnf upgrade".
> >
> > It has the following in it:
> >
> > Upgrading:
> > protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
> >
> > Enabling module streams:
> > ant
> > eclipse
> > maven
> >
> >
> > I don't consider this behavior adequate for a released Fedora version.
> >
> > As a maintainer of dependent packages (Cura stack) I have tested and built it
> > against the nonmodular protobuf. What just happened here and how do I track it
> > down?
> >
> > dnf doesn't even tell me what module is this in. I suppose eclipse.
> >
> > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
>
> More to it, the modular protobuf disables Python support in:
>
>
https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27e...
>
> My packages explicitly require protobuf for Python support. This is breaking them.
Probably caused by this:
https://pagure.io/releng/fedora-module-defaults/c/eced70a03ad4c97987b2665...
That protobuf build is indeed in the eclipse module:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1398456 - note
its tags are all 'module-eclipse-something'.
Stephen?
Just found Stephen's reply in Pagure :P
https://pagure.io/releng/fedora-module-defaults/pull-request/187
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:29 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On Fri, Dec 06, 2019 at 05:40:23PM +0100, Miro Hrončok wrote:
On 06. 12. 19 17:36, Miro Hrončok wrote:
> Today I've attempted to run "dnf upgrade".
>
> It has the following in it:
>
> Upgrading:
> protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
>
> However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
More to it, the modular protobuf disables Python support in:
https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27e...
My packages explicitly require protobuf for Python support. This is breaking them.
So this is going to break Ceph, too.
--
Tomasz Torcz “If you try to upissue this patchset I shall be seeking
tomek(a)pipebreaker.pl an IP-routable hand grenade.” — Andrew Morton (LKML)
10:49 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On Fri, 2019-12-06 at 17:36 +0100, Miro Hrončok wrote:
Today I've attempted to run "dnf upgrade".
It has the following in it:
Upgrading:
protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
Enabling module streams:
ant
eclipse
maven
I've noticed this during an update as well, pretty weird behavior when
user has not explicitely asked for a module to be installed & information
what has triggered this action is lacking.
I don't consider this behavior adequate for a released Fedora version.
As a maintainer of dependent packages (Cura stack) I have tested and built it
against the nonmodular protobuf. What just happened here and how do I track it down?
dnf doesn't even tell me what module is this in. I suppose eclipse.
However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
10:50 a.m.
Thanks for CCing me (maintainer of protobuf here), I am particularly
not happy that some module (which is not even called protobuf, but
some random Java #$%! with ripped out python support overrides my
builds).
I have put a proposal into a FESCo ticket.
On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> Today I've attempted to run "dnf upgrade".
>
> It has the following in it:
>
> Upgrading:
> protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
>
> Enabling module streams:
> ant
> eclipse
> maven
>
>
> I don't consider this behavior adequate for a released Fedora version.
>
> As a maintainer of dependent packages (Cura stack) I have tested and built it
> against the nonmodular protobuf. What just happened here and how do I track it down?
>
> dnf doesn't even tell me what module is this in. I suppose eclipse.
>
> However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> 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
10:59 a.m.
On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org> wrote:
Thanks for CCing me (maintainer of protobuf here), I am particularly
not happy that some module (which is not even called protobuf, but
some random Java #$%! with ripped out python support overrides my
builds).
I have put a proposal into a FESCo ticket.
On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> Today I've attempted to run "dnf upgrade".
>
> It has the following in it:
>
> Upgrading:
> protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
>
> Enabling module streams:
> ant
> eclipse
> maven
>
>
> I don't consider this behavior adequate for a released Fedora version.
>
> As a maintainer of dependent packages (Cura stack) I have tested and built it
> against the nonmodular protobuf. What just happened here and how do I track it
down?
>
> dnf doesn't even tell me what module is this in. I suppose eclipse.
>
> However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
>
For the record, I've just pushed a temporary removal of the eclipse
default stream, so the next compose will not have it. For those of you
who are affected, your best bet would be to use `yum history rollback`
and wait to update again until tomorrow.
11:10 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
----- Original Message -----
From: "Stephen Gallagher" <sgallagh(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Cc: "Mat Booth" <mbooth(a)fedoraproject.org>,
protobuf-mainatiners(a)fedoraproject.org
Sent: Friday, December 6, 2019 5:59:50 PM
Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf
On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org> wrote:
>
> Thanks for CCing me (maintainer of protobuf here), I am particularly
> not happy that some module (which is not even called protobuf, but
> some random Java #$%! with ripped out python support overrides my
> builds).
>
> I have put a proposal into a FESCo ticket.
>
> On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
> >
> > Today I've attempted to run "dnf upgrade".
> >
> > It has the following in it:
> >
> > Upgrading:
> > protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
> >
> > Enabling module streams:
> > ant
> > eclipse
> > maven
> >
> >
> > I don't consider this behavior adequate for a released Fedora version.
> >
> > As a maintainer of dependent packages (Cura stack) I have tested and
> > built it
> > against the nonmodular protobuf. What just happened here and how do I
> > track it down?
> >
> > dnf doesn't even tell me what module is this in. I suppose eclipse.
> >
> > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> >
For the record, I've just pushed a temporary removal of the eclipse
default stream, so the next compose will not have it. For those of you
who are affected, your best bet would be to use `yum history rollback`
and wait to update again until tomorrow.
I got affected as well and I guess a big number of people also.
Is it safe to assume that with the next compose the extra modules will be disabled/removed
when doing a dnf update? Or do we need to rollback the update?
_______________________________________________
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
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
11:12 a.m.
On Fri, Dec 6, 2019 at 12:11 PM Charalampos Stratakis
<cstratak(a)redhat.com> wrote:
----- Original Message -----
> From: "Stephen Gallagher" <sgallagh(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
> Cc: "Mat Booth" <mbooth(a)fedoraproject.org>,
protobuf-mainatiners(a)fedoraproject.org
> Sent: Friday, December 6, 2019 5:59:50 PM
> Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf
>
> On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko
> <ignatenkobrain(a)fedoraproject.org> wrote:
> >
> > Thanks for CCing me (maintainer of protobuf here), I am particularly
> > not happy that some module (which is not even called protobuf, but
> > some random Java #$%! with ripped out python support overrides my
> > builds).
> >
> > I have put a proposal into a FESCo ticket.
> >
> > On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
> > >
> > > Today I've attempted to run "dnf upgrade".
> > >
> > > It has the following in it:
> > >
> > > Upgrading:
> > > protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
> > >
> > > Enabling module streams:
> > > ant
> > > eclipse
> > > maven
> > >
> > >
> > > I don't consider this behavior adequate for a released Fedora
version.
> > >
> > > As a maintainer of dependent packages (Cura stack) I have tested and
> > > built it
> > > against the nonmodular protobuf. What just happened here and how do I
> > > track it down?
> > >
> > > dnf doesn't even tell me what module is this in. I suppose eclipse.
> > >
> > > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> > >
>
>
> For the record, I've just pushed a temporary removal of the eclipse
> default stream, so the next compose will not have it. For those of you
> who are affected, your best bet would be to use `yum history rollback`
> and wait to update again until tomorrow.
I got affected as well and I guess a big number of people also.
Is it safe to assume that with the next compose the extra modules will be
disabled/removed when doing a dnf update? Or do we need to rollback the update?
No, the extra modules won't be disabled/removed automatically. The
change I made is to ensure no one else gets hit. You will need to roll
back the update if you were affected.
4:45 p.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
----- Original Message -----
From: "Stephen Gallagher" <sgallagh(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Friday, December 6, 2019 6:12:32 PM
Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf
On Fri, Dec 6, 2019 at 12:11 PM Charalampos Stratakis
<cstratak(a)redhat.com> wrote:
>
>
>
> ----- Original Message -----
> > From: "Stephen Gallagher" <sgallagh(a)redhat.com>
> > To: "Development discussions related to Fedora"
> > <devel(a)lists.fedoraproject.org>
> > Cc: "Mat Booth" <mbooth(a)fedoraproject.org>,
> > protobuf-mainatiners(a)fedoraproject.org
> > Sent: Friday, December 6, 2019 5:59:50 PM
> > Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for
> > protobuf
> >
> > On Fri, Dec 6, 2019 at 11:51 AM Igor Gnatenko
> > <ignatenkobrain(a)fedoraproject.org> wrote:
> > >
> > > Thanks for CCing me (maintainer of protobuf here), I am particularly
> > > not happy that some module (which is not even called protobuf, but
> > > some random Java #$%! with ripped out python support overrides my
> > > builds).
> > >
> > > I have put a proposal into a FESCo ticket.
> > >
> > > On Fri, Dec 6, 2019 at 5:44 PM Miro Hrončok <mhroncok(a)redhat.com>
> > > wrote:
> > > >
> > > > Today I've attempted to run "dnf upgrade".
> > > >
> > > > It has the following in it:
> > > >
> > > > Upgrading:
> > > > protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular
> > > >
> > > > Enabling module streams:
> > > > ant
> > > > eclipse
> > > > maven
> > > >
> > > >
> > > > I don't consider this behavior adequate for a released Fedora
> > > > version.
> > > >
> > > > As a maintainer of dependent packages (Cura stack) I have tested and
> > > > built it
> > > > against the nonmodular protobuf. What just happened here and how do
I
> > > > track it down?
> > > >
> > > > dnf doesn't even tell me what module is this in. I suppose
eclipse.
> > > >
> > > > However, protobuf was not mentioned in
> > > > https://pagure.io/fesco/issue/2285
> > > >
> >
> >
> > For the record, I've just pushed a temporary removal of the eclipse
> > default stream, so the next compose will not have it. For those of you
> > who are affected, your best bet would be to use `yum history rollback`
> > and wait to update again until tomorrow.
>
> I got affected as well and I guess a big number of people also.
>
> Is it safe to assume that with the next compose the extra modules will be
> disabled/removed when doing a dnf update? Or do we need to rollback the
> update?
>
No, the extra modules won't be disabled/removed automatically. The
change I made is to ensure no one else gets hit. You will need to roll
back the update if you were affected.
I would like to mention here that this is the first time that a modularity issue affected
me negatively as a user.
I maintain a quite pristine system with fedora 31 on my home computer, knowing full well,
exactly what is installed, dependencies, configs etc. And at some point while doing the
schedule dnf update I get 3 modules enabled for whatever reason that I had no control
over. No information, nothing.
I get there might be some quirks here and there, but having that done on a stable fedora
due to eclipse moving into a module so late in the release cycle is just unacceptable. I
don't know what a good solution would be here, maybe have eclipse as a flatpak only or
something, but this is clearly breaking user experience and expectations.
_______________________________________________
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
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
5:35 p.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
Am 06.12.19 um 23:45 schrieb Charalampos Stratakis:
I get there might be some quirks here and there, but having that done
on a stable fedora due to eclipse moving into a module so late in the release cycle is
just unacceptable. I don't know what a good solution would be here, maybe have eclipse
as a flatpak only or something, but this is clearly breaking user experience and
expectations.
To me the worst thing is that we have no way of fixing that error without user
interaction because the current modularity tooling/design does not allow this.
I mean errors happen but for regular packages we can remove faulty packages by
obsoleting them or bumping the epoch.
Felix
6:51 p.m.
After reading this thread I think this is a more serious problem than just
this package. I had "assumed" modules were just normal, so I didn't
question them being installed.
I have not intentionally enabled/installed any modules but through regular
updates I now have the following installed:
$ rpm -qa | grep module_
xml-commons-resolver-1.2-26.module_f28+3872+5b76729e.noarch
jaf-1.2.1-3.module_f31+5559+ae1ed734.noarch
jzlib-1.1.3-8.module_f28+3872+5b76729e.noarch
bouncycastle-pg-1.61-1.module_f31+6165+9b01e00c.noarch
apache-commons-codec-1.11-3.module_f29+6921+ca3ed728.noarch
jakarta-commons-httpclient-3.1-31.module_f31+6165+9b01e00c.noarch
log4j12-1.2.17-22.module_f28+3872+5b76729e.noarch
javamail-1.6.3-4.module_f31+5559+ae1ed734.noarch
xerces-j2-2.11.0-34.module_f28+3872+5b76729e.noarch
jline-2.14.6-4.module_f31+6165+9b01e00c.noarch
eclipse-equinox-osgi-4.12-6.module_f31+6165+9b01e00c.x86_64
protobuf-3.6.1-6.module_f31+6165+9b01e00c.x86_64
jackson-databind-2.9.8-1.module_f31+6165+9b01e00c.noarch
jansi-native-1.7-7.module_f29+6921+ca3ed728.x86_64
jackson-annotations-2.9.8-1.module_f31+6165+9b01e00c.noarch
apache-commons-net-3.6-3.module_f28+3872+5b76729e.noarch
hawtjni-runtime-1.16-2.module_f29+6921+ca3ed728.noarch
sac-1.3-30.module_f31+6165+9b01e00c.noarch
apache-commons-logging-1.2-13.module_f29+6921+ca3ed728.noarch
objectweb-asm-7.0-2.module_f31+6165+9b01e00c.noarch
jna-4.5.1-9.module_f31+6165+9b01e00c.x86_64
xml-commons-apis-1.4.01-25.module_f28+3872+5b76729e.noarch
xalan-j2-2.7.1-38.module_f28+3872+5b76729e.noarch
jansi-1.17.1-1.module_f29+6921+ca3ed728.noarch
protobuf-lite-3.6.1-6.module_f31+6165+9b01e00c.x86_64
jsch-0.1.54-7.module_f28+3872+5b76729e.noarch
apache-commons-lang3-3.7-3.module_f29+6921+ca3ed728.noarch
protobuf-compiler-3.6.1-6.module_f31+6165+9b01e00c.x86_64
bouncycastle-1.61-1.module_f31+6165+9b01e00c.noarch
rxtx-2.2-0.24.20100211.module_f31+6165+9b01e00c.x86_64
rhino-1.7.7.1-7.module_f31+6165+9b01e00c.noarch
gimp-libs-2.10.14-1.module_f31+6993+669d73be.x86_64
jackson-core-2.9.8-2.module_f31+6165+9b01e00c.noarch
gimp-2.10.14-1.module_f31+6993+669d73be.x86_64
apache-commons-compress-1.18-6.module_f31+6165+9b01e00c.noarch
Thanks,
Richard
6:54 p.m.
Ok, even worse than I thought, if I try to remove all the modules it wants
to take these packages with it...
Removing dependent packages:
OpenImageIO-utils x86_64
2.0.11-1.fc31 @updates
2.1 M
clementine x86_64
1.3.1-38.20181130gitd260c8b.fc31 @fedora
23 M
jackson-module-mrbean noarch
2.10.0-1.fc31 @updates
37 k
libreoffice-writer2latex x86_64
1.0.2-26.fc31 @fedora
505 k
mlt x86_64
6.18.0-1.fc31 @updates
3.1 M
nomacs x86_64
3.12-1.fc31 @fedora
7.9 M
opencv x86_64
3.4.8-1.fc31 @updates
11 M
pentaho-reporting-flow-engine noarch
1:0.9.4-18.fc31 @fedora
428 k
vlc x86_64
1:3.0.9-22.fc31
@rpmfusion-free-updates 5.5 M
Removing unused dependencies:
OpenImageIO x86_64
2.0.11-1.fc31 @updates
12 M
flute noarch
1.3.0-21.OOo31.fc31 @fedora
62 k
libbase noarch
1.1.3-22.fc31 @fedora
147 k
libfonts noarch
1.1.3-25.fc31 @fedora
255 k
libformula noarch
1.1.3-22.fc31 @fedora
416 k
liblayout noarch
0.2.10-19.fc31 @fedora
841 k
libloader noarch
1.1.3-21.fc31 @fedora
130 k
libmicrodns x86_64
0.0.10-4.fc31 @fedora
56 k
libplacebo x86_64
1.18.0-2.fc31 @fedora
3.1 M
librepository noarch
1.1.3-21.fc31 @fedora
85 k
libserializer noarch
1.1.2-22.fc31 @fedora
50 k
movit x86_64
1.6.2-4.fc31 @fedora
795 k
movit-data noarch
1.6.2-4.fc31 @fedora
44 k
opencv-contrib x86_64
3.4.8-1.fc31 @updates
20 M
opencv-core x86_64
3.4.8-1.fc31 @updates
26 M
openni x86_64
1.5.7.10-16.fc31 @fedora
1.6 M
pentaho-libxml noarch
1.1.3-21.fc31 @fedora
107 k
vlc-core x86_64
1:3.0.9-22.fc31
@rpmfusion-free-updates 50 M
WTF?
Thanks,
Richard
7:01 p.m.
Problem solved...
It is possible to resolve the problem without rolling back updates.
$ rpm -qa | grep module_ | xargs sudo dnf -y erase
$ sudo dnf module disable \*
$ sudo install <reinstall packages you want>
I'm guessing you could skip the first and last and just disable the modules
and do a distro-sync?
Thanks,
Richard
7:26 p.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On Fri, 2019-12-06 at 18:51 -0600, Richard Shaw wrote:
After reading this thread I think this is a more serious problem than
just
this package. I had "assumed" modules were just normal, so I didn't
question them being installed.
They are normal. You're not wrong. The problem is well understood at
this point: a module was given a stream default - meaning it becomes
the default source of packages it contains. That module includes
protobuf, meaning it takes over from the non-modular repo as the
default source of protobuf. The build of protobuf it contains was
missing some bits that other packages depend on, which broke those
packages.
I have not intentionally enabled/installed any modules but through
regular
updates I now have the following installed:
Well, yes. That's what happens. If this didn't actually break anything
for you, you don't really need to panic, but if you want to sync with
the current state (where the module stream default has been removed at
least temporarily), just disable the modules that were enabled and then
run 'dnf distro-sync'. That should return you to the non-modular
builds.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:08 p.m.
On Fri, Dec 6, 2019 at 7:26 PM Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
On Fri, 2019-12-06 at 18:51 -0600, Richard Shaw wrote:
> After reading this thread I think this is a more serious problem than
just
> this package. I had "assumed" modules were just normal, so I didn't
> question them being installed.
They are normal. You're not wrong. The problem is well understood at
this point: a module was given a stream default - meaning it becomes
the default source of packages it contains. That module includes
protobuf, meaning it takes over from the non-modular repo as the
default source of protobuf. The build of protobuf it contains was
missing some bits that other packages depend on, which broke those
packages.
I guess I should say that part of my problem is that:
1. I didn't ask for/want a module.
2. They aren't actually needed. After disabling them and reinstalling the
programs I care about (or could have used distro-sync) they weren't
actually needed.
I have not intentionally enabled/installed any modules but through
regular
> updates I now have the following installed:
Well, yes. That's what happens. If this didn't actually break anything
for you, you don't really need to panic, but if you want to sync with
the current state (where the module stream default has been removed at
least temporarily), just disable the modules that were enabled and then
run 'dnf distro-sync'. That should return you to the non-modular
builds.
I guess I understand some programs needed a specific/older version of
something as a "good" reason to put something in a module, but I'm finding
myself more a purest and I don't think we should have more than one source
of "truth", or in this case, multiple ways to fulfill a dependency.
Thanks,
Richard
3:40 a.m.
Richard Shaw wrote:
I guess I should say that part of my problem is that:
1. I didn't ask for/want a module.
This is exactly the problem with default module streams and why we (Miro
Hrončok and several other people including me) want to ban them.
Modules should not be forced onto users.
I guess I understand some programs needed a specific/older version
of
something as a "good" reason to put something in a module,
And I think modules are inherently the wrong answer to that because they
are, by design, not parallel-installable. A parallel-installable
compatibility package should be used instead.
but I'm finding myself more a purest and I don't think we
should have more
than one source of "truth", or in this case, multiple ways to fulfill a
dependency.
Indeed. I agree.
Kevin Kofler
8:12 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
1. I didn't ask for/want a module.
2. They aren't actually needed. After disabling them and reinstalling the
programs I care about (or could have used distro-sync) they weren't
actually needed.
This is where I'll drop a plug for the Stewardship SIG. Thanks in large
part to Fabio's great work, 2 has been possible since the ant and maven
modules were introduced.
The only distribution we don't maintain as ursine is eclipse. But we
still maintain many of the dependencies of the Java stack (including LibreOffice,
Dogtag, Ant and Maven) as ursine.
For some of us in the SIG, this means that we're able to run without
modular repos enabled at all, and continue doing or daily jobs requiring
the Java stack.
If you like the work, consider helping out!
We keep a list of packages that we're looking for updates on:
https://decathorpe.fedorapeople.org/stewardship-sig-stats.html
But check our list of pending PRs first:
https://decathorpe.fedorapeople.org/stewardship-sig-prs.html
Feel free to join #fedora-stewardship on Freenode if you're interested
in helping out but don't know where to start.
- Alex
3:28 a.m.
On Saturday, December 7, 2019, Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
On Fri, 2019-12-06 at 18:51 -0600, Richard Shaw wrote:
> After reading this thread I think this is a more serious problem than
just
> this package. I had "assumed" modules were just normal, so I didn't
> question them being installed.
They are normal. You're not wrong. The problem is well understood at
this point: a module was given a stream default - meaning it becomes
the default source of packages it contains.
That module includes
protobuf, meaning it takes over from the non-modular repo as the
default source of protobuf.
This should not be possible, a module should not randomly overwrite normal
package, that basically means all the work done on the package
(maintenance, testing) is just worthless because some random module has the
same package.
We should really reconsider the whole "default module" concept - it is
inherently incompatible with the rest of the distribution. We can keep
adding hacks every time it breaks but that doesn't scale. The negatives far
outweighs the gains.
11:13 a.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On 06. 12. 19 18:10, Charalampos Stratakis wrote:>> For the record, I've just
pushed a temporary removal of the eclipse
> default stream, so the next compose will not have it. For those
of you
> who are affected, your best bet would be to use `yum history rollback`
> and wait to update again until tomorrow.
I got affected as well and I guess a big number of people also.
Is it safe to assume that with the next compose the extra modules will be
disabled/removed when doing a dnf update?
As of the moment, once a modular stream is enabled implicilty, there is no way
to disable it implicitly.
Or do we need to rollback the update?
Rollback or disable explicitly.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:50 p.m.
On Fri, Dec 6, 2019 at 6:14 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Rollback or disable explicitly.
I had been busy testing a bunch of other packages from koji and
rollback is going to break a lot of things at this point.
Could you please explain how to install the new protobuf build and get
rid of the pulled-in dependencies (in a way that people with
overworked and under-functioning brain cells could understand)?
1:05 p.m.
On Fri, Dec 6, 2019 at 1:52 PM Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
On Fri, Dec 6, 2019 at 6:14 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> Rollback or disable explicitly.
I had been busy testing a bunch of other packages from koji and
rollback is going to break a lot of things at this point.
Could you please explain how to install the new protobuf build and get
rid of the pulled-in dependencies (in a way that people with
overworked and under-functioning brain cells could understand)?
In theory, `dnf module disable eclipse` and `dnf downgrade protobuf`
should work. I haven't tried this myself.
1:35 p.m.
On Fri, Dec 6, 2019 at 8:06 PM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On Fri, Dec 6, 2019 at 1:52 PM Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
>
> On Fri, Dec 6, 2019 at 6:14 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
> >
> > Rollback or disable explicitly.
>
> I had been busy testing a bunch of other packages from koji and
> rollback is going to break a lot of things at this point.
> Could you please explain how to install the new protobuf build and get
> rid of the pulled-in dependencies (in a way that people with
> overworked and under-functioning brain cells could understand)?
In theory, `dnf module disable eclipse` and `dnf downgrade protobuf`
should work. I haven't tried this myself.
Thanks Stephen, it turns out that on this system I had only
protobuf-lite installed, but the issue was the same. I disabled ant,
eclipse and maven modules and downgraded protobuf-lite. I need to
remember to check my work PC on Monday, I ran an update just before
leaving and I do have all of the above installed there.
2:23 p.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
On Fri, 2019-12-06 at 14:05 -0500, Stephen Gallagher wrote:
On Fri, Dec 6, 2019 at 1:52 PM Alexander Ploumistos
<alex.ploumistos(a)gmail.com> wrote:
> On Fri, Dec 6, 2019 at 6:14 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
> > Rollback or disable explicitly.
>
> I had been busy testing a bunch of other packages from koji and
> rollback is going to break a lot of things at this point.
> Could you please explain how to install the new protobuf build and get
> rid of the pulled-in dependencies (in a way that people with
> overworked and under-functioning brain cells could understand)?
In theory, `dnf module disable eclipse` and `dnf downgrade protobuf`
should work. I haven't tried this myself.
Maybe distro-sync rather than downgrade protobuf would be better?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:32 p.m.
New subject: Fedora 31: dnf upgrade suddenly enables modular streams for
protobuf
----- Original Message -----
From: "Miro Hrončok" <mhroncok(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Sent: Friday, December 6, 2019 6:13:08 PM
Subject: Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf
On 06. 12. 19 18:10, Charalampos Stratakis wrote:>> For the record, I've just
pushed a temporary removal of the eclipse
>> default stream, so the next compose will not have it. For those of you
>> who are affected, your best bet would be to use `yum history rollback`
>> and wait to update again until tomorrow.
>
> I got affected as well and I guess a big number of people also.
>
> Is it safe to assume that with the next compose the extra modules will be
> disabled/removed when doing a dnf update?
As of the moment, once a modular stream is enabled implicilty, there is no
way
to disable it implicitly.
> Or do we need to rollback the update?
Rollback or disable explicitly.
That is more than unfortunate.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
6:55 p.m.
Charalampos Stratakis wrote:
> From: "Miro Hrončok" <mhroncok(a)redhat.com>
> On 06. 12. 19 18:10, Charalampos Stratakis wrote:
> >> > Or do we need to rollback the update?
>
> Rollback or disable explicitly.
That is more than unfortunate.
IMHO, we should disable all default module streams in F31 immediately and at
the same time push a DNF update to F31 updates that disables ALL module
streams. Then users can explicitly reenable those that they actually want
and that were not forced on them.
Kevin Kofler
1597
days inactive
1600
days old
27 comments
14 participants
participants (14)
-
Adam Williamson -
Adam Williamson -
Alex Scheel -
Alexander Ploumistos -
Charalampos Stratakis -
drago01 -
Felix Schwarz -
Igor Gnatenko -
Kevin Kofler -
Martin Kolman -
Miro Hrončok -
Richard Shaw -
Stephen Gallagher -
Tomasz Torcz