Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf
by Richard Shaw
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
4 years, 6 months
Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf
by Kevin Kofler
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
4 years, 6 months
Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf
by Richard Shaw
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
4 years, 6 months
Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf
by Kevin Kofler
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
4 years, 6 months
Re: modular protobuf issue (Dec. 6, 2019) recap
by Miro Hrončok
On 07. 12. 19 2:18, Langdon White wrote:
> ## How to determine if you have an issue and how to fix it:
>
> run: ```sudo dnf list --installed *protobuf*```
> if you get a result that looks like
> ```protobuf.x86_64 3.6.1-6.module_f31+6793+1c93c38```
>
> you have encountered the problem. so please:
>
> run: ```sudo dnf module disable eclipse```
> run: ```sudo dnf downgrade protobuf```
Since we cannot expect our users to read this list, I have opened:
https://bugzilla.redhat.com/show_bug.cgi?id=1780827
This needs to happen implicitly.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 6 months
Re: Bug filing/triage/ownership policy for modules
by Kevin Kofler
Vít Ondruch wrote:
> Also, it is interesting that AFAIK, we have not yet dealt with issue
> like this (i.e. reporting issues against specific streams) for RHEL8 yet.
How can Modularity have been forced to production in both Fedora and RHEL
without something as basic as this figured out? Inability to report bugs
against the software you ship should be considered a showstopper, ESPECIALLY
for a distribution calling itself "Enterprise".
It is also no surprise that you are not seeing any complaints about
Modularity if you do not provide a place to report them to.
Kevin Kofler
4 years, 5 months
Highlights from the latest Copr release
by Pavel Raiskup
Hello,
recently (on Feb 06, 2020) a new Copr release landed production. Here is
the list of visible changes:
- Users now can build packages against explicitly enabled modules. Go to
`Project -> Settings -> Build Options -> [Edit] button (near _enabled_
chroot) -> Enable module: textarea`. Note that fedora modular
repositories do not behave entirely good in mock (and copr) so we had to
disable before by default. So to actually bring the modules into copr,
you need to also configure the "external repositories" textarea for the
fedora-modular repo.
- Module builds were historically done only against Fedora dist-git. Now
the `copr-cli build-module` command was enhanced to accept `--distgit`
option which allows users to specify which dist-git instance to build
the module against. For now we have only the "fedora" distgit
configured. If you have ideas what external dist-git we should add to
our configuration, let us know.
- The EOL chroot policy scripts responsible for notifying users about
upcoming removals were fixed, users should now always be notified - and
if for some reason they are not, the EOL chroot will not be removed.
- Several fixes were done in copr-rpmbuild so the builds should be more
reliable, especially when the builder VM is heavily re-used for many
builds.
- News from yesterday - @msuchy enabled CDN for copr backend repositories.
You, or your users, likely want to re-enable the copr repositories
(dnf copr enable <owner/project>).
Happy building!
Pavel
4 years, 4 months
Re: Highlights from the latest Copr release
by John M. Harris Jr
On Thursday, February 6, 2020 8:42:56 AM MST Pavel Raiskup wrote:
> Hello,
>
> recently (on Feb 06, 2020) a new Copr release landed production. Here is
> the list of visible changes:
>
> - Users now can build packages against explicitly enabled modules. Go to
> `Project -> Settings -> Build Options -> [Edit] button (near _enabled_
> chroot) -> Enable module: textarea`. Note that fedora modular
> repositories do not behave entirely good in mock (and copr) so we had to
> disable before by default. So to actually bring the modules into copr,
> you need to also configure the "external repositories" textarea for the
> fedora-modular repo.
>
> - Module builds were historically done only against Fedora dist-git. Now
> the `copr-cli build-module` command was enhanced to accept `--distgit`
> option which allows users to specify which dist-git instance to build
> the module against. For now we have only the "fedora" distgit
> configured. If you have ideas what external dist-git we should add to
> our configuration, let us know.
>
> - The EOL chroot policy scripts responsible for notifying users about
> upcoming removals were fixed, users should now always be notified - and
> if for some reason they are not, the EOL chroot will not be removed.
>
> - Several fixes were done in copr-rpmbuild so the builds should be more
> reliable, especially when the builder VM is heavily re-used for many
> builds.
>
> - News from yesterday - @msuchy enabled CDN for copr backend repositories.
> You, or your users, likely want to re-enable the copr repositories
> (dnf copr enable <owner/project>).
>
> Happy building!
> Pavel
It looks like this is mostly module related stuff, which is absolutely useless
for most packagers.. I hope it's good for RHEL at least, but it seems to be
more of a nightmare there (for sysadmins, rather than packagers).
--
John M. Harris, Jr.
Splentity
4 years, 4 months
Re: Announcement: EPEL Steering Committee Changes
by Peter Boy
> Am 19.02.2020 um 06:59 schrieb John M. Harris Jr <johnmh(a)splentity.com>:
>
> Based on this, I'm not so sure that Troy is the best person to take that place
> within EPEL's Steering Committee. ..., as he is a member of the
> Modularity team, this is not a good sign for what's to come.
Whether modularity is good news or a nightmare, it is a fact in EL 8. Troy obviously being familiar with it might be the best to make it work as smooth as possible. Besides I remember him as very supportive from Scientific Linux (sadly gone with EL8)so I'd appreciate it.
—
Dr. Peter Boy
University of Bremen
Mary-Sommerville-Str. 5
28359 Bremen
Germany
pb(a)zes.uni-bremen.de
www.zes.uni-bremen.de
4 years, 3 months
