Re: Fedora 32 Beta blocker status
by Fabio Valentini
On Fri, Feb 21, 2020, 23:54 Kevin Kofler <kevin.kofler(a)chello.at> wrote:
> Ben Cotton wrote:
> > 1. dnf-plugins-extras — Cannot upgrade to Fedora 32: Modules blocking
> > the upgrade path — NEW
> > ACTION: dnf team to implement module reset workaround
> >
> > 2. PackageKit — Cannot upgrade to Fedora 32: Modules blocking the
> > upgrade path — NEW
> > ACTION: PackageKit maintainers to work with dnf team to implement
> > module reset workaround
>
> Yet again!
>
> Can we please finally make it release-blocking to have a permanent,
> non-hack
> fix for this issue (ideally, eliminating all default streams and providing
> a
> default upgrade path from modular to non-modular packages, requiring an
> explicit opt-out if the user wishes to remain on modules)? We already
> punted
> that for F31 and here we are again having the exact same issue for F32!
>
FESCo is aware of this issue and there is a current proposal to "ban"
default streams, at least for now.
See: https://pagure.io/fesco/issue/2341#comment-627466
Fabio
> Kevin Kofler
> _______________________________________________
> 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
>
4 years, 2 months
Modularity branch name
by Remi Collet
Hi,
After some test, is looks like the stream name of a module have to
match the branch name.
I think this constraint doesn't make sense.
We can want different content (.yaml file) for different
distributions (Fedora vs EPEL) or different Version
Reported as https://pagure.io/fedora-infrastructure/issue/8687
(but probably not the right place)
Remi
4 years, 2 months
Re: Donate 1 minute of your time to test upgrades from F31 to F32
by Jerry James
On Wed, Mar 4, 2020 at 9:07 AM José Abílio Matos <jamatos(a)fc.up.pt> wrote:
> Problem 7: package mp-3.1.0-26.20200215git71c21a5.fc32.x86_64 requires jacop,
> but none of the providers can be installed
> - problem with installed package mp-3.1.0-23.20161124git1f39801.fc31.x86_64
> - package jacop-4.7-1.fc32.noarch requires mvn(org.scala-lang:scala-
> compiler), but none of the providers can be installed
> - package jacop-4.7-1.fc32.noarch requires mvn(org.scala-lang:scala-
> library), but none of the providers can be installed
> - mp-3.1.0-23.20161124git1f39801.fc31.x86_64 does not belong to a
> distupgrade repository
> - package scala-2.10.6-17.fc32.noarch is filtered out by modular filtering
> Problem 8: package coin-or-Cbc-2.10.4-1.fc32.x86_64 requires libasl.so.3()
> (64bit), but none of the providers can be installed
> - package mp-3.1.0-26.20200215git71c21a5.fc32.x86_64 requires jacop, but
> none of the providers can be installed
> - package mp-3.1.0-23.20161124git1f39801.fc31.x86_64 requires libgsl.so.23()
> (64bit), but none of the providers can be installed
> - problem with installed package coin-or-Cbc-2.10.3-2.fc31.x86_64
> - package jacop-4.7-1.fc32.noarch requires mvn(org.scala-lang:scala-
> compiler), but none of the providers can be installed
> - package jacop-4.7-1.fc32.noarch requires mvn(org.scala-lang:scala-
> library), but none of the providers can be installed
> - gsl-2.5-2.fc31.x86_64 does not belong to a distupgrade repository
> - coin-or-Cbc-2.10.3-2.fc31.x86_64 does not belong to a distupgrade
> repository
> - package scala-2.10.6-17.fc32.noarch is filtered out by modular filtering
This looks like yet another problem with modules. With no modules
involved, this update works just fine. You can install scala, jacop,
mp, and the coin-or packages in an F32 mock chroot, for example. But
somehow modules are preventing scala from being installed or updated.
--
Jerry James
http://www.jamezone.org/
4 years, 2 months
Re: Fedora 33 System-Wide Change proposal: Introduce module
Obsoletes and EOL
by Zbigniew Jędrzejewski-Szmek
On Tue, Mar 31, 2020 at 09:25:45AM +0200, Vít Ondruch wrote:
> Wouldn't be easier to use something we already have? E.g.
> https://src.fedoraproject.org/rpms/fedora-obsolete-packages
Obsoletes in individual rpms have no effect on modules, and any
enabled module "shadows" non-modular rpms that the module declared,
i.e. makes dnf consider only rpms from the module, completely ignoring
rpms from the normal repo, no matter what EVRA they have.
If that sounds wrong to you, you are not alone. But things are as
they are, and this Change is about making upgrades work within the
design of Modularity, hopefully avoiding stuff like [1,2,3,4,5].
[1] https://fedoraproject.org/wiki/Common_F31_bugs#Eclipse_module_has_been_re...
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1780827
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1747408
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1807832
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1806303
Zbyszek
4 years, 1 month
Re: Modularity Survey
by Kevin Kofler
Adam Williamson wrote:
> Well. Uh. Clearly it's being provided to *Google*.
Indeed. Once again, Fedora is depending on third-party, proprietary,
privacy-invading SaaS.
Kevin Kofler
4 years, 1 month
Re: Modularity Survey
by Adam Williamson
On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote:
> I'm sure we can trust that Red Hat did its
>
> due diligence and Google isn't using responses to a customer's form to
>
> track those taking the survey.
I don't really know why you'd think anyone can trust that. Google
tracks everyone everywhere as hard as it can. It's what Google *does*.
But I didn't actually suggest it's Terribly Awful to run this survey
through Google. I just said the privacy declaration seems to be wrong.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 1 month
Re: Modularity Survey
by Kamil Paral
On Tue, Apr 7, 2020 at 7:22 PM Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
> On Tue, 2020-04-07 at 13:12 -0400, Alex Scheel wrote:
> > I'm sure we can trust that Red Hat did its
> >
> > due diligence and Google isn't using responses to a customer's form to
> >
> > track those taking the survey.
>
> I don't really know why you'd think anyone can trust that. Google
> tracks everyone everywhere as hard as it can. It's what Google *does*.
>
> But I didn't actually suggest it's Terribly Awful to run this survey
> through Google. I just said the privacy declaration seems to be wrong.
>
I personally considered it quite clear that the intended meaning was that
they are not giving the data away to anyone external deliberately. Your
responses will be read and understood by a very small group of people and
not published in raw form. Yes there are servers and software providers
along the way. But this way you could also include the ISPs who also are
not prevented from snooping in your packets (and it's trivial at least for
plain text emails). And even if they provided a "direct" way to send your
responses to their email, and we ignored the ISPs, still, Google is the
email provider for most RedHatters. So there's no improvement at all.
I'm not saying we shouldn't talk about it, but the points mentioned are
common for most data submissions anywhere. I don't think it was the core of
the message.
4 years, 1 month
Re: Modularity Survey
by Adam Williamson
On Wed, 2020-04-08 at 13:47 -0400, Alex Scheel wrote:
> Hey Daniel, do you mind updating the GDPR compliance tag to include
> Google?
Right, this is all I intended in the first place :) A simple:
-The raw data will not be provided to anyone else at Red Hat or any 3rd parties
+The raw data will not be provided to anyone else at Red Hat or any 3rd parties (except Google)
would do the trick just fine. We didn't need a big thread about it...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4 years, 1 month
Re: Modularity Survey
by Daniel Mach
Updated.
Thanks both of you for the suggestion.
Dne 08. 04. 20 v 19:59 Adam Williamson napsal(a):
> On Wed, 2020-04-08 at 13:47 -0400, Alex Scheel wrote:
>> Hey Daniel, do you mind updating the GDPR compliance tag to include
>> Google?
>
> Right, this is all I intended in the first place :) A simple:
>
> -The raw data will not be provided to anyone else at Red Hat or any 3rd parties
> +The raw data will not be provided to anyone else at Red Hat or any 3rd parties (except Google)
>
> would do the trick just fine. We didn't need a big thread about it...
>
4 years, 1 month
Re: Modularity Survey
by Kamil Paral
On Wed, Apr 8, 2020 at 7:18 PM Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
> > I personally considered it quite clear that the intended meaning was that
> > they are not giving the data away to anyone external deliberately. Your
> > responses will be read and understood by a very small group of people and
> > not published in raw form. Yes there are servers and software providers
> > along the way. But this way you could also include the ISPs who also are
> > not prevented from snooping in your packets (and it's trivial at least
> for
> > plain text emails). And even if they provided a "direct" way to send your
> > responses to their email, and we ignored the ISPs, still, Google is the
> > email provider for most RedHatters. So there's no improvement at all.
>
> Er. It's a Google Survey, provided over https. Email is not involved.
>
No, it isn't. I was just trying to point out that even if they said "send
us your responses directly to our email", it wouldn't be better for
people's privacy, but possibly even slightly worse. It wasn't directly
related to what you said but rather to "Once again, Fedora is depending on
third-party, proprietary, privacy-invading SaaS" sentiment. I probably
should have quoted it better.
4 years, 1 month
