Re: Please, IMHO, resolve in some way the Samba MIT kerberos problem.
On Mon, 4 Nov 2019 20:56:13 -0600 Chris Adams wrote: > Once upon a time, Nico Kadel-Garcia said: > > Without robust integration with AD, I have no use > > for FreeIPA. And I don't know *anyone* who uses a FreeIPA server. > > > > Perhaps it's time to drop FreeIPA? > > Nope. You are assuming the everybody needs AD... lots of people have no > use for AD and just want a good IdM. > > Never assume your use case is the only use case. If I can speak for myself and for the Linux people I know, nobody needs a FreeIPA, and many need a Samba AD DC. And of course they want a stable solution if possible. The current situation leads to either choosing a different distribution (the simplest solution), or compiling a Samba with Heimdal Kerberos themselves; perhaps someone chooses a commercial solution also (which is of course with Heimdal Kerberos). I am not saying that the FreeIPA is useless or has no users, but in my opinion the chosen attitude to the Samba AD DC was perhaps the worst possible and IMO at least frustrated a lot of users (including me). For me, thanks to Nico Kadel-Garcia, for his work to make stable as possible Samba AD DC in Fedora/Centos. Regards, Franta Hanzlik -- I hope the Fedora will have a better init and no binary logs ___ 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: Modularity: The Official Complaint Thread
On 05. 11. 19 21:17, Stephen Gallagher wrote: I'm sure there are other pain points and I encourage you to share them. Please adhere to the guidelines about objectively measurable issues, though. M1. For traditional packages, there was a consistent and easy way to find a spec file for a given package on a given Fedora release. Step 1. Figure out hat the source package is (e.g. repoquery --source) Step 2. Go to src.fp.o or fedpkg clone the source pkg Step 3. Switch branch to fN For modular packages, I still don't remember how to do this, but I know it requires more than 3 steps, to comply with the strict guidelines for complaints. As an added problem, it is usually still possible to do the steps above and end up with a spec file that is not what I have installe don my system (because the package is modular without me realizing that). As a side note, with the special package.cfg file, it is now getting more complicated even with ursine packages. I however am also strictly against using package.cfg to build on Fedora N from a different branch while not documenting it in the fN branch. M2. For traditional packages, it was consistent and easy to find package dependencies in Fedora. For a proven packager, Fedora Packaging Committee member or generally for anybody doing a System Wide Change, being able to run queries like: $ repoquery --repo=rawhide --whatrequires 'libpython3.8.so.1.0()(64bit)' is trivial. Arguably, there are some quirks already (for example it doesn't properly work with boolean (rich?) deps). Witch modules, I still don't remember how to do this, but I know it requires more than 1 easy repoquery over rawhide. M3. For traditional packages, it was consistent and easy to do a targeted rebuild over a dependency bump. You repeat the previous step, gather source package names, and do "fedpkg clone, rpmdev-bumpspec, git push, fedpkg build" for each. With modularity, you need to figure out what modules even use your dependency, how to update the packages in said modules, commit some empty commits into the module and rebuild the module. In cases where you need to do changes to accommodate some backwards incompatible changes, you might get problems with modules that build on one Fedora, but ship everywhere. M4. With traditional packages, we have processes to ensure that if a package is no longer working, it eventually gets orphaned. Announcements are happening. Dependent packages are informed. If a module goes dead and potentially away, the dependent packages are not automatically informed. And even if they happen to realize, it might not be easy for them to unorpahn given module and start maintaining it, if they are not yet familiarized with the technology. (Let me know if anything needs more details, I'm writing this in a hurry before I go somewhere.) Disclaimer: I criticise the problems with the design and/or implemtatation of a technology. I do not attampt to demoralize or offend any particular person, group or project. If it sounds like it, note that it was not my intention. I was always assuming this is obvious, but based on several e-mails I've seen recently, I am rather being explicit. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Modularity and all the things
On Tuesday, November 5, 2019 2:31:56 PM MST Randy Barlow wrote: > This means that Gentoo has 15 years of experience with providing > multiple versions of software streams to their users. As I said in my > last e-mail, it's the analogous "you can learn from the XSS > vulnerabilities that Firefox has solved along the way". If they've been > doing it for 15 years, they have expertise in this problem space and we > can learn from that. This only works to a limited degree in Gentoo, and even then, if you want a stable system, you can't really install different versions of packages as X version of Y package will break package Z, generally not in the ebuild either. -- John M. Harris, Jr. Splentity ___ 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: Modularity and all the things
On Tuesday, November 5, 2019 6:42:43 PM MST Randy Barlow wrote: > On Wed, 2019-11-06 at 01:24 +0100, Kevin Kofler wrote: > > Actually, it could also mean that Gentoo users are just in a habit of > > not complaining, no matter what. :-) After all, those are the same > > users who find it perfectly fine that installing the kernel or > > LibreOffice takes days (at least in the early years). ;-) > > Heh, true. I don't have a graphical Gentoo install these days, but last > I tried it LibreOffice did take a few days (maybe 2-3?). KDE was epic > too. The kernel actually isn't so bad, as long as you only build the > modules you need for your hardware. gcc takes a long time too, due to > the staged builds. A bit off topic, but: I build my own kernel with Fedora. Have to, as I'm running on an Asus C201P. It generally takes anywhere from one to 4 hours to build the kernel I use, on the Asus C201P itself. It takes 40 minutes at most on my other laptop, a Core 2 Duo X200 Tablet @ 1.2GHz. -- John M. Harris, Jr. Splentity ___ 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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
On 06. 11. 19 0:26, Michael Cronenworth wrote: On 11/5/19 4:59 PM, Kevin Kofler wrote: … and Calamares … ... and Domoticz (Fedora), and Kodi (RPMFusion)... Will this be as simple as a BR change in the spec or will application patches be necessary? Not for most cases. See this list: Python extension modules that currently are unnecessary linked to libpython - changes to cmake/autotools are needed, a sed in spec might do - if not changed, still works, but drags in the extra 3.4 MB (shared) Non-extension software embedding Python and linking to libpython - no changes necessary at all - but drags in the extra 3.4 MB (shared) Python extension modules embedding Python and linking to libpython - needs to be evaluated case by case - changes to cmake/autotools are needed - changes in code might be necessary as well - if not changed, might misbehave - Python Maint will provide help if asked for -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Encrypted DNS in Fedora
On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel wrote: > Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit : > > > > > > I don't agree with centralisation. You should run your own DoH > > endpoint, > > using Google's, Cloudflare's or Quad9's servers is a shortcut. > > DoH has zero integration and manageability. “It’s not centralized” (but > you have to set manually DoH settings in all apps *or* rely on a > centralized Google DoH whitelist) is an utter joke. Setting in all apps? Excuse me? You run your stub DoH resolver on ::1 and put ::1 in resolv.conf. Done, you've got DoH set system-wide, which I believe this thread is about. And you run resolving endpoint on your trusted server, or on some micro-vm in Azure or somewhere else, or even on Fedora's Communishift. Google does not even enter the picture. (cutting the rest as it's irrelevant) -- Tomasz TorczOnce you've read the dictionary, xmpp: zdzich...@chrome.pl every other book is just a remix. ___ 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: Modularity and all the things
On Tue, 2019-11-05 at 21:17 -0500, Neal Gompa wrote: > This feature of "slotting" multiple EVRs of the same name actually > already exists in RPM. DNF currently restricts this to packages that > contain one of the following provides: > * installonlypkg(kernel) > * installonlypkg(kernel-module) > * installonlypkg(vm) > * multiversion(kernel) > > It's not terribly difficult to extend this functionality to apply > more > broadly than kernels and VM images wrapped in RPMs. :) That's a good point. I had actually noticed that the kernel was "special" in this regard. Is this hardcoded in dnf? When I grep for "installonly", I see this: /etc/dnf/dnf.conf:installonly_limit=3 I guess that's why I get 3 kernels, but I'm wondering if I can expand that set as a user? Probably not a good idea to mess with ☺ In any case, you are right that we could make it so other packages allowed installing more than one of the same name using this, but there would need to be awareness of which ones can and can't be simultaneously installed, and that's what Gentoo's slot feature achieves. For example, we could start calling python simply "python", but there would have to be a way to denote that some Python's can and can't be parallel installed (you can't parallel install a 3.6.1 and 3.6.2, but you *can* parallel install a 3.6.1 and a 3.5.2), and also that some other packages cannot be parallel installed (like grep, since it occupies /usr/bin/grep). But yeah, it does sound like dnf does have some of the code we'd need to do that. signature.asc Description: This is a digitally signed message part ___ 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: Modularity and all the things
On Tue, Nov 05, 2019 at 08:40:05PM -0500, Randy Barlow wrote: > Matthew, my door is still open to talk. Thanks. I think that would be a good idea. I replied to your private email. Like I said before, I was at a conference last week, and I am on vacation this week, and I have some family matters to attend to, so I literally do not know when I have time for a call. That doesn't mean I don't want to talk, it's just... kind of crazy. -- Matthew Miller Fedora Project Leader ___ 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: Modularity and all the things
On Tue, Nov 5, 2019 at 9:08 PM Randy Barlow wrote: > > > langdon wrote: > > > > * compat-libs (or compat lib style): not discoverable, name > > > > mangling > > > > Randy Barlow replied: > > > Yeah I don't love this either. > > > > I don't understand why people dislike compatibility libraries so > > much. > > I'll qualify my position as not so much that I strongly dislike it, but > more that I would prefer if the package metadata could formally store > the data for me, rather than encoding it in the name. > > When we encode it in the name, it's a convention, but when we store the > data in the package metadata it becomes a formal spec. > > For example, in Gentoo the Python package is just called "python", and > because they know about slots, it is comfortable with me having several > of them at once: > > $ equery l python > dev-lang/python-2.7.16 > dev-lang/python-3.6.9 > > In Fedora, we obviously do this too, but we don't call the package > Python, instead calling it "python2" and "python3": > > $ rpm -q python2 > python2-2.7.16-2.fc30.x86_64 > $ rpm -q python3 > python3-3.7.5-1.fc30.x86_64 > > This isn't bad, per se, but I like the elegance of having the package > manager explicitly know that python-2.7.16 and python-3.6.9 are both > the same package, just different slots of it. I mean, obviously, it's > working out OK for us. > This feature of "slotting" multiple EVRs of the same name actually already exists in RPM. DNF currently restricts this to packages that contain one of the following provides: * installonlypkg(kernel) * installonlypkg(kernel-module) * installonlypkg(vm) * multiversion(kernel) It's not terribly difficult to extend this functionality to apply more broadly than kernels and VM images wrapped in RPMs. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Modularity and all the things
On Wed, 2019-11-06 at 01:18 +0100, Kevin Kofler wrote: > The big difference is that Gentoo is source-based, whereas Fedora is > binary-based. So where Gentoo needs to ship only one ebuild (the > equivalent of a specfile) for foo-1.2.3 that the user can then > compile against different choices of dependencies, we need to ship > binary RPMs of that same foo-1.2.3 version for each and every > combination (exponentially many) of dependency versions that we want > to support. Which is one of the unsolved issues with our Modularity > implementation, too. This seems to be like more of a complication for the packager than for the user, right? I was commenting on the user experience and not the packager experience. I agree that the packager experience does have the crazy combinatorics, as adamw pointed out, but I discussed that in my reply to him. You are right that the varying choices of dependencies creates exponential growth, but modularity has conflicts too (you can't install two modules that need conflicting dependency versions) and I don't see a way to offer the user what we are talking about without having conflicts. Gentoo does have conflicts too for packages that can't parallel install (not all of their packages are parallel installable, but they are all generally parallel available), so they basically have this problem too. Unless I am misunderstanding what you mean? > One solution would be to pick one combination of dependency versions > and > rely on parallel installation of the dependencies, but for that, we > need not > only a stream system, but also the file system layout tweaks of the > parallel-installable Gentoo slots. For parallel installation, there > are > really only 2 solutions: > 1. manually tweak things per package in the least invasive possible > way >(e.g., installing headers to /usr/include/qt5 rather than just >/usr/include), as already done in compatibility packages, or > 2. use a custom prefix under /opt, as is already done in SCLs. > I think 1. is by far superior (even though it is more work), and > AFAIK, FPC > and FESCo mostly agree: in fact, Fedora ships packages that do 1., > but not > packages that do 2. (SCLs have basically been rejected in Fedora). Agreed. > langdon wrote: > > > * compat-libs (or compat lib style): not discoverable, name > > > mangling > > Randy Barlow replied: > > Yeah I don't love this either. > > I don't understand why people dislike compatibility libraries so > much. I'll qualify my position as not so much that I strongly dislike it, but more that I would prefer if the package metadata could formally store the data for me, rather than encoding it in the name. When we encode it in the name, it's a convention, but when we store the data in the package metadata it becomes a formal spec. For example, in Gentoo the Python package is just called "python", and because they know about slots, it is comfortable with me having several of them at once: $ equery l python dev-lang/python-2.7.16 dev-lang/python-3.6.9 In Fedora, we obviously do this too, but we don't call the package Python, instead calling it "python2" and "python3": $ rpm -q python2 python2-2.7.16-2.fc30.x86_64 $ rpm -q python3 python3-3.7.5-1.fc30.x86_64 This isn't bad, per se, but I like the elegance of having the package manager explicitly know that python-2.7.16 and python-3.6.9 are both the same package, just different slots of it. I mean, obviously, it's working out OK for us. > "not discoverable": How so? I agree that the compat packages are discoverable. I will say though that searching for "python" returning 2 results instead of 1 is a minorly worse search experience. Minor enough that it doesn't really bother me much. signature.asc Description: This is a digitally signed message part ___ 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: Modularity and all the things
On Tue, 2019-11-05 at 19:13 -0500, Randy Barlow wrote: > For packagers who want to put the same spec file in all branches > today (I think Kevin Koffler often likes to do this) *Kofler - sorry for misspelling your name Kevin. signature.asc Description: This is a digitally signed message part ___ 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: Modularity and all the things
On Wed, 2019-11-06 at 01:24 +0100, Kevin Kofler wrote: > Actually, it could also mean that Gentoo users are just in a habit of > not complaining, no matter what. :-) After all, those are the same > users who find it perfectly fine that installing the kernel or > LibreOffice takes days (at least in the early years). ;-) Heh, true. I don't have a graphical Gentoo install these days, but last I tried it LibreOffice did take a few days (maybe 2-3?). KDE was epic too. The kernel actually isn't so bad, as long as you only build the modules you need for your hardware. gcc takes a long time too, due to the staged builds. signature.asc Description: This is a digitally signed message part ___ 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: Modularity and all the things
On Tue, 2019-11-05 at 19:00 -0500, Stephen Gallagher wrote: > Randy, I think you are misinterpreting Matthew’s statements here. > You’re attributing malice and dismissiveness where “text is a poor > communication medium” is a valid answer. Hi Stephen, Text is a poor communication medium. I've worked to remain objective and dispassionate in the face of mischaracterizations and accusations. My post that you replied to was not dispassionate, but it's becoming difficult to remain so. I've been trying to meet with Matthew for two weeks now so we can avoid text, but he keeps canceling or declining the meetings. Thus, we are stuck with text for now. Matthew, my door is still open to talk. > I strongly doubt that Matthew (of all people!) is trying to insult > anyone in Fedora. Could you try to reread his words, this time > assuming he’s speaking in good faith and may not have communicated > his points well? I just went and re-read each of our posts. In my first reply to him, I explicitly gave him the benefit of the doubt. He did not return the favor. It's hard to see how accusing me of trolling on a public list (and in a private message), misconstruing what I said, and claiming that I said "_they're_ the problem" were done in good faith. Each of Matthew's apologies were accompanied with an accusation, which communicates that he wasn't really sorry. A person acting in good faith would simply have apologized. > Because piling onto what I can reasonably guess is just a case of bad > phrasing is bringing the conversation into a needlessly negative and > personal space. I disagree that it is simply bad phrasing, but I agree with your broader point and goal. Thank you. signature.asc Description: This is a digitally signed message part ___ 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: Modularity: The Official Complaint Thread
- Original Message - > From: "Kevin Kofler" > To: devel@lists.fedoraproject.org > Sent: Tuesday, November 5, 2019 7:48:47 PM > Subject: Re: Modularity: The Official Complaint Thread > > Alex Scheel wrote: > > Special care needs to be taken to make sure we discuss what happens > > when a _module maintainer_ wants to switch the module stream of one > > of its dependencies, especially a dependency the user never > > specifically selected a stream for. That should be an allowed and fully > > supported use case. > > > > This was the pki-core<->idm module fiasco that was never resolved by > > DNF/Modularity. > > > > I'd post the bug number but the bug isn't public. > > > > > > So perhaps split this into: > > > > 1. How does a _user_ change module streams during upgrade? > > 2. How does the _maintainer_ change module streams of a dependent > > module? (module a -dep-> module b -- change stream of b from 1 to 2) > > > > > > IMO, without a resolution in Fedora we'll never get one in RHEL. > > Indeed, in Fedora, it is quite plausible for a package to be ported to a new > major version of a library in an update. (In RHEL, it actually also is, but > for different reasons, i.e., its extremely long lifetime.) > > But this shows how modules are the wrong answer for non-leaf packages. What > happens if one of the packages you had installed wants to bump the module > stream of its dependency and another one doesn't? Then suddenly, your system > cannot be updated anymore, because the packages that previously coexisted > just fine now irremediably conflict. > > (In fact, this is just a particularly nasty special case of the more general > design flaw of Modularity that Stephen Gallagher has unfortunately forgotten > in his list in the original post, the version conflicts caused by versioned > dependencies without parallel installability. The special case is that the > conflicts can also be introduced on updates to previously non-conflicting > packages.) > > Providing incompatible versions of non-leaf packages MUST be done in a > parallel-installable way. There is no other way out. Since this is all public, for the rest of the audience: - There are three modules in question here, in core RHEL: 1. pki-deps, an artifact of the original, broken attempt at Modularity in RHEL, when builds would take eons. This contains a bunch of dependencies of Dogtag. 2. pki-core, the core packages of Dogtag: - JSS - Tomcatjss - ldap-jdk - Dogtag PKI 3. The IPA module and its "DL1" stream. You can pull these three modules today on RHEL and try them out if you want. - The dependency tree is thus: IPA:DL1 -> pki-core:10.6 -> pki-deps:10.6 - What we had wished to do was provide two sets of module streams: pki-core @ 10.6 -- Dogtag at 10.6 version (in RHEL 8.0 only) pki-core @ 10.7 -- Dogtag at 10.7 version (in RHEL 8.1 only). Anyone who was using pki-core by itself could stay on 10.6 if they so desired (by staying on RHEL 8.0) or upgrade to 10.7 (by upgrading to RHEL 8.1). This allowed us, in the future, to support multiple versions on the same RHEL version if there were breaking changes between them. Since IPA is a monolith and wanted features in 10.7, it was going to switch to 10.7 in the new RHEL 8.1 release (out today!) because it wanted some things we introduced there. - Instead, since switching branches as described above wasn't supported, we ended up shipping our 10.7 version release in the (now incorrectly named) 10.6 branch. This means, on the whole, the pki-core module isn't netting us any value. It functions just like an ursine collection of packages with only a single version stream available. So to answer your question: > What happens if one of the packages you had installed wants to bump the > module stream of its dependency and another one doesn't? This was RHEL. We (the Dogtag / RHCS team at Red Hat) had full control over our package. We could choose to ship whatever version we want. That meant that we have to _work_ with other teams (in this case, exactly one: IPA) and ensure what we wanted to ship wouldn't break anything. Part of that was making sure we can switch streams. It turns out that, while we wanted to and got sign-off from IPA, the issue was a fundamental limitation in DNF. In RHEL, we know there is only one such dependent, IPA, and we can deal with that. In short, inside RHEL, we can take this as risk and control for it. In Fedora, it is harder and would require (packaging/FESCO/Modularity/...) policy to enforce. But it really _isn't_ a hard thing to do: limit it to Rawhide, require changes to be announced and coordinated (like SONAME bumps). Plus, inside RHEL, we could make reasonable support assumptions like, say, running an IPA server on the same system as $MythicalOtherUserOfDogtag wasn't supported. I'd argue we could (and should!) do the same in Fedora. In practice, t
Re: Modularity: The Official Complaint Thread
Neal Gompa wrote: > This list is fairly comprehensive, but one thing I think was missed is > that we lack a policy and mechanism for making buildroot-only packages > externally consumable. I think what we actually lack is a policy banning buildroot-only packages, period. > For example, the Rust modules in Fedora 30 actually have a > buildroot-only backport of RPM 4.15 Ewww! Building packages with a custom RPM is just plain unacceptable. If some addition to RPM is needed, it ought to be backported to the systemwide RPM package. Kevin Kofler ___ 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: Modularity: The Official Complaint Thread
Alex Scheel wrote: > Special care needs to be taken to make sure we discuss what happens > when a _module maintainer_ wants to switch the module stream of one > of its dependencies, especially a dependency the user never > specifically selected a stream for. That should be an allowed and fully > supported use case. > > This was the pki-core<->idm module fiasco that was never resolved by > DNF/Modularity. > > I'd post the bug number but the bug isn't public. > > > So perhaps split this into: > > 1. How does a _user_ change module streams during upgrade? > 2. How does the _maintainer_ change module streams of a dependent > module? (module a -dep-> module b -- change stream of b from 1 to 2) > > > IMO, without a resolution in Fedora we'll never get one in RHEL. Indeed, in Fedora, it is quite plausible for a package to be ported to a new major version of a library in an update. (In RHEL, it actually also is, but for different reasons, i.e., its extremely long lifetime.) But this shows how modules are the wrong answer for non-leaf packages. What happens if one of the packages you had installed wants to bump the module stream of its dependency and another one doesn't? Then suddenly, your system cannot be updated anymore, because the packages that previously coexisted just fine now irremediably conflict. (In fact, this is just a particularly nasty special case of the more general design flaw of Modularity that Stephen Gallagher has unfortunately forgotten in his list in the original post, the version conflicts caused by versioned dependencies without parallel installability. The special case is that the conflicts can also be introduced on updates to previously non-conflicting packages.) Providing incompatible versions of non-leaf packages MUST be done in a parallel-installable way. There is no other way out. Kevin Kofler ___ 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: Modularity and all the things
Randy Barlow wrote: > There's a second reason it's relevant to mention their 15 year track > record: if they've been doing it 15 years, and during that time there > haven't been significant complaints (there haven't), this indicates > that their solution has a good chance of working well. Actually, it could also mean that Gentoo users are just in a habit of not complaining, no matter what. :-) After all, those are the same users who find it perfectly fine that installing the kernel or LibreOffice takes days (at least in the early years). ;-) Kevin Kofler ___ 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: Modularity and all the things
Randy Barlow wrote: > I haven't used Nix before, so I can't comment on that one, but in what > way would Gentoo's solution require a substantial user experience > change? When Gentoo added it, the only user experience change for me > was when I wanted to pick a non-default slot (or as we call it, > stream). If I wasn't doing that, things just kept working they way they > had for years before that. It's still like that to this day - I only > have to know about Gentoo slots if I am trying to opt-in to some > version that isn't the default (the default in Gentoo is typically the > latest stable version). Actually, even if you don't opt in you are > likely to end up with a few packages parallel installing due to > dependencies pulling in different versions of things. The big difference is that Gentoo is source-based, whereas Fedora is binary- based. So where Gentoo needs to ship only one ebuild (the equivalent of a specfile) for foo-1.2.3 that the user can then compile against different choices of dependencies, we need to ship binary RPMs of that same foo-1.2.3 version for each and every combination (exponentially many) of dependency versions that we want to support. Which is one of the unsolved issues with our Modularity implementation, too. One solution would be to pick one combination of dependency versions and rely on parallel installation of the dependencies, but for that, we need not only a stream system, but also the file system layout tweaks of the parallel-installable Gentoo slots. For parallel installation, there are really only 2 solutions: 1. manually tweak things per package in the least invasive possible way (e.g., installing headers to /usr/include/qt5 rather than just /usr/include), as already done in compatibility packages, or 2. use a custom prefix under /opt, as is already done in SCLs. I think 1. is by far superior (even though it is more work), and AFAIK, FPC and FESCo mostly agree: in fact, Fedora ships packages that do 1., but not packages that do 2. (SCLs have basically been rejected in Fedora). langdon wrote: >> * compat-libs (or compat lib style): not discoverable, name mangling Randy Barlow replied: > Yeah I don't love this either. I don't understand why people dislike compatibility libraries so much. "not discoverable": How so? If you search for foo in Dnfdragora, you will automatically also find foo1. How is that "not discoverable"? In addition, compatibility libraries are usually used for non-leaf packages, which in most cases you don't want to install directly, but instead, whatever you actually want to install will automatically drag in the correct version. So there is nothing to "discover" in that case. "name mangling": Why is this a problem? First of all, it is not mangling, it is suffixing. The original name is retained unchanged and nothing is prepended to it, only appended. And, e.g., Qt 3, 4, and 5 are all different packages, so why should they have the same package name? I can understand people complaining about "mangling" if you do things the Debian way and append an soversion (not a human readable version, so the KDE 3 libraries end up as kdelibs4 and the KDE 4 libraries as kdelibs5!) to all libraries (even the default version), but that is not how compatibility libraries work in Fedora. I think that compatibility libraries are the much cleaner solution than any stream-based approach, be it module streams or Gentoo slots. Kevin Kofler ___ 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: Modularity and all the things
Hi Adam! On Tue, 2019-11-05 at 15:24 -0800, Adam Williamson wrote: > This has a few consequences I can think of. For a start it means the > actual problem we're currently having with our current module streams > wouldn't necessarily be solved by your system - we could've run into > exactly the same problem, more or less; the libgit2 package could've > declared a '0.27' stream in F29 and then decided that in F31 it > wanted > everyone on the '0.28' stream, or something like that. We still have > the potential problem of needing to define rules and implement > mechanisms for stream transitions at release boundaries, essentially. Yeah agreed, there does need to be a way to express what to do upon release boundaries. Though Gentoo does not have releases, they do still have "slots" that go from being "supported" to being unsupported (which is to say, dropped from the repository). I personally think this is somewhat similar to "upgrading from F29 to F31", with the obvious exception that in Gentoo there isn't a coordination point for *when* packages will do this. This means that on any given day, you could find out that the stream you are using is gone now. That's part of the fun of Gentoo! (I'm not saying we should do that). In Gentoo, when a package goes from supported to unsupported, you are going to have to switch to a supported slot/stream. Typically, the package manager does this for you (and it has notation on the upgrade command that shows you that you are switching slots so you can be informed.) Sometimes there can be conflicts, but I think "more conflicts" is just one of the consequences of allowing different packages to require conflicting dependencies (not every package in Gentoo is parallel installable, so you can hit conflicts this way.) I agree with you that "we have to decide what to do" is true here too. I think that having this one problem in common is OK though, given that I think it will be easier for our packagers to make use of it. > Another one - how does this work on the packaging end? Do I have some > sort of combinatorial explosion of dist-git branches for > "release+stream", so that if I introduce a stream called 'foo' I get > an an f29-foo git branch, an f30-foo git branch, an f31-foo git > branch and a master-foo git branch? Then I get another four branches > for each new stream? And each time a release comes out I get X new > branches, where X is the amount of streams that exist? Or would there > be another way to do it? Yeah this is a great question. I do think this problem is the same for modularity as it is for what I'm suggesting too, like the above problem. It's just that it splits the combinatorics between two dist- git repos instead of one. I can think of a few ways. I've actually been thinking about how our dist-git works a lot lately, and have some thoughts. So we could keep doing what modularity has done, where the branch names are the streams, and not Fedora versions. You don't strictly have to build a Fedora package from the given release today. I (rarely) have built the master branch for a stable release, because the spec file had nothing in it that was special for any particular Fedora version. So we could just have stream names as the branches, just like modularity already did, and then just point Koji at it with the build target you want (to get the matrix of Fedora versions). Or, we could do things more differently! In Gentoo, their spec files are called ebuilds, and you just put n ebuilds in the repo at a time, corresponding to the version of the package that the ebuild is for. Now, this results in some copying, which is certainly a drawback, but you could imagine naming the spec file with the stream as part of it or something like that. Here's an example: https://github.com/gentoo/gentoo/tree/master/dev-lang/python Or we could go crazy on the combinatorics with the stream and Fedora version, like you hinted at above (prob not ideal). Here's a neat idea though: there was also a thread a month or three ago where Jeremy Cline suggested using git tags to indicate the version, release, and even user facing update notes (in the tag message body). What if we extended that idea to also allow notating the stream and Fedora/EPEL version in the tag? Then, the meaning of the branches is completely up to the packager - they can devise a branching strategy that works for them, as they see fit, and they just tag certain commits, in any branch they please, with the FNESVR (Where F is the Fedora/EPEL version) that they want to turn that commit into. For packagers who want to put the same spec file in all branches today (I think Kevin Koffler often likes to do this), they can just maintain a master branch and not bother with all the merging, and just add a few tags to indicate the releases they want to go out. For packagers who are maintaining pretty divergent spec files for different Fedora/EPEL versions, or divergence due to streams, they can make the branches that m
Re: Modularity and all the things
On Tue, Nov 5, 2019 at 6:37 PM Randy Barlow wrote: > On Tue, 2019-11-05 at 14:14 -0500, Matthew Miller wrote: > > Well, exactly. This is what I meant with my short "who is going to do > > that work?" comment. Gentoo's solution is not a drop-in thing for > > Fedora and would require changes to RPM, DNF, and the *significant* > > work of figuring out what all this would mean in a binary-focused > > distribution. > > Modularity also required changes to these things, and more significant > changes. The fact that we're binary focused isn't relevant. What Gentoo > has done isn't related to where or how the software is compiled, it's > related to the repository and package metadata. > > > We'd certainly need a whole *new* MBS equivalent > > Why? > > > , and there's surely a ton of "unknown unknowns" lurking as well. > > Sure. > > > And then all of that would get us to... sort of where we are now? > > Where that would get us to is a system that very similar to the > "traditional" RPM system. This means that packagers and users will more > easily be able to learn how to use it. There won't be extra build > systems, dual spec and yaml files, or two kinds of packages. It will > all just be RPMs that are only minorly different than the RPMs we have > today. The only difference is that there would be a new Stream: field > in the spec file, in addition to the NEVRA we have today. So NEVRA > becomes NESVRA. > > Making a system that is familiar to packagers and users is advantageous > for adoption. > > > Basically the same thing as with Modularity's "virtual repositories" > > approach with different tradeoffs? > > No, every RPM would be in the same repos we make today. There would > just be more RPMs of the same package available in the repo than 1. > There would be 1 per stream (or more - Gentoo actually allows many > package versions per stream to be stable at a time, which is actually > their real solution to "parallel availability". Their slot is really > just a way to formalize a "set of package versions that are API > compatible", which is what we call a "stream"). > > > I don't feel bad at all about standing up for their wanting to > > continue to refine the path they've chosen and are working on. > > I don't think that's the message you've been sending. > > > If someone were to come by and say "I don't understand why you're > > doing all this, when it's been solved by AppImage since 2004", I'd > > say the same thing I'm telling Randy: you're welcome to work on that, > > but it's rude to tell the people who are invested in building > > something different that _they're_ the problem. > > It's worse than rude to say that I told people that _they're_ the > problem. I said no such thing. This is dishonest of you. > > > If that's demoralizing... well, I don't know what to to tell you. > > Your writing has been dismissive, dishonest, insulting, and belittling. > > > I want to support people doing things and exploring and contributing. > > Your writing is not consistent with this statement. Randy, I think you are misinterpreting Matthew’s statements here. You’re attributing malice and dismissiveness where “text is a poor communication medium” is a valid answer. I strongly doubt that Matthew (of all people!) is trying to insult anyone in Fedora. Could you try to reread his words, this time assuming he’s speaking in good faith and may not have communicated his points well? Because piling onto what I can reasonably guess is just a case of bad phrasing is bringing the conversation into a needlessly negative and personal space. > ___ > 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: Modularity and all the things
On Tue, 2019-11-05 at 14:14 -0500, Matthew Miller wrote: > Well, exactly. This is what I meant with my short "who is going to do > that work?" comment. Gentoo's solution is not a drop-in thing for > Fedora and would require changes to RPM, DNF, and the *significant* > work of figuring out what all this would mean in a binary-focused > distribution. Modularity also required changes to these things, and more significant changes. The fact that we're binary focused isn't relevant. What Gentoo has done isn't related to where or how the software is compiled, it's related to the repository and package metadata. > We'd certainly need a whole *new* MBS equivalent Why? > , and there's surely a ton of "unknown unknowns" lurking as well. Sure. > And then all of that would get us to... sort of where we are now? Where that would get us to is a system that very similar to the "traditional" RPM system. This means that packagers and users will more easily be able to learn how to use it. There won't be extra build systems, dual spec and yaml files, or two kinds of packages. It will all just be RPMs that are only minorly different than the RPMs we have today. The only difference is that there would be a new Stream: field in the spec file, in addition to the NEVRA we have today. So NEVRA becomes NESVRA. Making a system that is familiar to packagers and users is advantageous for adoption. > Basically the same thing as with Modularity's "virtual repositories" > approach with different tradeoffs? No, every RPM would be in the same repos we make today. There would just be more RPMs of the same package available in the repo than 1. There would be 1 per stream (or more - Gentoo actually allows many package versions per stream to be stable at a time, which is actually their real solution to "parallel availability". Their slot is really just a way to formalize a "set of package versions that are API compatible", which is what we call a "stream"). > I don't feel bad at all about standing up for their wanting to > continue to refine the path they've chosen and are working on. I don't think that's the message you've been sending. > If someone were to come by and say "I don't understand why you're > doing all this, when it's been solved by AppImage since 2004", I'd > say the same thing I'm telling Randy: you're welcome to work on that, > but it's rude to tell the people who are invested in building > something different that _they're_ the problem. It's worse than rude to say that I told people that _they're_ the problem. I said no such thing. This is dishonest of you. > If that's demoralizing... well, I don't know what to to tell you. Your writing has been dismissive, dishonest, insulting, and belittling. > I want to support people doing things and exploring and contributing. Your writing is not consistent with this statement. signature.asc Description: This is a digitally signed message part ___ 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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
On 11/5/19 4:59 PM, Kevin Kofler wrote: … and Calamares … ... and Domoticz (Fedora), and Kodi (RPMFusion)... Will this be as simple as a BR change in the spec or will application patches be necessary? ___ 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: Modularity and all the things
On Tue, 2019-11-05 at 17:55 -0500, Randy Barlow wrote: > To avoid the word "slot", what I'm saying is why not just add a > "Stream" field to the RPM spec file (so, instead of NEVR, it's NESVR), > and provide a way for users to specify which streams they want to > follow? So, a couple of thoughts on this. There's a constraint we have that Gentoo doesn't here: releases. Gentoo doesn't have releases. So, we have to consider how this stream system would interact with releases. This has a few consequences I can think of. For a start it means the actual problem we're currently having with our current module streams wouldn't necessarily be solved by your system - we could've run into exactly the same problem, more or less; the libgit2 package could've declared a '0.27' stream in F29 and then decided that in F31 it wanted everyone on the '0.28' stream, or something like that. We still have the potential problem of needing to define rules and implement mechanisms for stream transitions at release boundaries, essentially. Another one - how does this work on the packaging end? Do I have some sort of combinatorial explosion of dist-git branches for "release+stream", so that if I introduce a stream called 'foo' I get an f29-foo git branch, an f30-foo git branch, an f31-foo git branch and a master-foo git branch? Then I get another four branches for each new stream? And each time a release comes out I get X new branches, where X is the amount of streams that exist? Or would there be another way to do it? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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: Modularity and all the things
On Tue, Nov 5, 2019 at 5:57 PM Randy Barlow > > We (Stephen Gallagher and I) discussed me writing a blog post to > > revisit > > these past questions when Zbigniew raised the question the other > > day. > > However, I haven't written it yet. > > +1 > > Suggestion: could it be done as a page in the modularity documentation > instead of (or in addition to) a blog post? That would make it easier > to discover later if people wonder about these things. > > Extra suggestion: Stephen's requirements blog post would also be > excellent to archive in the modularity docs. Stephen, if you don't have > the time or inclination, I'd be happy to try to figure out how to get > it in there for you. We did in fact already do this! https://docs.fedoraproject.org/en-US/modularity/requirements/ ___ 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: Modularity: The Official Complaint Thread
On Tue, 2019-11-05 at 17:19 -0500, Stephen Gallagher wrote: > Others have contacted me privately and indicated that my choice of > words here did not convey the tone that I had intended. It makes it > sound as if I am accusing people of being disingenuous. For what it's worth, I didn't take it that way. It made me think that perhaps I did beg the question. I think what you wrote was OK. signature.asc Description: This is a digitally signed message part ___ 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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
Miro Hrončok wrote: > Only applications embedding Python need to link to libpython. That is what > software like krita or blender … and Calamares … > are most likely doing. Kevin Kofler ___ 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: Modularity and all the things
Thanks for writing this post Langdon! On Tue, 2019-11-05 at 12:55 -0500, langdon wrote: > * The two most promising candidates, Gentoo's slots (etc) and nix > both > require a substantial user experience change both as a command line > person and in how / where things land in the OS. We believe this to > be > an insurmountable change for Fedora users. Also, Gentoo's slots are > more > sophisticated than they were ~5 years ago when we started this > project > so they definitely appear more "tempting" now. I haven't used Nix before, so I can't comment on that one, but in what way would Gentoo's solution require a substantial user experience change? When Gentoo added it, the only user experience change for me was when I wanted to pick a non-default slot (or as we call it, stream). If I wasn't doing that, things just kept working they way they had for years before that. It's still like that to this day - I only have to know about Gentoo slots if I am trying to opt-in to some version that isn't the default (the default in Gentoo is typically the latest stable version). Actually, even if you don't opt in you are likely to end up with a few packages parallel installing due to dependencies pulling in different versions of things. It seems to me that modularity requires a similar interaction from the user when defaults are enabled. The user needs to learn how to use the set of dnf module subcommands. I see that as a pretty equivalent amount of user experience change between the two. Is there something more than this you are referring to with Gentoo? > * alternatives infra (for lack of a better name): doesn't really > solve > the problem of parallel availability without massive name mangling > and, > potentially, fragile symlinking around the system. I'm not familiar with this - could you describe it? > * many repos: considered to be non-performant in dnf (although that > has > gotten *much* better), very confusing for users, not discoverable. I suppose that Copr might fit into this category. I can't comment about performance other than I agree that all the repo metadata syncing could get slow, but for discoverability there is a dnf copr search subcommand. Curiously, I don't see a dnf module search subcommand, but I do see a list subcommand, which I suppose could be used with grep if there start to be too many. > * compat-libs (or compat lib style): not discoverable, name mangling Yeah I don't love this either. > * language specific lib management (e.g. rvm, virtualenv): > completely > different by language, preferred tool changing over time, led by > language communities (vs the distro) +1 > there are definitely others that I am not thinking of at the moment. > However, I wanted to try to get this out quickly. > > Basically, everything we looked at either, a) was a massive user > experience shift for Fedora users (way more than even some of the > broken > things we have in modularity). Could we get some expansion on this? It's not clear to me how adding slots to the RPM spec file to denote "streams" would necessarily result in a significantly different user experience in comparison to the user experience we have today with modularity (in terms of dnf commands - or are you thinking of other things when you say user experience?). To avoid the word "slot", what I'm saying is why not just add a "Stream" field to the RPM spec file (so, instead of NEVR, it's NESVR), and provide a way for users to specify which streams they want to follow? > Or, b) solved the problem in the "wrong" > part of the stack (in my opinion), meaning we should be able to do > this > in the package manager or "in the OS." I think the "Stream" field could be done in dnf, but you were probably referring to some of the other solutions considered. > However, Stephen's blog post > about the requirements is a way better treatise on the reasons why > the > alternatives didn't work. I am glad Stephen wrote that blog post, it was helpful. However, my reaction after reading it is still that adding a "Stream" field to the RPM Spec file could work and would be simpler for implementors and packagers. > We (Stephen Gallagher and I) discussed me writing a blog post to > revisit > these past questions when Zbigniew raised the question the other > day. > However, I haven't written it yet. +1 Suggestion: could it be done as a page in the modularity documentation instead of (or in addition to) a blog post? That would make it easier to discover later if people wonder about these things. Extra suggestion: Stephen's requirements blog post would also be excellent to archive in the modularity docs. Stephen, if you don't have the time or inclination, I'd be happy to try to figure out how to get it in there for you. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lis
Re: Modularity: The Official Complaint Thread
Stephen Gallagher writes: > My intention was to provide some scope to the problem, because it > seemed that a lot of alternatives being floated were not seeing some > of the more subtle cases that we were trying to address. However, the > biggest problem is that nearly every email to the list has been > started with a "Begging the Question" Fallacy. People have started > from the premise that "Modularity is Bad" and all of the rest of the > conversation has continued from there. I'd like to provide an > opportunity for us as a community to *constructively* state our > grievances with Modularity. The fundamental root cause of some of the > miscommunication is, I believe, that Modularity has problems and that > people have assumed that they are fundamental and unfixable. Your framing here precludes a complete redesign, and that option needs to be on the table for any real progress in communication and trust to be made. If others have "begged" that "modularity is bad", you have done the same for "modularity is good". > 2. Packages moved out of traditional Fedora and into a default module > stream are not available to the non-modular buildroot. [3] > > 3. Insufficient guidelines and rules have resulted in some modules > being shipped in a state that makes it difficult or impossible to > build other software for the distribution. In particular, the 'ant' > and 'maven' modules have default streams that own the namespace of > several of their dependencies that have been configured for private > use rather than public to the rest of the distrtibution. [4] 2 and 3 together, with some other factors, create a situation that there's no incentive for leaf packages to expose their dependencies to the core distribution. This results in both unnecessary duplication of work that could have been shared, and bloat (because we didn't need all the different versions of any particular package foo) that costs not just storage and builder time but also effort to monitor security-wise. (You can measure this in many different ways. For instance: does an ursine package exist? Is it usable? How many modules have a duplicate of it? How many modules have a newer version of it? etc.) Thanks, --Robbie signature.asc Description: PGP signature ___ 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: Trouble with install ordering and SELinux config
> Hi, > > It looks like some leftover from the past. I don't really see why it > should be there. > > This commit removes that: > > https://github.com/fedora-selinux/selinux-policy-macros/commit/5f366657da0c7c67f2448be03620581437c2dfbb > > Fixing it also in Rawhide and F31. Thanks a lot! Can it also happen for epel7 and 8? Pretty please :) Dridi ___ 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: Modularity: The Official Complaint Thread
On Tue, Nov 5, 2019 at 3:17 PM Stephen Gallagher wrote: > My intention was to provide some scope to the problem, because it > seemed that a lot of alternatives being floated were not seeing some > of the more subtle cases that we were trying to address. However, the > biggest problem is that nearly every email to the list has been > started with a "Begging the Question" Fallacy. People have started > from the premise that "Modularity is Bad" and all of the rest of the > conversation has continued from there. I'd like to provide an > opportunity for us as a community to *constructively* state our > grievances with Modularity. The fundamental root cause of some of the > miscommunication is, I believe, that Modularity has problems and that > people have assumed that they are fundamental and unfixable. Others have contacted me privately and indicated that my choice of words here did not convey the tone that I had intended. It makes it sound as if I am accusing people of being disingenuous. I had meant to indicate that we (as fallible humans) were falling into the "Begging the Question" Fallacy as we had pre-judged the situation and then proceeded to continue talking as if those judgements were forgone conclusions. I myself have been guilty of doing the same at times in those threads and have been actively attempting to catch myself when I do. My intention here was to help others notice the same of their own contributions. I do apologize if it came across as dismissive or accusatory. It can be difficult to convey intention over plaintext. For what it's worth, you can reasonably start reading the email from the following section and not be missing anything except my poorly-chosen lead-in. > I'd like to gather a constructive list of the actual use-cases that > you feel Modularity is causing problems for, with the following > stipulations: Any *subjective* problems will be ignored. "I think > writing YAML is harder than writing a spec file" is an example of a > subjective opinion. Similarly, "change inevitably results in some > learning curve" is a basic maxim of innovation and is not in and of > itself an argument not to change. "Modularity requires me to write > both a spec file and a YAML file, thereby increasing the total work" > is an *objective* observation (and a valid one; I'm going to include > it below in my own starter list). If you aren't sure if it's > objective, a useful question is "is it quantitatively measurable?" > (AKA "Can I assign a number to it and see that number increase or > decrease when changing something about the implementation?") ___ 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: Modularity and all the things
On Tue, 2019-11-05 at 14:57 -0500, Neal Gompa wrote: > Yeah, the reason OpenPKG was able to do this is because their flavor > of RPM had specific enhancements for it: > * Macros used in the spec had their definitions embedded into the > SRPM > * Generated package names and provides were discoverable from the > spec and SRPMs > * The dependency resolver could "install" source packages, build > them, > install the artifacts, and keep going I want to clarify that I'm not proposing that we become a non-binary distro. I think we can adapt the ideas that Gentoo and others* have employed while still shipping binary RPMs. That said, as a user of a source based distro, the idea of being able to take Fedora SRPMs and build a custom local build out of it is a neat idea, thanks for sharing. The thread a bit ago about using newer processor instructions is an example of a use case that someone might benefit from something like this. If you have a brand new processor and want to take advantage of the new instructions it can do, build your own SRPMs! * I talk about Gentoo a lot because I've been a user of that distro for a long time and have a lot of familiarity with it. I don't do so to the exclusion of how other distros have solved these problems, so please note that I equally welcome learning from Nix, Debian, or anyone else. signature.asc Description: This is a digitally signed message part ___ 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: Modularity and all the things
On Tue, 2019-11-05 at 12:11 -0500, Matthew Miller wrote: > But, I still am having a hard time seeing the thing I quoted as a > respectful > approach. I avoided paraphrasing before, but I'm going to now, not to > caricature what Randy said but to clarify how it sounds to me and > what I'm > reacting to. The message in entirety was: > >I've pointed out a few times that other distros have solved the > "too >fast, too slow" problem. In at least one case, as long ago as > 2004. I >see it as a solved problem and I don't understand why we are > trying to >solve it again. > > To, that isn't "hey, maybe you missed an elegant prior art we could > adapt". > To me, it seems to say "this effort is a waste of time -- this > problem is > already solved". You admit here that you are putting your own interpretation into it. Take that thought a step further and ask yourself what would be the right thing to do in a situation where you know you are spinning someone else's words? We all make mistakes like this in our heads when reading text, but the right thing for you to have done is to ask clarifying questions. "I am not sure what you mean here, can you explain further?" Instead, you assumed ill intent and proceeded down the dark path of this thread. > And mentioning "as long ago as 2004" seems ... well, like I said, > inflammatory. This means that Gentoo has 15 years of experience with providing multiple versions of software streams to their users. As I said in my last e-mail, it's the analogous "you can learn from the XSS vulnerabilities that Firefox has solved along the way". If they've been doing it for 15 years, they have expertise in this problem space and we can learn from that. There's a second reason it's relevant to mention their 15 year track record: if they've been doing it 15 years, and during that time there haven't been significant complaints (there haven't), this indicates that their solution has a good chance of working well. A solution that's faithfully served another community with the same problem statement for 15 years is surely worth learning from? How you got from "as long ago as 2004" to "Randy is disrespectful" is troubling. > This is not a respectful way to say this to the people who have put a > lot of > *years* into working on this problem and solving it in Fedora. Even > if we > take as given that other distros have solved the problem for their > users, it > being solved _there_ doesn't directly help us _here_. The work people > did to > get us to where we are now _does_. Nothing I've written in these threads is disrespectful. I've explained how studying the other distros' solutions helps us many times, and you have not replied to those explanations with any counters. signature.asc Description: This is a digitally signed message part ___ 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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
On 05. 11. 19 21:11, Neal Gompa wrote:
We need a way to autogenerate the the Python language ABI dependency
then. So far, no solution has been presented, and that needs to be
fixed before this can be implemented. Without that and no library
dependency, we have no way of knowing what to rebuild.
There are basically 3 cases I can think of:
A) you build an extension module into sitearch - ABI dependency is generated
B) you build anything that still links to libpython - dependency on specific
libpython3.X.so is generated
C) you build an extension module into custom directory - ABI dependency needs to
be manually added now
for C) we should generate the dependency based on filename
(*.cpython-38-{arch}-linux-gnu.so). but that would leave out cases where the
filename is "simply" foo.so. As such, we might be able to figure out it is a
Python extension by some other means.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Modularity and all the things
On Tue, Nov 5, 2019 at 8:15 PM Matthew Miller wrote: > > On Tue, Nov 05, 2019 at 01:08:23PM -0500, Neal Gompa wrote: > > I think I mentioned that it would be possible, as OpenPKG actually > > worked this way. > > > > The key for this would be improving the user-experience with > > interacting with source RPMs and spec files with DNF. We've optimized > > *heavily* for remote builds, but a good chunk of how Gentoo's > > mechanism works is built around supporting local permutations. We just > > don't have that fleshed out yet. > > Well, exactly. This is what I meant with my short "who is going to do that > work?" comment. Gentoo's solution is not a drop-in thing for Fedora and > would require changes to RPM, DNF, and the *significant* work of figuring > out what all this would mean in a binary-focused distribution. We'd > certainly need a whole *new* MBS equivalent, and there's surely a ton of > "unknown unknowns" lurking as well. > > And then all of that would get us to... sort of where we are now? Basically > the same thing as with Modularity's "virtual repositories" approach with > different tradeoffs? > > If someone thinks that my skepticism is wrong and that the Modularity team > is on the complete wrong path, I have no objection to anyone who wants to > work on something new solution, either as a prototype or a more detailed > proposal. Awesome! If it gets to the point where it's a viable alternative, > we can weigh those options. But the team in Fedora actually working on > Modularity today includes some pretty smart, very invested Fedora people and > I don't feel bad at all about standing up for their wanting to continue to > refine the path they've chosen and are working on. > > To me this is just like the Flatpak and Snap thing — both have some > strengths and weaknesses. I'm absolutely supportive of the effort of the > Workstation team (and Red Hat's Desktop team!) to drive that work in Fedora. > I happen to personally (and professionally) think that's good for Fedora. > But I'm _also_ happy to make room for you and whoever else to work on doing > something similar with Snap. > > If someone were to come by and say "I don't understand why you're doing all > this, when it's been solved by AppImage since 2004", I'd say the same thing > I'm telling Randy: you're welcome to work on that, but it's rude to tell the > people who are invested in building something different that _they're_ the > problem. > > If that's demoralizing... well, I don't know what to to tell you. I want to > support people doing things and exploring and contributing. That's all well and good, but you seem to be forgetting that people are actually getting *paid* to work on modularity for fedora. Any proposal for an alternative, which apparently needs to arrive at least at MVP / proof-of-concept quality before it is even *considered* as an alternative without getting called "trolling", can likely only be worked on in somebody's spare time. I don't think that's a fair requirement, and "exploring and contributing" will stay limited to RH employees if that's the case. Fabio > -- > Matthew Miller > > Fedora Project Leader > ___ > 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: Encrypted DNS in Fedora
Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit : > > > I don't agree with centralisation. You should run your own DoH > endpoint, > using Google's, Cloudflare's or Quad9's servers is a shortcut. DoH has zero integration and manageability. “It’s not centralized” (but you have to set manually DoH settings in all apps *or* rely on a centralized Google DoH whitelist) is an utter joke. Real decentralization means something like DHCP works on your own network. So you can run your own load balancers and all the other cool free software things that rely on name resolution. But if you delegate DoH endpoint selection to DHCP all the “protection” benefits of DoH vanish. Which just shows that the actual “protection” of DoH is giving the kingdom keys to a small centralized cartel of cloud companies (just like they gave the certificate keys to a small number of CA companies, and *that* was a brillant success). DoH works for people for whom network = Google + Chrome + Android. And useful idiots who find nowheristan’s police practices outrageous but turn a blind eye to the USA privatized surveillance state. The day DoH actually gets decentralized the nowheristan state and its ISPs will run DoH servers like everyone else and influence their results exactly like today, and the nowheristan population will use the result by default just like they use the state and ISP servers by default. Because that’s what decentralization actually means. Same thing as free software. You don’t get to choose who runs things — tech has no political opinions (neither does Google BTW, see: China). And the state has all the big guns, wherever you reside on Earth. Because the state not having all the big guns basically means any nutcake can butcher everyone around him with impunity (see: failed states). The only thing aggressive DoH migration gets you today is instant depreciation of Google competitors. And you may not like them, but you’ll like a world where Google has no remaining competitors even less. And all the money Google will make of DoH will serve to find ways to track and profile you even further. Regards, -- Nicolas Mailhot ___ 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: Modularity: The Official Complaint Thread
On Tue, Nov 5, 2019 at 3:22 PM Stephen Gallagher wrote: > > Last week, I put out a blog post and fedora-devel thread describing > the problems that we wanted to solve with Modularity. That thread was > not ultimately as successful as I had hoped. > > My intention was to provide some scope to the problem, because it > seemed that a lot of alternatives being floated were not seeing some > of the more subtle cases that we were trying to address. However, the > biggest problem is that nearly every email to the list has been > started with a "Begging the Question" Fallacy. People have started > from the premise that "Modularity is Bad" and all of the rest of the > conversation has continued from there. I'd like to provide an > opportunity for us as a community to *constructively* state our > grievances with Modularity. The fundamental root cause of some of the > miscommunication is, I believe, that Modularity has problems and that > people have assumed that they are fundamental and unfixable. > > I'd like to gather a constructive list of the actual use-cases that > you feel Modularity is causing problems for, with the following > stipulations: Any *subjective* problems will be ignored. "I think > writing YAML is harder than writing a spec file" is an example of a > subjective opinion. Similarly, "change inevitably results in some > learning curve" is a basic maxim of innovation and is not in and of > itself an argument not to change. "Modularity requires me to write > both a spec file and a YAML file, thereby increasing the total work" > is an *objective* observation (and a valid one; I'm going to include > it below in my own starter list). If you aren't sure if it's > objective, a useful question is "is it quantitatively measurable?" > (AKA "Can I assign a number to it and see that number increase or > decrease when changing something about the implementation?") > > So, in the interest of highlighting some specific cases where the > current, deployed[1] implementation (in no particular order): > This list is fairly comprehensive, but one thing I think was missed is that we lack a policy and mechanism for making buildroot-only packages externally consumable. For example, the Rust modules in Fedora 30 actually have a buildroot-only backport of RPM 4.15 to use generated build dependencies (which is likely to be something to disallow by policy for other reasons...), meaning that the modules are published with SRPMs that literally will not work on Fedora 30. There is no mechanism to consume buildroot-only packages for package builds on those modules and so on... There's no policy that defines what cases BR-only packages even make sense (I would argue that they don't for Fedora). But in cases like this, we need a way for those packages to be available when building on top of those modules or rebuilding them. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Modularity and all the things
On Tue, Nov 05, 2019 at 02:14:29PM -0500, Matthew Miller wrote: > If someone were to come by and say "I don't understand why you're doing all > this, when it's been solved by AppImage since 2004", I'd say the same thing > I'm telling Randy: you're welcome to work on that, but it's rude to tell the > people who are invested in building something different that _they're_ the > problem. > No, no, no. I'm not (and I don't think Randy is) saying _they're_ the problem. Commenting on an idea or project is *not* commenting on the person. Please do not imply I am doing so. There are communities where people attack people instead of the idea and those are toxic, unpleasant places. Fedora, thankfully, doesn't have too much of that. The problem Fedora has is that when you criticize a design or idea it's often conflated with a personal attack. Without feedback, how on earth are you going to make something anyone wants to use, though? I think this is in no small part responsible for the packaging experience we currently have. > If that's demoralizing... well, I don't know what to to tell you. I want to > support people doing things and exploring and contributing. > I too want to support doing things and exploring and contributing. If that means never providing constructive, critical reviews of that work, however, I'm not terribly interested in participating. ___ 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: Modularity: The Official Complaint Thread
- Original Message - > From: "Stephen Gallagher" > To: "Development discussions related to Fedora" > > Sent: Tuesday, November 5, 2019 3:17:28 PM > Subject: Modularity: The Official Complaint Thread ~snip~ > 1. Once enabled, a module stream is never changed on behalf of the > user. While this adds some strong guarantees to those who want to run > applications built from those streams, the presence of default streams > changes the expected upgrade behavior for users. Traditionally, at > upgrade a user would get the new release's most-updated version of all > packages currently on their system. With Modularity, if one of their > packages comes from a default stream and that stream is not the > default for the next release, they will stay on the current stream (or > be blocked from upgrading, if the current stream is unavailable on the > next release). [2] Special care needs to be taken to make sure we discuss what happens when a _module maintainer_ wants to switch the module stream of one of its dependencies, especially a dependency the user never specifically selected a stream for. That should be an allowed and fully supported use case. This was the pki-core<->idm module fiasco that was never resolved by DNF/Modularity. I'd post the bug number but the bug isn't public. So perhaps split this into: 1. How does a _user_ change module streams during upgrade? 2. How does the _maintainer_ change module streams of a dependent module? (module a -dep-> module b -- change stream of b from 1 to 2) IMO, without a resolution in Fedora we'll never get one in RHEL. - Alex ___ 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
Modularity: The Official Complaint Thread
Last week, I put out a blog post and fedora-devel thread describing the problems that we wanted to solve with Modularity. That thread was not ultimately as successful as I had hoped. My intention was to provide some scope to the problem, because it seemed that a lot of alternatives being floated were not seeing some of the more subtle cases that we were trying to address. However, the biggest problem is that nearly every email to the list has been started with a "Begging the Question" Fallacy. People have started from the premise that "Modularity is Bad" and all of the rest of the conversation has continued from there. I'd like to provide an opportunity for us as a community to *constructively* state our grievances with Modularity. The fundamental root cause of some of the miscommunication is, I believe, that Modularity has problems and that people have assumed that they are fundamental and unfixable. I'd like to gather a constructive list of the actual use-cases that you feel Modularity is causing problems for, with the following stipulations: Any *subjective* problems will be ignored. "I think writing YAML is harder than writing a spec file" is an example of a subjective opinion. Similarly, "change inevitably results in some learning curve" is a basic maxim of innovation and is not in and of itself an argument not to change. "Modularity requires me to write both a spec file and a YAML file, thereby increasing the total work" is an *objective* observation (and a valid one; I'm going to include it below in my own starter list). If you aren't sure if it's objective, a useful question is "is it quantitatively measurable?" (AKA "Can I assign a number to it and see that number increase or decrease when changing something about the implementation?") So, in the interest of highlighting some specific cases where the current, deployed[1] implementation (in no particular order): 1. Once enabled, a module stream is never changed on behalf of the user. While this adds some strong guarantees to those who want to run applications built from those streams, the presence of default streams changes the expected upgrade behavior for users. Traditionally, at upgrade a user would get the new release's most-updated version of all packages currently on their system. With Modularity, if one of their packages comes from a default stream and that stream is not the default for the next release, they will stay on the current stream (or be blocked from upgrading, if the current stream is unavailable on the next release). [2] 2. Packages moved out of traditional Fedora and into a default module stream are not available to the non-modular buildroot. [3] 3. Insufficient guidelines and rules have resulted in some modules being shipped in a state that makes it difficult or impossible to build other software for the distribution. In particular, the 'ant' and 'maven' modules have default streams that own the namespace of several of their dependencies that have been configured for private use rather than public to the rest of the distrtibution. [4] 4. Documentation of how to create a module stream is comprehensive but daunting. There is a lot of available information, but what is really lacking is a basic walkthrough for converting a single package to a module stream. 5. There is no specification defined for dropping a default or enabled module stream and returning to non-modular packages. 6. We don't provide a direct solution for parallel-installability. This is an intentional design decision, but it *is* arguably a regression from SCL functionality, so I'll include it here. 7. The implementation in DNF occurs in libdnf rather than at the libsolv layer, which makes it difficult to reimplement for other packaging or build tools (such as GNOME Software and OBS, resp.) 8. The YAML format for modulemd is complex and can be difficult to get started with. [5] [6] 9. We don't have a good document on how to MBS generates modules and their repositories. This makes it hard for other build-systems to replicate the behavior. [7] 10. The MBS has performance issues which make official builds take a long time. [8] 11. "Module Stream API" when used in a default stream causes package incompatibilities and unsupportable configurations. [4] 12. Packaging a module requires writing both a spec file and a modulemd YAML file, which increases the total amount of work I need to do. [5] I'm sure there are other pain points and I encourage you to share them. Please adhere to the guidelines about objectively measurable issues, though. --- [1] I'll highlight with a [N] any of the cases I list that have a non-deployed fix, mitigation or are under design. [2] This is an identified user-experience issue and is under active design discussion on other threads. Please do not rehash that here. Some of the options being considered are: - Record whether the user "locked" themselves on a stream or had it enabled because it happened to be the default stream
Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
On Tue, Nov 5, 2019 at 2:17 PM Miro Hrončok wrote: > > On 05. 11. 19 19:41, Kevin Kofler wrote: > >> Python 3 traditionally in Fedora was built with a shared library > >> libpython3.?.so and the final binary was dynamically linked against > >> that shared library. This change is about creating the static library > >> and linking the final python3 binary against it, > > > > I oppose this change, because this is yet another size increase: > > It is a trade. Performance vs. size. Some use cases will not gain more > performance, but most will. Some use cases will be affected by the size > increase, but mos won't. Details below. > > That said, it is a fair point. When Fedora decides whether to do this, this > needs to be considered. > > >> As a negative side effect, when both libpython3.8.so and > >> /usr/bin/python3.8 are installed, the filesystem footprint will be > >> slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M). > > > > and while: > > > >> OTOH only a very small amount of packages will depend on > >> libpython3.8.so. > > > > in practice, that does not help because some of those packages are installed > > by default, e.g., the ones you mentioned being installed by default even on > > the Docker image: > > > >> *'''libcomps''' > >> *'''libdnf''' > >> *'''vim''' > > I haven't checked vim (but work can be done to get rid of the dependency, it > is > vim-minimal -> libpython). For the dnf stack, is is mostly a matter of > adapting > the cmake files to not link extension modules to libpython. An example: > > https://src.fedoraproject.org/rpms/libarcus/pull-request/8 > > Not being able to make the packages listed in bold libpython-less is a problem > that would activate the contingency plan (revert). > > > but there are more, such as gdb, libreoffice, krita, boost, etc. that are > > installed on various live images, and calamares, which is popular on > > remixes. So all those images will be bloated as a result of your code > > duplicating change. > > gdb Python support is optional. > > krita is IMHO big enough to not notice the filesize increase. > > So is libreoffice, but in fact only libreoffice-pyuno is doing this and it > might > be adapted or the dependency of libreoffice on libreoffice-pyuno might be made > optional. > > For boost, only the Python modules are affected and I'm confident it's the > same > problem as in the most of the rest of the list. > > Extension modules should not link to libpython. Packages need to be adapted. > > Only applications embedding Python need to link to libpython. That is what > software like krita or blender are most likely doing. > > > In addition: > > > >> By applying this change, libpython's namespace will be separated from > >> Python's, so '''C extension which are still linked to libpython''' > >> might experience side effects or break. > > > > so compatibility is an issue too. > > It is an issue. We will look into this issue and provide help fixing the > affected software. Python extension modules should not link to libpython and > the > packages need to be adapted not to do that. > We need a way to autogenerate the the Python language ABI dependency then. So far, no solution has been presented, and that needs to be fixed before this can be implemented. Without that and no library dependency, we have no way of knowing what to rebuild. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Modularity and all the things
On Tue, Nov 5, 2019 at 2:15 PM Matthew Miller wrote: > > On Tue, Nov 05, 2019 at 01:08:23PM -0500, Neal Gompa wrote: > > I think I mentioned that it would be possible, as OpenPKG actually > > worked this way. > > > > The key for this would be improving the user-experience with > > interacting with source RPMs and spec files with DNF. We've optimized > > *heavily* for remote builds, but a good chunk of how Gentoo's > > mechanism works is built around supporting local permutations. We just > > don't have that fleshed out yet. > > Well, exactly. This is what I meant with my short "who is going to do that > work?" comment. Gentoo's solution is not a drop-in thing for Fedora and > would require changes to RPM, DNF, and the *significant* work of figuring > out what all this would mean in a binary-focused distribution. We'd > certainly need a whole *new* MBS equivalent, and there's surely a ton of > "unknown unknowns" lurking as well. > Yeah, the reason OpenPKG was able to do this is because their flavor of RPM had specific enhancements for it: * Macros used in the spec had their definitions embedded into the SRPM * Generated package names and provides were discoverable from the spec and SRPMs * The dependency resolver could "install" source packages, build them, install the artifacts, and keep going > And then all of that would get us to... sort of where we are now? Basically > the same thing as with Modularity's "virtual repositories" approach with > different tradeoffs? > I think we'd have an easier time if modularity was merely just virtual repositories. As it stands, it has a lot more, which has a lot of interesting consequences... -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: scribus-generator now provides python2-tkinter in Fedora 30 ?
On 11/5/19 4:36 AM, Felix Schwarz wrote: > Am 05.11.19 um 10:05 schrieb Zbigniew Jędrzejewski-Szmek: >> That seems to be a bug. > > Ok, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1768831 > (Hopefully we can get this fixed asap because we won't be able to fix this > automatically once python2-tkinter was removed in existing installs.) > > Felix If you need a workaround right now, I was able to reinstall python2-tkinter by first installing the versionlock plugin (python3-dnf-plugin-versionlock) and running dnf versionlock exclude scribus-generator dnf versionlock exclude scribus which prevented the current, broken versions of scribus from getting installed. -Mat ___ 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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
On 05. 11. 19 19:41, Kevin Kofler wrote: Python 3 traditionally in Fedora was built with a shared library libpython3.?.so and the final binary was dynamically linked against that shared library. This change is about creating the static library and linking the final python3 binary against it, I oppose this change, because this is yet another size increase: It is a trade. Performance vs. size. Some use cases will not gain more performance, but most will. Some use cases will be affected by the size increase, but mos won't. Details below. That said, it is a fair point. When Fedora decides whether to do this, this needs to be considered. As a negative side effect, when both libpython3.8.so and /usr/bin/python3.8 are installed, the filesystem footprint will be slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M). and while: OTOH only a very small amount of packages will depend on libpython3.8.so. in practice, that does not help because some of those packages are installed by default, e.g., the ones you mentioned being installed by default even on the Docker image: *'''libcomps''' *'''libdnf''' *'''vim''' I haven't checked vim (but work can be done to get rid of the dependency, it is vim-minimal -> libpython). For the dnf stack, is is mostly a matter of adapting the cmake files to not link extension modules to libpython. An example: https://src.fedoraproject.org/rpms/libarcus/pull-request/8 Not being able to make the packages listed in bold libpython-less is a problem that would activate the contingency plan (revert). but there are more, such as gdb, libreoffice, krita, boost, etc. that are installed on various live images, and calamares, which is popular on remixes. So all those images will be bloated as a result of your code duplicating change. gdb Python support is optional. krita is IMHO big enough to not notice the filesize increase. So is libreoffice, but in fact only libreoffice-pyuno is doing this and it might be adapted or the dependency of libreoffice on libreoffice-pyuno might be made optional. For boost, only the Python modules are affected and I'm confident it's the same problem as in the most of the rest of the list. Extension modules should not link to libpython. Packages need to be adapted. Only applications embedding Python need to link to libpython. That is what software like krita or blender are most likely doing. In addition: By applying this change, libpython's namespace will be separated from Python's, so '''C extension which are still linked to libpython''' might experience side effects or break. so compatibility is an issue too. It is an issue. We will look into this issue and provide help fixing the affected software. Python extension modules should not link to libpython and the packages need to be adapted not to do that. Only Python extension modules that embed Python will truly be problematic to handle. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Modularity and all the things
On Tue, Nov 05, 2019 at 01:08:23PM -0500, Neal Gompa wrote: > I think I mentioned that it would be possible, as OpenPKG actually > worked this way. > > The key for this would be improving the user-experience with > interacting with source RPMs and spec files with DNF. We've optimized > *heavily* for remote builds, but a good chunk of how Gentoo's > mechanism works is built around supporting local permutations. We just > don't have that fleshed out yet. Well, exactly. This is what I meant with my short "who is going to do that work?" comment. Gentoo's solution is not a drop-in thing for Fedora and would require changes to RPM, DNF, and the *significant* work of figuring out what all this would mean in a binary-focused distribution. We'd certainly need a whole *new* MBS equivalent, and there's surely a ton of "unknown unknowns" lurking as well. And then all of that would get us to... sort of where we are now? Basically the same thing as with Modularity's "virtual repositories" approach with different tradeoffs? If someone thinks that my skepticism is wrong and that the Modularity team is on the complete wrong path, I have no objection to anyone who wants to work on something new solution, either as a prototype or a more detailed proposal. Awesome! If it gets to the point where it's a viable alternative, we can weigh those options. But the team in Fedora actually working on Modularity today includes some pretty smart, very invested Fedora people and I don't feel bad at all about standing up for their wanting to continue to refine the path they've chosen and are working on. To me this is just like the Flatpak and Snap thing — both have some strengths and weaknesses. I'm absolutely supportive of the effort of the Workstation team (and Red Hat's Desktop team!) to drive that work in Fedora. I happen to personally (and professionally) think that's good for Fedora. But I'm _also_ happy to make room for you and whoever else to work on doing something similar with Snap. If someone were to come by and say "I don't understand why you're doing all this, when it's been solved by AppImage since 2004", I'd say the same thing I'm telling Randy: you're welcome to work on that, but it's rude to tell the people who are invested in building something different that _they're_ the problem. If that's demoralizing... well, I don't know what to to tell you. I want to support people doing things and exploring and contributing. -- Matthew Miller Fedora Project Leader ___ 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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
On Tue, 2019-11-05 at 19:41 +0100, Kevin Kofler wrote: > > Python 3 traditionally in Fedora was built with a shared library > > libpython3.?.so and the final binary was dynamically linked against > > that shared library. This change is about creating the static library > > and linking the final python3 binary against it, > > I oppose this change, because this is yet another size increase: Up to ~27% speed increase for extra ~3.4 MB storage used seems like a good trade-off to me... > > > As a negative side effect, when both libpython3.8.so and > > /usr/bin/python3.8 are installed, the filesystem footprint will be > > slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M). > > and while: > > > OTOH only a very small amount of packages will depend on > > libpython3.8.so. > > in practice, that does not help because some of those packages are installed > by default, e.g., the ones you mentioned being installed by default even on > the Docker image: > > > *'''libcomps''' > > *'''libdnf''' > > *'''vim''' > > but there are more, such as gdb, libreoffice, krita, boost, etc. that are > installed on various live images, and calamares, which is popular on > remixes. So all those images will be bloated as a result of your code > duplicating change. > > > In addition: > > > By applying this change, libpython's namespace will be separated from > > Python's, so '''C extension which are still linked to libpython''' > > might experience side effects or break. > > so compatibility is an issue too. > > Kevin Kofler > ___ > 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: Encrypted DNS in Fedora
On Tue, Nov 05, 2019 at 03:07:53PM +0100, Marius Schwarz wrote: > > I personally favor DoT as it would make use of the millions of dns > server available on the net. DoH is too centralized to implement for now. > I don't agree with centralisation. You should run your own DoH endpoint, using Google's, Cloudflare's or Quad9's servers is a shortcut. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) ___ 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: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
> Python 3 traditionally in Fedora was built with a shared library > libpython3.?.so and the final binary was dynamically linked against > that shared library. This change is about creating the static library > and linking the final python3 binary against it, I oppose this change, because this is yet another size increase: > As a negative side effect, when both libpython3.8.so and > /usr/bin/python3.8 are installed, the filesystem footprint will be > slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M). and while: > OTOH only a very small amount of packages will depend on > libpython3.8.so. in practice, that does not help because some of those packages are installed by default, e.g., the ones you mentioned being installed by default even on the Docker image: > *'''libcomps''' > *'''libdnf''' > *'''vim''' but there are more, such as gdb, libreoffice, krita, boost, etc. that are installed on various live images, and calamares, which is popular on remixes. So all those images will be bloated as a result of your code duplicating change. In addition: > By applying this change, libpython's namespace will be separated from > Python's, so '''C extension which are still linked to libpython''' > might experience side effects or break. so compatibility is an issue too. Kevin Kofler ___ 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: Modularity and all the things
On Tue, Nov 5, 2019 at 12:58 PM Jeremy Cline wrote: > > On Tue, Nov 05, 2019 at 12:11:56PM -0500, Matthew Miller wrote: > > On Tue, Nov 05, 2019 at 04:34:55PM +, Jeremy Cline wrote: > > > I'd just like to say that I have found this thread very demoralizing. I > > > think Randy has valid points and has brought them up far more > > > respectfully than I could and I feel like it's being dismissed as > > > trolling. I think this has a very negative affect on people's > > > willingness to put their opinions out there and is going to lead to an > > > echo chamber. > > > > It's definitely gone of the rails, and I'm sorry. I didn't mean for that to > > happen. I want to hear people's opinions even if they're dissenting. > > > > But, I still am having a hard time seeing the thing I quoted as a respectful > > approach. I avoided paraphrasing before, but I'm going to now, not to > > caricature what Randy said but to clarify how it sounds to me and what I'm > > reacting to. The message in entirety was: > > > >I've pointed out a few times that other distros have solved the "too > >fast, too slow" problem. In at least one case, as long ago as 2004. I > >see it as a solved problem and I don't understand why we are trying to > >solve it again. > > > > To, that isn't "hey, maybe you missed an elegant prior art we could adapt". > > To me, it seems to say "this effort is a waste of time -- this problem is > > already solved". > > > > And mentioning "as long ago as 2004" seems ... well, like I said, > > inflammatory. > > > > This is not a respectful way to say this to the people who have put a lot of > > *years* into working on this problem and solving it in Fedora. Even if we > > take as given that other distros have solved the problem for their users, it > > being solved _there_ doesn't directly help us _here_. The work people did to > > get us to where we are now _does_. > > > > I've seen Randy ask multiple times why Gentoo's approach won't work for > us, specifically, and I've seen zero responses (apologies if I've missed > them across all the threads). > I think I mentioned that it would be possible, as OpenPKG actually worked this way. The key for this would be improving the user-experience with interacting with source RPMs and spec files with DNF. We've optimized *heavily* for remote builds, but a good chunk of how Gentoo's mechanism works is built around supporting local permutations. We just don't have that fleshed out yet. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Modularity and all the things
On Tue, Nov 05, 2019 at 12:11:56PM -0500, Matthew Miller wrote: > On Tue, Nov 05, 2019 at 04:34:55PM +, Jeremy Cline wrote: > > I'd just like to say that I have found this thread very demoralizing. I > > think Randy has valid points and has brought them up far more > > respectfully than I could and I feel like it's being dismissed as > > trolling. I think this has a very negative affect on people's > > willingness to put their opinions out there and is going to lead to an > > echo chamber. > > It's definitely gone of the rails, and I'm sorry. I didn't mean for that to > happen. I want to hear people's opinions even if they're dissenting. > > But, I still am having a hard time seeing the thing I quoted as a respectful > approach. I avoided paraphrasing before, but I'm going to now, not to > caricature what Randy said but to clarify how it sounds to me and what I'm > reacting to. The message in entirety was: > >I've pointed out a few times that other distros have solved the "too >fast, too slow" problem. In at least one case, as long ago as 2004. I >see it as a solved problem and I don't understand why we are trying to >solve it again. > > To, that isn't "hey, maybe you missed an elegant prior art we could adapt". > To me, it seems to say "this effort is a waste of time -- this problem is > already solved". > > And mentioning "as long ago as 2004" seems ... well, like I said, > inflammatory. > > This is not a respectful way to say this to the people who have put a lot of > *years* into working on this problem and solving it in Fedora. Even if we > take as given that other distros have solved the problem for their users, it > being solved _there_ doesn't directly help us _here_. The work people did to > get us to where we are now _does_. > I've seen Randy ask multiple times why Gentoo's approach won't work for us, specifically, and I've seen zero responses (apologies if I've missed them across all the threads). Other folks are highlighting how people have been working on Modularity for years so I don't think highlighting that there's been prior art that does seem to check every box around for *15 years* is particularly inflammatory. Could the sentence have been intelligible without it? Sure, but it certainly doesn't feel like a valid reason to discard a whole solution, nor does it feel like you're assuming positive intent here. As I said, this is all very demoralizing and this kind of stuff is why I've stopped involving myself in Fedora things outside of my direct work responsibilities. - Jeremy ___ 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: Modularity and all the things
On 10/25/19 10:15 AM, Randy Barlow wrote: On Fri, 2019-10-25 at 09:43 +0200, Pierre-Yves Chibon wrote: That is true, but the wording used also implied that this design has not been considered. The question of whether other designs have been considered has been raised many times over the years, and I've not seen it claimed that yes, these specific designs were considered and were rejected. I also don't see it documented at https://docs.fedoraproject.org/en-US/modularity that these suggested ideas were considered. If people keep asking if these designs were considered and don't get answers, it does become reasonable to think that maybe they weren't. We reviewed *many* alternate / existing solutions to this problem both at the start and over the course of the project. In fact, I have given talks on these reviews at various conferences (IIRC flock, fosdem, and devconf.cz). Off the top of my head: * The two most promising candidates, Gentoo's slots (etc) and nix both require a substantial user experience change both as a command line person and in how / where things land in the OS. We believe this to be an insurmountable change for Fedora users. Also, Gentoo's slots are more sophisticated than they were ~5 years ago when we started this project so they definitely appear more "tempting" now. * alternatives infra (for lack of a better name): doesn't really solve the problem of parallel availability without massive name mangling and, potentially, fragile symlinking around the system. * many repos: considered to be non-performant in dnf (although that has gotten *much* better), very confusing for users, not discoverable. * compat-libs (or compat lib style): not discoverable, name mangling * language specific lib management (e.g. rvm, virtualenv): completely different by language, preferred tool changing over time, led by language communities (vs the distro) there are definitely others that I am not thinking of at the moment. However, I wanted to try to get this out quickly. Basically, everything we looked at either, a) was a massive user experience shift for Fedora users (way more than even some of the broken things we have in modularity). Or, b) solved the problem in the "wrong" part of the stack (in my opinion), meaning we should be able to do this in the package manager or "in the OS." However, Stephen's blog post about the requirements is a way better treatise on the reasons why the alternatives didn't work. We (Stephen Gallagher and I) discussed me writing a blog post to revisit these past questions when Zbigniew raised the question the other day. However, I haven't written it yet. ___ 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: Modularity and all the things
On Tue, Nov 05, 2019 at 04:34:55PM +, Jeremy Cline wrote: > I'd just like to say that I have found this thread very demoralizing. I > think Randy has valid points and has brought them up far more > respectfully than I could and I feel like it's being dismissed as > trolling. I think this has a very negative affect on people's > willingness to put their opinions out there and is going to lead to an > echo chamber. It's definitely gone of the rails, and I'm sorry. I didn't mean for that to happen. I want to hear people's opinions even if they're dissenting. But, I still am having a hard time seeing the thing I quoted as a respectful approach. I avoided paraphrasing before, but I'm going to now, not to caricature what Randy said but to clarify how it sounds to me and what I'm reacting to. The message in entirety was: I've pointed out a few times that other distros have solved the "too fast, too slow" problem. In at least one case, as long ago as 2004. I see it as a solved problem and I don't understand why we are trying to solve it again. To, that isn't "hey, maybe you missed an elegant prior art we could adapt". To me, it seems to say "this effort is a waste of time -- this problem is already solved". And mentioning "as long ago as 2004" seems ... well, like I said, inflammatory. This is not a respectful way to say this to the people who have put a lot of *years* into working on this problem and solving it in Fedora. Even if we take as given that other distros have solved the problem for their users, it being solved _there_ doesn't directly help us _here_. The work people did to get us to where we are now _does_. That's what I take objection to, not the suggestion of additional ideas to move us forward. -- Matthew Miller Fedora Project Leader ___ 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
Jenkins plugin upgrade to change from fedmsg to fedora-messaging
Hello Fedora CI and Devel Teams! The CI team will be performing a Jenkins plugin upgrade this Thursday to allow us to switch from fedmsg to fedora-messaging. While performing this upgrade, dist-git tests will be temporarily unavailable. When the upgrade is complete and things appear good, we will reply-all here. Please note that this is simply an upgrade to the plugin itself; while it allows the use of the fedora-messaging bus, we will continue to use fedmsg after the upgrade to validate plugin stability. If all goes well, our plan is to switch to fedora-messaging next week (tentatively on Wednesday the 13th). If you have any questions or concerns, by all means please reach out to me. Thank you! -Jim Bair ___ 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 1768810] perl-XML-Namespace for EL8
https://bugzilla.redhat.com/show_bug.cgi?id=1768810 Petr Pisar changed: What|Removed |Added Status|NEW |ASSIGNED CC|ppi...@redhat.com | --- Comment #1 from Petr Pisar --- https://pagure.io/releng/fedora-scm-requests/issue/19355 https://pagure.io/releng/fedora-scm-requests/issue/19356 -- 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
NeuroFedora team meeting logs: 1600 UTC on Tuesday, 5th November
Hello, Please find the logs from today's NeuroFedora team meeting below: - Logs (HTML): https://meetbot.fedoraproject.org/fedora-neuro/2019-11-05/neurofedora.2019-11-05-16.03.log.html - Minute (HTML): https://meetbot.fedoraproject.org/fedora-neuro/2019-11-05/neurofedora.2019-11-05-16.03.html The text minutes are pasted below for your convenience. The next meeting will be at the same time next week, and it will be chaired by @bt0dotninja. === #fedora-neuro: NeuroFedora - 2019-11-05 === Meeting started by FranciscoD at 16:03:35 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-neuro/2019-11-05/neurofedora.2019-11-05-16.03.log.html . Meeting summary --- * Agenda (FranciscoD, 16:04:32) * Introductions and roll call (FranciscoD, 16:05:01) * Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting (FranciscoD, 16:05:12) * Bugs: https://tinyurl.com/neurofedora-bugs (FranciscoD, 16:05:20) * Action items from last meeting (FranciscoD, 16:05:30) * Some neuroscience (FranciscoD, 16:05:43) * Next meeting time/chair (FranciscoD, 16:05:48) * Open floor (FranciscoD, 16:05:52) * Introductions/roll calls (FranciscoD, 16:06:00) * Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting (FranciscoD, 16:09:02) * Issue #307: NeuroFedora at FOSDEM 2020. - NeuroFedora - Pagure.io: https://pagure.io/neuro-sig/NeuroFedora/issue/307 (FranciscoD, 16:09:26) * Flock slides are neuroscience heavy---need tailoring to target audience (FranciscoD, 16:11:15) * ACTION: MeWjOr note tweaks we require to slides for FOSDEM (FranciscoD, 16:12:20) * 20 minute talk should be sufficient for FOSDEM (FranciscoD, 16:12:39) * Flock slides: https://github.com/neurofedora/2019-flock-neurofedora (FranciscoD, 16:19:43) * OSB workshop slides: https://github.com/neurofedora/201909-OSB-neurofedora (FranciscoD, 16:19:51) * CNS abstract: https://github.com/neurofedora/2019CNS-neurofedora-abstract (FranciscoD, 16:20:02) * ACTION: FranciscoD send edit link to team (FranciscoD, 16:20:24) * Skipping brochure ticket: WIP (FranciscoD, 16:23:09) * Skipping badges ticket: still blocked at badges (FranciscoD, 16:23:21) * Issue #311: Move neuroscience planets to NeuroFedora - NeuroFedora - Pagure.io: https://pagure.io/neuro-sig/NeuroFedora/issue/311 (FranciscoD, 16:23:33) * ACTION: FranciscoD try pelican alias plugin and see what can be done (FranciscoD, 16:34:15) * worse case scenario, we break the URL for some people (FranciscoD, 16:34:37) * ACTION: FranciscoD update ticket with info (FranciscoD, 16:35:23) * NeuroFedora bugs: https://tinyurl.com/neurofedora-bugs (FranciscoD, 16:35:56) * Bugs are in good shape, nothing urgent (FranciscoD, 16:36:39) * Everyone, please keep packaging up tools from our list (FranciscoD, 16:37:50) * Action items from last meeting (FranciscoD, 16:37:57) * FranciscoD tweak abstract draft for FOSDEM -> MeWjOr is taking a look (FranciscoD, 16:38:16) * MeWjOr go through current slide sets -> DONE (FranciscoD, 16:38:25) * MeWjOr ping FOSDEM booth thread asking for someone to take the lead so they can help -> DONE (FranciscoD, 16:38:32) * MeWjOr work on #308 -> DONE: New image has been publicised: https://neuroblog.fedoraproject.org/2019/11/05/neurofedora-computational-neuroscience-iso-image-is-now-available.html (FranciscoD, 16:39:29) * Some neuroscience? (FranciscoD, 16:39:44) * No neuroscience to discuss today :( :( :( (FranciscoD, 16:41:13) * Next meeting chair (FranciscoD, 16:41:22) * ACTION: bt0 to chair next meeting: send reminder on Friday, send out logs after meeting etc (FranciscoD, 16:42:28) * ACTION: FranciscoD send out meeting logs (FranciscoD, 16:42:33) * Open Floor (FranciscoD, 16:42:38) Meeting ended at 16:45:22 UTC. Action Items * MeWjOr note tweaks we require to slides for FOSDEM * FranciscoD send edit link to team * FranciscoD try pelican alias plugin and see what can be done * FranciscoD update ticket with info * bt0 to chair next meeting: send reminder on Friday, send out logs after meeting etc * FranciscoD send out meeting logs Action Items, by person --- * bt0 * bt0 to chair next meeting: send reminder on Friday, send out logs after meeting etc * FranciscoD * FranciscoD send edit link to team * FranciscoD try pelican alias plugin and see what can be done * FranciscoD update ticket with info * FranciscoD send out meeting logs * MeWjOr * MeWjOr note tweaks we require to slides for FOSDEM * **UNASSIGNED** * (none) People Present (lines said) --- * FranciscoD (126) * MeWjOr (45) * zodbot (15) * bt0 (11) * alciregi (0) * LoKoMurdoK (0) * gicmo (
Re: Trouble with install ordering and SELinux config
On 11/3/19 9:38 AM, Dridi Boukelmoune wrote:
> On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
>>
>> On 11/1/19 1:47 PM, Daniel Walsh wrote:
>>> Flat pack should be doing a requires(post): selinux-policy-base
>>>
>>> To make sure it is installed before flatpack.
>>
>> Thanks. The proper incantation actually though seems to be:
>>
>> %{?selinux_requires}
>>
>> which contains that. See:
>>
>> https://fedoraproject.org/wiki/SELinux/IndependentPolicy#The_Preamble
>
> I have used this successfully for EPEL 7 work at $DAYJOB and woud have
> pointed this out earlier if I hadn't fallen off the devel list for the
> past few weeks.
>
> Revisiting this on Fedora 31 I still see this:
>
> $ rpm --eval %selinux_requires | grep git
> BuildRequires: git
>
> And I can't help but wonder whether we really need git at build time
> as this slows down the build root creation step.
>
> Any idea from SELinux folks?
>
Hi,
It looks like some leftover from the past. I don't really see why it
should be there.
This commit removes that:
https://github.com/fedora-selinux/selinux-policy-macros/commit/5f366657da0c7c67f2448be03620581437c2dfbb
Fixing it also in Rawhide and F31.
Thanks,
Lukas.
> Thanks,
> Dridi
>
>> This works because the selinux-policy-base providing packages have a:
>>
>> Requires(pre): selinux-policy
>>
>> which pushes that earlier. I'm still not entirely convinced that that
>> creates a contract that selinux-policy's %post script will be run before
>> the flatpak-selinux's %post script, but hopefully in practice it won't
>> matter.
>>
>> I've created https://src.fedoraproject.org/rpms/flatpak/pull-request/5
>>
>>> On 11/1/19 2:51 PM, Tim Zabel wrote:
On Fri, 2019-11-01 at 12:02 -0600, Orion Poplawski wrote:
> My F31 kickstart install is failing with:
>
> DNF error: Error in POSTIN scriptlet in rpm package flatpak-selinux
Hmm, I've also ran into this issue of flatpak-selinux's POSTIN failing
:(
Just to be sure, are you building the kickstart with SELinux set to
permissive? It won't work if it's in Enforcing.
> This is because flapak-selinux installs a SELinux module in %post:
>
> %post selinux
> %selinux_modules_install %{_datadir}/selinux/packages/flatpak.pp.bz2
>
> which sources /etc/selinux/config. It is failing because
> /etc/selinux/config
> does not exist and /bin/sh exits with failure (/bin/bash does not
> interestingly enough).
>
> This was reported earlier here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1723118
For reference, here are some other BZs that I've ran into while trying
to come up with my own fixes to this issue:
*https://bugzilla.redhat.com/show_bug.cgi?id=1732132
*https://bugzilla.redhat.com/show_bug.cgi?id=1665643
> and the suggestion made to add:
>
> Requires(post): selinux-policy
>
> since selinux-policy owns /etc/selinux/config. However, selinux-
> policy
> creates /etc/selinux/config in its own %post, and Requires(post) only
> guarantees that the package's contents are installed, not that its
> scripts are
> complete.
>
> So, what's the best way to fix this? We need /etc/selinux/policy to
> be
> present and populated with SELINUXTYPE=targeted for the selinux
> policy modules
> to be installed properly.
>
> selinux-policy does:
>
> %post
> if [ ! -s /etc/selinux/config ]; then
> #
> # New install so we will default to targeted policy
> #
> echo "
> # This file controls the state of SELinux on the system.
> # SELINUX= can take one of these three values:
> # enforcing - SELinux security policy is enforced.
> # permissive - SELinux prints warnings instead of enforcing.
> # disabled - No SELinux policy is loaded.
> SELINUX=enforcing
> # SELINUXTYPE= can take one of these three values:
> # targeted - Targeted processes are protected,
> # minimum - Modification of targeted policy. Only selected
> processes are
> protected.
> # mls - Multi Level Security protection.
> SELINUXTYPE=targeted
>
> " > /etc/selinux/config
>
> ln -sf ../selinux/config /etc/sysconfig/selinux
> restorecon /etc/selinux/config 2> /dev/null || :
> else
> . /etc/selinux/config
> fi
> exit 0
>
> But can't this be achieved simply with:
>
> %config(noreplace) %{_sysconfdir}/selinux/config
>
> New installs would get the default config, but otherwise you would
> get a
> .rpmnew file.
>
> However, I realize that nothing is particularly simple about SELinux
> so there
> are probably things I'm not aware of that prevent this.
>
> PS - the else code seems to be a no-op.
Back when I was trying to find my own fixes, I managed to fix one
portion of the %post selinux that wa
Re: Modularity and all the things
On Mon, Nov 04, 2019 at 08:40:45PM -0500, Matthew Miller wrote: > On Mon, Nov 04, 2019 at 06:10:33PM -0500, Randy Barlow wrote: > > Consider the message that comments like this one and your last post > > send. I took the time to thoughtfully put together a set of ideas that > > can solve our problems in an easier and less controversial way by > > learning lessons from others who have traveled this path before us. > > > > You could have replied to my posts explaining why you think they won't > > achieve our goals. Instead, you have replied telling me that my efforts > > are not helpful, or that I need to have more details figured out than > > modularity does to participate in the conversation. You only quoted a > > single sentence from me - did you read the rest? Anybody can reply with > > a simple "what you wrote is not helpful", but it doesn't get us > > anywhere, and frankly it's lazy since you avoided countering my points, > > and a bit insulting too. > > Clearly we're having a failure to communicate here. I actually quoted less > than the entire message before because I felt like the rest of it was even > more inflammatory and trolling and I didn't want to escalate. Let's take > this offline and come back when we're on the same page about what we're even > *trying* to say rather than doing more back and forth. > I'd just like to say that I have found this thread very demoralizing. I think Randy has valid points and has brought them up far more respectfully than I could and I feel like it's being dismissed as trolling. I think this has a very negative affect on people's willingness to put their opinions out there and is going to lead to an echo chamber. Regards, Jeremy ___ 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: Encrypted DNS in Fedora
Am 05.11.19 um 16:01 schrieb Stephen John Smoogen: > >> To an extend in bandwidth, you could send out parallel queries and >> check, if they match or if someone has tampered >> with them. Would be a nice sideeffect. > This breaks down for multiple reasons. > > I do a parallel query and I get two different answers.. it isn't > because they are tampered with but because the DNS server got a GEOIP > regional address and so each server got one that was closest. However > this also leads to consolidation because a lot of DNS servers aren't > spec'd to dealing with more traffic than local DNS. Getting lots of > outside traffic ends up causing problems and links. So instead you get > a deal with Google/CloudFare/Akamai/etc to put in a DNS server which > they then offer to the public for a bit and you mostly. Tada.. person > on the internet thinks they spread out and aren't tracked but are just > as much as before. > I can imagine, that it is a realistic scenario for the US, but not in the rest of the free world. I.e. here in Germany, you find static ips, which would be mandatory for a public dns cache, or did you mean public as in "public places"? , mainly in companies and they won't share theire bandwidth for a public dns cache. Some private people and organizations run free open dns caches on science centers, but thats about it. That google (or anyone else) gave them money to redirect to i.e. 8.8.8.8 is hard to believe. Concerns about privacy + google/facebook/younameit are wide spread in europe, which is totally different in the us, as far as I heard. best regards, Marius ___ 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: recent mesa + libglvnd rawhide updates broke ... something?
So a few package need to adapt, they should have listed all the required #includes in their source files already IMO > So you mean to say that this has to be "fixed" in each individual > package, from fedora f32 forward? ___ 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's up with GStreamer 0.10 in F31?
On Tue, 5 Nov 2019 at 15:07, Fabio Valentini wrote: > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages > > Note that these Guidelines explicitly only apply to *renaming* and > *replacing*existing packages, not the plain removal / retirement of > packages. > gstreamer1-foo doesn't replace gstreamer-foo, so Obsoleting it is not > the correct thing anyway. I disagree. GStreamer 1.x is the successor of GStreamer 0.10.x, which has been kept alive out of convenience and to allow for a long-term migration of dependencies to GStreamer 1.x. Technically, GStreamer 1.x replaces GStreamer 0.10.x as an upgrade, particularly if dropping the latter from the distribution. For that it doesn't need to be API/ABI compatible, and the fact that both have been parallel installable for some time is entirely unrelated. Btw, even the retirement commit messages said "Obsoleted by 1.0 version": https://src.fedoraproject.org/rpms/gstreamer/c/80b168e5f2038409d9b5f6b78ab5b48e006a4942?branch=master > Arguably, the only reasonable thing would be to add gstreamer-foo to > fedora-obsolete-packages, and only if any of the retired packages > would cause issues during or after the upgrade to the affected fedora > release. That has not been done either. ___ 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: Modularity and all the things
On Mon, 2019-11-04 at 20:40 -0500, Matthew Miller wrote: > I actually quoted less than the entire message before because I felt > like the rest of it was even more inflammatory and trolling and I > didn't want to escalate. Accusing someone of trolling is not consistent with the actions of a person who wants to deescalate. signature.asc Description: This is a digitally signed message part ___ 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: package retirements broken since yesterday, nothing gets untagged from koji
On Tue, Nov 5, 2019 at 4:14 PM Miro Hrončok wrote: > > On 05. 11. 19 15:33, Fabio Valentini wrote: > > Hi everybody, > > > > It looks like yesterday, koji stopped blocking and removing retired > > packages from the f32 tag, or at least, it stopped doing so reliably. > > > > The following packages have been retired a day ago, but today they are > > all still tagged into f32, and were part of two composes after they > > were "fedpkg retire"d: > > > > - ... > > > > The actual list of affected packages might be longer, but I don't have > > a good way of checking "which packages were attempted to be retired, > > but actually were not" without looking at dist-git. > > > > The packages listed above were "partly removed" as part of the > > six-week-orphan cleanup (dist-git shows the retirement message), but > > yet they are all still tagged into f32 and they were included in two > > composes since their retirement. > > https://pagure.io/releng/issue/8958 > https://pagure.io/releng/issue/8966 Oh, great, thanks for the update :) Fabio > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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: package retirements broken since yesterday, nothing gets untagged from koji
On 05. 11. 19 15:33, Fabio Valentini wrote: Hi everybody, It looks like yesterday, koji stopped blocking and removing retired packages from the f32 tag, or at least, it stopped doing so reliably. The following packages have been retired a day ago, but today they are all still tagged into f32, and were part of two composes after they were "fedpkg retire"d: - ... The actual list of affected packages might be longer, but I don't have a good way of checking "which packages were attempted to be retired, but actually were not" without looking at dist-git. The packages listed above were "partly removed" as part of the six-week-orphan cleanup (dist-git shows the retirement message), but yet they are all still tagged into f32 and they were included in two composes since their retirement. https://pagure.io/releng/issue/8958 https://pagure.io/releng/issue/8966 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance
https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup == Summary == Python 3 traditionally in Fedora was built with a shared library libpython3.?.so and the final binary was dynamically linked against that shared library. This change is about creating the static library and linking the final python3 binary against it, as it provides significant performance improvement, up to 27% depending on the workload. The static library will not be shipped. The shared library will continue to exist in a separate subpackage. In essence, python3 will no longer depend on libpython. == Owner == * Name: [[User:Cstratak| Charalampos Stratakis]], [[User:Vstinner| Victor Stinner]], [[User:Churchyard| Miro Hrončok]] * Email: python-ma...@redhat.com == Detailed Description == When we compile the python3 package on Fedora (prior to this change), we create the libpython3.?.so shared library and the final python3 binary (/usr/bin/python3) is dynamically linked against it. However by building the libpython3.?.a static library and statically linking the final binary against it, we can achieve a performance gain of 5% to 27% depending on the workload. Link time optimizations and profile guided optimizations also have a greater impact when python3 is linked statically. Since Python 3.8, [https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build C extensions must no longer be linked to libpython by default]. Applications embedding Python now need to utilize the --embed flag for python3-config to be linked to libpython. During the [[Changes/Python3.8|Python 3.8 upgrade and rebuilds]] we've uncovered various cases of packages linking to libpython implicitly through various hacks within their buildsystems and fixed as many as possible. However, there are legitimate reasons to link an application to libpython and for those cases libpython should be provided so applications that embed Python can continue to do so. This mirrors the Debian/Ubuntu way of building Python, where they offer a statically linked binary and an additional libpython subpackage. The libpython subpackage will be created and python3-devel will depend on it, so packages that embed Python will keep working. The change was first done in Debian and Ubuntu years ago, followed by Python 3.8. manylinux1 and manylinux2010 ABI don't link C extensions to libpython either (to support Debian/Ubuntu). By applying this change, libpython's namespace will be separated from Python's, so '''C extension which are still linked to libpython''' might experience side effects or break. There is one exception for C extensions. If an application is linked to libpython in order to embed Python, C extensions used only within this application can continue to be linked to libpython. Currently there is no upstream option to build the static library, as well as the shared one and statically link the final binary to it, so we have to rely on a downstream patch to achieve it. We plan to work with upstream to incorporate the changes there as well. Before the change, python3.8 is dynamically linked to libpython3.8: +---+ | | | | ++ | libpython3.8.so <-+ /usr/bin/python3.8 | | | ++ | | +---+ After the change, python3.8 is statically linked to libpython3.8: +---+ | | | /usr/bin/python3.8 | | | +---+ | +---+ | | | | | | | | | | | | | | libpython3.8.so | | | libpython3.8.a | | | | | | | | | | | | | | +---+ | +---+ | +---+ As a negative side effect, when both libpython3.8.so and /usr/bin/python3.8 are installed, the filesystem footprint will be slightly increased (libpython3.8.so on Python 3.8.0, x86_64 is ~3.4M). OTOH only a very small amount of packages will depend on libpython3.8.so. == Benefit to Fedora == Python's performance will increase significantly depending on the workload. Since many core components of the OS also depend on Python this could lead to an increase in their performance as well, however individual benchmarks will need to be conducted to verify the performance gain for those components. [https://pyperformance.readthedocs.io/ pyperformance] results, ignoring differences smaller than 5%: (see wiki page for table) == Scope == * Proposal owners: ** Review and merge the [https://src.fedoraproject.org/rpms/python3/pull-request/133 pull request with the implementation].
Re: Encrypted DNS in Fedora
On Tue, 5 Nov 2019 at 09:51, Marius Schwarz wrote: > > Am 05.11.19 um 15:17 schrieb Florian Weimer: > > I categorically reject your notion that you can increase privacy by > > sending queries to more servers. As a result, you will end up with a > > larger set of servers you must trust, not a smaller one. > > > > You don't need to trust them for your privacy, the more servers > involved, the fewer data they get to profile about you. > Simple mathematics. > Except most of those servers are run by the same 3-4 organizations which will just use the same datatracking methods they use over other cloud apps to figure out what X is doing. Currently the 8.8.8.8/8.8.4.4 are thousands of DNS servers which also have other ip addresses that are given out by various coffee shops and other devices. The same with the 1.1.1.1 and probably a dozen other single IP servers. > To an extend in bandwidth, you could send out parallel queries and > check, if they match or if someone has tampered > with them. Would be a nice sideeffect. This breaks down for multiple reasons. I do a parallel query and I get two different answers.. it isn't because they are tampered with but because the DNS server got a GEOIP regional address and so each server got one that was closest. However this also leads to consolidation because a lot of DNS servers aren't spec'd to dealing with more traffic than local DNS. Getting lots of outside traffic ends up causing problems and links. So instead you get a deal with Google/CloudFare/Akamai/etc to put in a DNS server which they then offer to the public for a bit and you mostly. Tada.. person on the internet thinks they spread out and aren't tracked but are just as much as before. > > best regards, > Marius > ___ > 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 -- Stephen J Smoogen. ___ 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: Encrypted DNS in Fedora
Am 05.11.19 um 15:17 schrieb Florian Weimer: > I categorically reject your notion that you can increase privacy by > sending queries to more servers. As a result, you will end up with a > larger set of servers you must trust, not a smaller one. > You don't need to trust them for your privacy, the more servers involved, the fewer data they get to profile about you. Simple mathematics. To an extend in bandwidth, you could send out parallel queries and check, if they match or if someone has tampered with them. Would be a nice sideeffect. best regards, Marius ___ 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: Encrypted DNS in Fedora
Am 05.11.19 um 14:38 schrieb Tomasz Torcz:
> On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
>> DoH is IMHO a waste of resources and as Browsers implement it, useless
>> at best, but mostly a centralization of control of users under a false
>> protection umbrella.
>>
>> Any modern Browser will do this sequence:
>>
>> User enters URL
>> Browser checks for domainnames
>> Browser sends DNS request ( over which path doesn't matter )
>> Opens connection to the target host
>>
>> If ( HTTPS ) {
>> sends the domainname, he has found in the URL as SNI in plain! in
>> his TLS request
> This is not true, SNI is encrypted:
> https://eff.org/pl/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
It says "experimental" in sentence one in 2018 ... and this is end of
2019 connecting to EFF.org with Firefox:
Request:
15:11:04.342072 IP MYIP.46286 > vm1.eff.org.https: Flags [P.], seq
1:518, ack 1, win 502, options [nop,nop,TS val 2291965978 ecr
490558638], length 517
0x: 4500 0239 8492 4000 4006 f5ae c0a8 0022 E..9..@.@.."
0x0010: adef 4fc4 b4ce 01bb 52d3 1d70 a0d0 f7f6 ..O.R..p
0x0020: 8018 01f6 857b 0101 080a 889c a01a .{..
0x0030: 1d3d 54ae 1603 0102 0001 0001 fc03 032e .=T.
0x0040: 4e54 98b3 7e3d 6fc4 0a9a f788 da24 62f4 NT..~=o..$b.
0x0050: 8649 5ed0 eee5 941e fcf2 ab32 2510 f020 .I^2%...
0x0060: 88d6 2ac2 75f3 309f 636d 07fe 8660 84e6 ..*.u.0.cm...`..
0x0070: da60 a907 d7c5 aa3e 5c58 4af5 274c 5c4c .`.>\XJ.'L\L
0x0080: 0022 1301 1303 1302 c02b c02f cca9 cca8 ."...+./
0x0090: c02c c030 c00a c009 c013 c014 0033 0039 .,.0.3.9
0x00a0: 002f 0035 0100 0191 0017 0015 ./.5
0x00b0: 1261 6e6f 6e2d 7374 6174 732e 6566 662e .*anon-stats.eff.*
0x00c0: 6f72 6700 1700 00ff 0100 0100 000a 000e *org*.
0x00d0: 000c 001d 0017 0018 0019 0100 0101 000b
0x00e0: 0002 0100 0023 0010 000e 000c 0268 .#.h
0x00f0: 3208 6874 7470 2f31 2e31 0005 0005 0100 2.http/1.1..
Answere:
15:11:04.517421 IP vm1.eff.org.https > MYIP.46286: Flags [.], seq
1:1441, ack 518, win 11, options [nop,nop,TS val 490558683 ecr
2291965978], length 1440
0x: 4500 05d4 a322 4000 2e06 e583 adef 4fc4 E"@...O.
0x0010: c0a8 0022 01bb b4ce a0d0 f7f6 52d3 1f75 ..."R..u
0x0020: 8010 000b 09d2 0101 080a 1d3d 54db .=T.
0x0030: 889c a01a 1603 0300 5402 5003 03ae T...P...
0x0040: 9213 9378 8065 5d69 d974 edc4 3a2f 85d4 ...x.e]i.t..:/..
0x0050: e7e3 46cd aa03 c317 4dde 5bb2 947c e100 ..F.M.[..|..
0x0060: c030 28ff 0100 0100 000b .0..(...
0x0070: 0004 0300 0102 0023 0017 0010 ...#
0x0080: 000b 0009 0868 7474 702f 312e 3116 0303 .http/1.1...
0x0090: 0b04 0b00 0b00 000a fd00 0661 3082 065d ...a0..]
0x00a0: 3082 0545 a003 0201 0202 1203 1919 210a 0..E..!.
0x00b0: ca50 2c2e 4bc1 798f bffc 2094 7330 0d06 .P,.K.y.s0..
0x00c0: 092a 8648 86f7 0d01 010b 0500 304a 310b .*.H0J1.
0x00d0: 3009 0603 5504 0613 0255 5331 1630 1406 0...UUS1.0..
0x00e0: 0355 040a 130d 4c65 7427 7320 456e 6372 .ULet's.Encr
0x00f0: 7970 7431 2330 2106 0355 0403 131a 4c65 ypt1#0!..ULe
0x0100: 7427 7320 456e 6372 7970 7420 4175 7468 t's.Encrypt.Auth
0x0110: 6f72 6974 7920 5833 301e 170d 3139 3131 ority.X30...1911
0x0120: 3031 3138 3330 3436 5a17 0d32 3030 3133 01183046Z..20013
0x0130: 3031 3833 3034 365a 301d 311b 3019 0603 0183046Z0.1.0...
0x0140: 5504 0313 1261 6e6f 6e2d 7374 6174 732e U*anon-stats.*
0x0150: 6566 662e 6f72 6730 8202 2230 0d06 092a *eff.org*0.."0...*
0x0160: 8648 86f7 0d01 0101 0500 0382 020f 0030 .H.0
0x0170: 8202 0a02 8202 0100 be74 c8c0 c04e d886 .t...N..
0x0180: 6fb4 90f7 d65b c1be 0d7d eece be45 6161 o[...}...Eaa
0x0190: c71f 544d 8fd7 ab3c 63bd 4ce5 b3dc f5c8 ..TM...___
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
package retirements broken since yesterday, nothing gets untagged from koji
Hi everybody, It looks like yesterday, koji stopped blocking and removing retired packages from the f32 tag, or at least, it stopped doing so reliably. The following packages have been retired a day ago, but today they are all still tagged into f32, and were part of two composes after they were "fedpkg retire"d: - cbi-plugins - eclipse-dtp - eclipse-ecf - eclipse-eclemma - eclipse-egit-github - eclipse-linuxtools - eclipse-moreunit - eclipse-mpc - eclipse-mylyn - eclipse-packagekit - eclipse-pydev - eclipse-swtbot - eclipse-tm-terminal - freemedforms - java-base64 - jetty-version-maven-plugin - stringtemplate4 - tagsoup The actual list of affected packages might be longer, but I don't have a good way of checking "which packages were attempted to be retired, but actually were not" without looking at dist-git. The packages listed above were "partly removed" as part of the six-week-orphan cleanup (dist-git shows the retirement message), but yet they are all still tagged into f32 and they were included in two composes since their retirement. 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: Encrypted DNS in Fedora
* Marius Schwarz: > Am 05.11.19 um 14:21 schrieb Florian Weimer: >> >>> ahm.. in which way, does the use of encryption, make a sourcelist for >>> dns names to ask, obsolete? >> Names or servers? > "names of domainnameservers" > >>> nscd i.e. uses resolv.conf as source for the round robin server list. >> With encryption, the server address will always be 127.0.0.1 (or >> potentially in the future, a UNIX domain socket) because pretty much all >> the current DNS client software does not support encryption. Running a >> small local cache has other benefits as well, such as caching server >> reachability information. > running a local DNS-Cache does not make so much sense as you may > think. It definitely makes sense to cache server availability because that's not something a short-running process can effectively determine from scratch. I categorically reject your notion that you can increase privacy by sending queries to more servers. As a result, you will end up with a larger set of servers you must trust, not a smaller one. Thanks, Florian ___ 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's up with GStreamer 0.10 in F31?
Michael Schwendt wrote on 2019/11/05 21:17: On Wed, 25 Sep 2019 10:45:45 +0200, Kalev Lember wrote: On 9/24/19 14:50, Michael Catanzaro wrote: On Thu, Aug 22, 2019 at 9:04 am, Tom Callaway wrote: or know of some reason it shouldn't be brought back Well this looks like gstreamer 0.10. I'm really surprised we still have this in the distro. It's been obsolete for the better part of a decade and is probably filled with security bugs. I remember openSUSE got rid of its 0.10 packages 5+ years ago. Why not let it die? Whatever is using it surely needs to go. I second to that. I think it's time to let gstreamer 0.10 get removed from the distro. What has happened here? It seems GStreamer 0.10 has been removed from F31 prior to release, but only partially, breaking dependencies, leaving behind packages that cannot be installed. And packagers have not been warned/informed either. # dnf install gstreamer-plugins-base Last metadata expiration check: 0:06:09 ago on Tue 05 Nov 2019 13:07:19 CET. Error: Problem: conflicting requests - nothing provides libgstbase-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstcontroller-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstdataprotocol-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 gstreamer has once removed from distro due to FTBFS policy. And perhaps it is found that this package was still needed and the retirement got reverted, and actually after that gstreamer-0.10.36-24.fc31 was rebuild: https://koji.fedoraproject.org/koji/packageinfo?packageID=575 gstreamer-plugins-base was the same: it got removed due to FTBFS policy, and retirement was reverted. What is interesting is that when rebuilding gstreamer-plugins-base-0.10.36-24.fc31 (after retirement revert), gstreamer-0.10.36-18.fc27 from F27 (!) was used according to root.log: https://koji.fedoraproject.org/koji/buildinfo?buildID=1376705 Then gstreamer-plugins-base-0.10.36-24.fc31 was submitted to bodhi, however it seems submitting gstreamer-0.10.36-24.fc31 was forgotton. 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
Re: Encrypted DNS in Fedora
Am 05.11.19 um 14:21 schrieb Florian Weimer: > >> ahm.. in which way, does the use of encryption, make a sourcelist for >> dns names to ask, obsolete? > Names or servers? "names of domainnameservers" >> nscd i.e. uses resolv.conf as source for the round robin server list. > With encryption, the server address will always be 127.0.0.1 (or > potentially in the future, a UNIX domain socket) because pretty much all > the current DNS client software does not support encryption. Running a > small local cache has other benefits as well, such as caching server > reachability information. > running a local DNS-Cache does not make so much sense as you may think. besides the obvious reasons like short daytime usage with poweroff at the end, you will run into the same kind of problems, the windows local dnscache had: It's even harder to debug customers problems, as more caches are involved. Countless days i had to let users flush their local dns cache, to ensure they don't connect to something outdated. DNS is so vital to all services, that you want to have something easy to maintain and debug, unlike NetworkManager, which enslaves all users to the default dns names, that came via dhcp. Last time i checked, it does not support round robin to increase privacy. NSCD does, and if NM lets it, it's working good. (had it running) If someone wants to improve privacy, some rules apply: a) you don't ask the same server for all your questions ( Round Robin with thousands of dnscaches world wide) b) you build a chain of trust ( DNSSEC ) c) the entire chain encrypts the traffic It would be ok, to have a local resolver handle this for all apps and it mimics an unencrypted ns on 127.0.0.1:53 . But the main problem with a+b+c is, it takes a sh*tload of overhead to a real simple thing AND as with browsers, has absolutely no value, because the browser will tell anyone between himself and the target, what he is connecting to. (see other posting). Most people won't even gain privacy protection out of it, as outbound dns is blocked except for the ISPs dns, the cable/dsl box they use will just send them two dns servers, not thousands to choose from and in the end, the browser will give them away anyway. From my POV, which supports the DoT as it's a good idea, "why protecting something, that the last device sabotages anyway?" Ok, there are more than webpages, but most used services like mail pop imap, open one connection to a known targetport, not hard to guess what it is and where it is. BTW, those clients do 1 dns resolve per day, they won't profit from a local cache ;) And even if the browser would not give the dn away in SNI or Host: , it does not make things better, as you can simply ask the internet, which websites are hosted on a specific ip, and you get a long list of names. Tracking a users connections makes it always possible to build profiles, maybe not as precise as with dns data, but good enough. My conclusion: DoT and DoH, if not done via a browser, and not done via one single server, are acceptable and a valid goal for a change inside Fedora, but they won't help in privacy protection. What is needed to reach this special goal, takes more than Fedora or Red Hat can provide. I personally favor DoT as it would make use of the millions of dns server available on the net. DoH is too centralized to implement for now. best regards, Marius ___ 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's up with GStreamer 0.10 in F31?
On Tue, Nov 5, 2019 at 2:44 PM Michael Schwendt wrote: > > On Tue, 5 Nov 2019 13:52:00 +0100, Miro Hrončok wrote: > > > gstreamer was retired > > https://src.fedoraproject.org/rpms/gstreamer/c/21fd6753e6c7f1fa1dee1045596b25fdb8c71f37?branch=f31 > > > > the commit was reverted > > https://src.fedoraproject.org/rpms/gstreamer/c/1ce6b77242c27c450179e32a2fc7833300aa8759?branch=f31 > > > > But the package was never unretired or rebuilt. > > That can't be the full story. Why has the GStreamer 0.10.x framework been > removed without checking for dependency breakage and without warning packagers > about it? All I can see is that releng has rebuilt the packages during the F31 > cycle, and later the build dependencies have been removed from the dist, so > the packages cannot even be rebuilt anymore. > > Currently, no gstreamer1* package contains Obsoletes tags that would > retire those packages properly. It seems to me that the guidelines have > not been followed at all: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages Note that these Guidelines explicitly only apply to *renaming* and *replacing*existing packages, not the plain removal / retirement of packages. gstreamer1-foo doesn't replace gstreamer-foo, so Obsoleting it is not the correct thing anyway. Arguably, the only reasonable thing would be to add gstreamer-foo to fedora-obsolete-packages, and only if any of the retired packages would cause issues during or after the upgrade to the affected fedora release. Fabio > Information for RPM gstreamer1-plugins-base-1.16.1-1.fc31.x86_64.rpm > Obsoletes No Obsoletes > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=19158674 > Obsoletes No Obsoletes > > Information for RPM gstreamer1-plugins-good-1.16.1-2.fc31.x86_64.rpm > Obsoletes gstreamer1-plugin-mpg123 < 1.13.1 > ___ > 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: Encrypted DNS in Fedora
On 05/11/2019 13:42, Tom Hughes wrote: I don't think one CDN deploying a non-standard extension can reasonably be described as meaning that SNI is now encrypted. Yes it is encrypted if you're using a special test version of one specific browser and you access a site run by one of a handful of providers that support that on the server side. Looks like release Firefox does have it now, but not enabled by default - there is a network.security.esni.enabled configuration option that would have to be turned on. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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's up with GStreamer 0.10 in F31?
On Tue, 5 Nov 2019 13:52:00 +0100, Miro Hrončok wrote: > gstreamer was retired > https://src.fedoraproject.org/rpms/gstreamer/c/21fd6753e6c7f1fa1dee1045596b25fdb8c71f37?branch=f31 > > the commit was reverted > https://src.fedoraproject.org/rpms/gstreamer/c/1ce6b77242c27c450179e32a2fc7833300aa8759?branch=f31 > > But the package was never unretired or rebuilt. That can't be the full story. Why has the GStreamer 0.10.x framework been removed without checking for dependency breakage and without warning packagers about it? All I can see is that releng has rebuilt the packages during the F31 cycle, and later the build dependencies have been removed from the dist, so the packages cannot even be rebuilt anymore. Currently, no gstreamer1* package contains Obsoletes tags that would retire those packages properly. It seems to me that the guidelines have not been followed at all: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages Information for RPM gstreamer1-plugins-base-1.16.1-1.fc31.x86_64.rpm Obsoletes No Obsoletes https://koji.fedoraproject.org/koji/rpminfo?rpmID=19158674 Obsoletes No Obsoletes Information for RPM gstreamer1-plugins-good-1.16.1-2.fc31.x86_64.rpm Obsoletes gstreamer1-plugin-mpg123 < 1.13.1 ___ 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: Encrypted DNS in Fedora
On 05/11/2019 13:38, Tomasz Torcz wrote:
On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
DoH is IMHO a waste of resources and as Browsers implement it, useless
at best, but mostly a centralization of control of users under a false
protection umbrella.
Any modern Browser will do this sequence:
User enters URL
Browser checks for domainnames
Browser sends DNS request ( over which path doesn't matter )
Opens connection to the target host
If ( HTTPS ) {
sends the domainname, he has found in the URL as SNI in plain! in
his TLS request
This is not true, SNI is encrypted:
https://eff.org/pl/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
I don't think one CDN deploying a non-standard extension can reasonably
be described as meaning that SNI is now encrypted.
Yes it is encrypted if you're using a special test version of one
specific browser and you access a site run by one of a handful of
providers that support that on the server side.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: Encrypted DNS in Fedora
On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
> DoH is IMHO a waste of resources and as Browsers implement it, useless
> at best, but mostly a centralization of control of users under a false
> protection umbrella.
>
> Any modern Browser will do this sequence:
>
> User enters URL
> Browser checks for domainnames
> Browser sends DNS request ( over which path doesn't matter )
> Opens connection to the target host
>
> If ( HTTPS ) {
> sends the domainname, he has found in the URL as SNI in plain! in
> his TLS request
This is not true, SNI is encrypted:
https://eff.org/pl/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
--
Tomasz Torcz ,,If you try to upissue this patchset I shall be
seeking
xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton
(LKML)
___
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: 20191105.n.0 changes
OLD: Fedora-Rawhide-20191104.n.1 NEW: Fedora-Rawhide-20191105.n.0 = SUMMARY = Added images:2 Dropped images: 1 Added packages: 3 Dropped packages:0 Upgraded packages: 29 Downgraded packages: 0 Size of added packages: 20.91 MiB Size of dropped packages:0 B Size of upgraded packages: 5.19 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 62.43 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server boot armhfp Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-Rawhide-20191105.n.0.iso Image: Server dvd armhfp Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-Rawhide-20191105.n.0.iso = DROPPED IMAGES = Image: LXDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20191104.n.1-sda.raw.xz = ADDED PACKAGES = Package: R-GenomicRanges-1.38.0-1.fc32 Summary: Representation and manipulation of genomic intervals RPMs:R-GenomicRanges Size:9.94 MiB Package: R-IRanges-2.20.0-1.fc32 Summary: Low-level containers for storing sets of integer ranges RPMs:R-IRanges R-IRanges-devel Size:10.96 MiB Package: python-timeunit-1.1.0-1.fc32 Summary: Python module providing utility methods to convert across time units RPMs:python3-timeunit Size:12.30 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Cython-0.29.14-1.fc32 Old package: Cython-0.29.13-5.fc32 Summary: Language for writing Python extension modules RPMs: emacs-cython-mode python3-Cython Dropped RPMs: python2-Cython Size: 13.56 MiB Size change: -10.94 MiB Changelog: * Mon Nov 04 2019 Miro Hron??ok - 0.29.14-1 - Update to 0.29.14 (#1768034) - Python 2 subpackage has been removed Package: R-S4Vectors-0.24.0-1.fc32 Old package: R-S4Vectors-0.22.0-2.fc31 Summary: S4 implementation of vectors and lists RPMs: R-S4Vectors R-S4Vectors-devel Size: 11.51 MiB Size change: 596.75 KiB Changelog: * Mon Nov 04 2019 Tom Callaway - 0.24.0-1 - update to 0.24.0 Package: alienarena-7.71.1-1.fc32 Old package: alienarena-7.71.0-3.fc31 Summary: Multiplayer retro sci-fi deathmatch game RPMs: alienarena alienarena-data alienarena-server Size: 770.58 MiB Size change: 3.25 MiB Changelog: * Mon Nov 04 2019 Tom Callaway - 7.71.1-1 - update to svn trunk (7.71.1) - update descriptions Package: audit-3.0-0.15.20191104git1c2f876.fc32 Old package: audit-3.0-0.14.20190507gitf58ec40.fc32 Summary: User space tools for kernel auditing RPMs: audispd-plugins audispd-plugins-zos audit audit-libs audit-libs-devel python2-audit python3-audit Size: 3.50 MiB Size change: 4.32 KiB Changelog: * Mon Nov 04 2019 Steve Grubb 3.0-0.14.20191104git1c2f876 - New upstream git snapshot prerelease Package: autodownloader-0.4.0-1.fc32 Old package: autodownloader-0.3.0-20.fc31 Summary: GUI-tool to automate the download of certain files RPMs: autodownloader Size: 38.29 KiB Size change: 112 B Changelog: * Mon Nov 04 2019 Lum??r Balhar - 0.4.0-1 - New upstream, new release - Python 3 & GTK 3 compatibility Package: bluefish-2.2.10-13.fc32 Old package: bluefish-2.2.10-12.fc31 Summary: Web development application for experienced users RPMs: bluefish bluefish-shared-data Size: 4.81 MiB Size change: -218.45 KiB Changelog: * Mon Nov 04 2019 Paul Howarth - 2.2.10-13 - Disable Python functionality on F-32, EL-8 onwards as it requires Python 2 https://bugzilla.redhat.com/show_bug.cgi?id=1737907 Will re-enable when Python 3 is supported https://sourceforge.net/p/bluefish/tickets/10/ Package: firefox-70.0.1-2.fc32 Old package: firefox-70.0.1-1.fc32 Summary: Mozilla Firefox Web browser RPMs: firefox firefox-wayland firefox-x11 Size: 281.93 MiB Size change: 46.63 KiB Changelog: * Mon Nov 04 2019 Jan Horak - 70.0.1-2 - Added fix for non-scrollable popups Package: flamegraph-1.0-3.20191024.1a0dc69.fc32 Old package: flamegraph-1.0-2.20190216.1b1c6de.fc31 Summary: Stack trace visualizer RPMs: flamegraph flamegraph-demos flamegraph-stackcollapse flamegraph-stackcollapse-perf flamegraph-stackcollapse-php Size: 543.27 KiB Size change: 10.46 KiB Changelog: * Mon Nov 04 2019 Jerry James - 1.0-3.20191024.1a0dc69 - Update to latest git HEAD for bug fixes - Add man pages Package: freecad-1:0.18.3-7.fc32 Old package: freecad-1:0.18.3-6.fc32 Summary: A general purpose 3D CAD modeler RPMs: freecad freecad-data Size: 317.86 MiB Size change: 23.21 KiB Changelog: * Mon Nov 04 2019 Richard Shaw - 1:0.18.3-7 - Fix python3-pyside2 requires and other specfile cleanup. Package: gimp-2:2.10.14-1.fc32 Old package: gimp-2:2.10.12-3.fc32 Summary: GNU Image Manipulation Program RPMs: gimp gimp-devel gimp-devel-tools gimp-libs
Re: Encrypted DNS in Fedora
* Marius Schwarz: > Am 04.11.19 um 23:52 schrieb Michael Cronenworth: >> cryptographic library into every process that queries an Internet host >>> name. That also applies to DNSSEC. >> >> The transition to DoT/DoH makes the resolv.conf file obsolete. Any >> discussion on removing it entirely? Default to looking at a local >> resolver. > > ahm.. in which way, does the use of encryption, make a sourcelist for > dns names to ask, obsolete? Names or servers? > nscd i.e. uses resolv.conf as source for the round robin server list. With encryption, the server address will always be 127.0.0.1 (or potentially in the future, a UNIX domain socket) because pretty much all the current DNS client software does not support encryption. Running a small local cache has other benefits as well, such as caching server reachability information. Thanks, Florian ___ 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: Encrypted DNS in Fedora
Am 04.11.19 um 23:52 schrieb Michael Cronenworth: > cryptographic library into every process that queries an Internet host >> name. That also applies to DNSSEC. > > The transition to DoT/DoH makes the resolv.conf file obsolete. Any > discussion on removing it entirely? Default to looking at a local > resolver. ahm.. in which way, does the use of encryption, make a sourcelist for dns names to ask, obsolete? nscd i.e. uses resolv.conf as source for the round robin server list. best regards, Marius ___ 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: Encrypted DNS in Fedora
Am 04.11.19 um 17:40 schrieb Michael Cronenworth:
> Hi,
>
> Is there any project or team involved with improving encrypted DNS
> support in Fedora? Any movement in Red Hat corporate?
>
> - Glibc team?
> The /etc/resolv.conf file needs some love. AFAIK it still does not
> verify DNSSEC.
> - Bind team?
> Using 'stunnel' is not a real option.
> - DHCP(d & c) team?
> Some sort of standard for applying DoT/DoH options to resolv.conf
DoH is IMHO a waste of resources and as Browsers implement it, useless
at best, but mostly a centralization of control of users under a false
protection umbrella.
Any modern Browser will do this sequence:
User enters URL
Browser checks for domainnames
Browser sends DNS request ( over which path doesn't matter )
Opens connection to the target host
If ( HTTPS ) {
sends the domainname, he has found in the URL as SNI in plain! in
his TLS request
} else {
send the domainame in plaintext as Host: Header to the target.
}
in both cases, the result is the same. The user is trackable.
> IMHO, this should be our number one priority over modules, new spins,
> or whatever paint color the bike shed needs to be today. I would like
> to see DNS over TLS (DoT) with DTLS at the very least.
I support this.
best regards,
Marius
___
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's up with GStreamer 0.10 in F31?
On 05. 11. 19 13:17, Michael Schwendt wrote: On Wed, 25 Sep 2019 10:45:45 +0200, Kalev Lember wrote: On 9/24/19 14:50, Michael Catanzaro wrote: On Thu, Aug 22, 2019 at 9:04 am, Tom Callaway wrote: or know of some reason it shouldn't be brought back Well this looks like gstreamer 0.10. I'm really surprised we still have this in the distro. It's been obsolete for the better part of a decade and is probably filled with security bugs. I remember openSUSE got rid of its 0.10 packages 5+ years ago. Why not let it die? Whatever is using it surely needs to go. I second to that. I think it's time to let gstreamer 0.10 get removed from the distro. What has happened here? It seems GStreamer 0.10 has been removed from F31 prior to release, but only partially, breaking dependencies, leaving behind packages that cannot be installed. And packagers have not been warned/informed either. # dnf install gstreamer-plugins-base Last metadata expiration check: 0:06:09 ago on Tue 05 Nov 2019 13:07:19 CET. Error: Problem: conflicting requests - nothing provides libgstbase-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstcontroller-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstdataprotocol-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstreamer-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides gstreamer >= 0.10.36 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstreamer-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides libgstbase-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides libgstcontroller-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides libgstdataprotocol-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides gstreamer >= 0.10.36 needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides libgstbase-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides libgstcontroller-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides libgstdataprotocol-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides libgstreamer-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides gstreamer >= 0.10.36 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides libgstreamer-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 - nothing provides libgstbase-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 - nothing provides libgstcontroller-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 - nothing provides libgstdataprotocol-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 - nothing provides gstreamer >= 0.10.36 needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 (try to add '--skip-broken' to skip uninstallable packages) gstreamer was retired https://src.fedoraproject.org/rpms/gstreamer/c/21fd6753e6c7f1fa1dee1045596b25fdb8c71f37?branch=f31 the commit was reverted https://src.fedoraproject.org/rpms/gstreamer/c/1ce6b77242c27c450179e32a2fc7833300aa8759?branch=f31 But the package was never unretired or rebuilt. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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-20191105.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 45 required tests failed, 3 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default Failed openQA tests: 9/153 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20191104.n.1): ID: 480268 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/480268 ID: 480278 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/480278 ID: 480287 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/480287 ID: 480318 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/480318 ID: 480357 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/480357 ID: 480375 Test: x86_64 universal install_pxeboot URL: https://openqa.fedoraproject.org/tests/480375 Old failures (same test failed in Fedora-Rawhide-20191104.n.1): ID: 480229 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/480229 ID: 480291 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/480291 ID: 480293 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/480293 ID: 480295 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/480295 Soft failed openQA tests: 2/153 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20191104.n.1): ID: 480345 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/480345 ID: 480347 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/480347 Passed openQA tests: 134/153 (x86_64) New passes (same test not passed in Fedora-Rawhide-20191104.n.1): ID: 480223 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/480223 ID: 480224 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/480224 ID: 480258 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/480258 ID: 480259 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/480259 ID: 480272 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/480272 ID: 480275 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/480275 ID: 480276 Test: x86_64 KDE-live-iso release_identification URL: https://openqa.fedoraproject.org/tests/480276 ID: 480277 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/480277 ID: 480279 Test: x86_64 KDE-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/480279 ID: 480280 Test: x86_64 KDE-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/480280 ID: 480281 Test: x86_64 KDE-live-iso base_service_manipulation URL: https://openqa.fedoraproject.org/tests/480281 ID: 480282 Test: x86_64 KDE-live-iso base_update_cli URL: https://openqa.fedoraproject.org/tests/480282 ID: 480283 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/480283 ID: 480284 Test: x86_64 KDE-live-iso desktop_terminal URL: https://openqa.fedoraproject.org/tests/480284 ID: 480285 Test: x86_64 KDE-live-iso base_system_logging URL: https://openqa.fedoraproject.org/tests/480285 ID: 480288 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/480288 ID: 480289 Test: x86_64 KDE-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/480289 ID: 480290 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/480290 ID: 480314 Test: x86_64 universal install_kickstart_firewall_disabled URL: https://openqa.fedoraproject.org/tests/480314 ID: 480315 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/480315 ID: 480321 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/480321 ID: 480339 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/480339 ID: 480360 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedorapr
Re: recent mesa + libglvnd rawhide updates broke ... something?
On Tue, Nov 5, 2019 at 1:13 PM Leigh Scott wrote: > > See https://gitlab.gnome.org/GNOME/mutter/merge_requests/870 So you mean to say that this has to be "fixed" in each individual package, from fedora f32 forward? 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
What's up with GStreamer 0.10 in F31?
On Wed, 25 Sep 2019 10:45:45 +0200, Kalev Lember wrote: > On 9/24/19 14:50, Michael Catanzaro wrote: > > On Thu, Aug 22, 2019 at 9:04 am, Tom Callaway wrote: > >> or know of some reason it shouldn't be brought back > > > > Well this looks like gstreamer 0.10. I'm really surprised we still have > > this in the distro. It's been obsolete for the better part of a decade > > and is probably filled with security bugs. I remember openSUSE got rid > > of its 0.10 packages 5+ years ago. > > > > Why not let it die? Whatever is using it surely needs to go. > > I second to that. I think it's time to let gstreamer 0.10 get removed > from the distro. What has happened here? It seems GStreamer 0.10 has been removed from F31 prior to release, but only partially, breaking dependencies, leaving behind packages that cannot be installed. And packagers have not been warned/informed either. # dnf install gstreamer-plugins-base Last metadata expiration check: 0:06:09 ago on Tue 05 Nov 2019 13:07:19 CET. Error: Problem: conflicting requests - nothing provides libgstbase-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstcontroller-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstdataprotocol-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstreamer-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides gstreamer >= 0.10.36 needed by gstreamer-plugins-base-0.10.36-24.fc31.i686 - nothing provides libgstreamer-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides libgstbase-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides libgstcontroller-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides libgstdataprotocol-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides gstreamer >= 0.10.36 needed by gstreamer-plugins-base-0.10.36-24.fc31.x86_64 - nothing provides libgstbase-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides libgstcontroller-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides libgstdataprotocol-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides libgstreamer-0.10.so.0 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides gstreamer >= 0.10.36 needed by gstreamer-plugins-base-0.10.36-18.fc27.i686 - nothing provides libgstreamer-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 - nothing provides libgstbase-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 - nothing provides libgstcontroller-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 - nothing provides libgstdataprotocol-0.10.so.0()(64bit) needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 - nothing provides gstreamer >= 0.10.36 needed by gstreamer-plugins-base-0.10.36-18.fc27.x86_64 (try to add '--skip-broken' to skip uninstallable packages) ___ 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: recent mesa + libglvnd rawhide updates broke ... something?
See https://gitlab.gnome.org/GNOME/mutter/merge_requests/870 ___ 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: Encrypted DNS in Fedora
dnsmasq can include the real dns server ips from a external file 19/11/5 12:51(e)an, Sam Varshavchik igorleak idatzi zuen: > Florian Weimer writes: > >> * Michael Cronenworth: >> >> > On 11/4/19 2:17 PM, Florian Weimer wrote: >> >> We are not going to implement this directly in glibc. You should >> talk >> >> to a stub resolver on 127.0.0.1 instead. We do not want to link a >> >> cryptographic library into every process that queries an Internet >> host >> >> name. That also applies to DNSSEC. >> > >> > The transition to DoT/DoH makes the resolv.conf file obsolete. Any >> > discussion on removing it entirely? Default to looking at a local >> > resolver. >> >> This is the default today. The issue is that the defaults for the DNS >> search path and some other options are wrong, and we will need a >> transition to correct that. Then we can probably remove the file, >> unless something else is stored there. > > Where would the dhcp-supplied DNS resolver, and DNS search path, go? > > Ubuntu's default configuration appears to set up a stub resolver on > localhost and dnsmasq. Made it somewhat difficult to do any kind of > diagnostics, sine the real DNS server IP address seems to get stored > entirely within dnsmasq, and not visible anywhere. > > I like plain text files, in well-defined locations. Makes things much > easier to troubleshoot. > > > ___ > 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 -- Julen Landa Alustiza ___ 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: Encrypted DNS in Fedora
Florian Weimer writes: * Michael Cronenworth: > On 11/4/19 2:17 PM, Florian Weimer wrote: >> We are not going to implement this directly in glibc. You should talk >> to a stub resolver on 127.0.0.1 instead. We do not want to link a >> cryptographic library into every process that queries an Internet host >> name. That also applies to DNSSEC. > > The transition to DoT/DoH makes the resolv.conf file obsolete. Any > discussion on removing it entirely? Default to looking at a local > resolver. This is the default today. The issue is that the defaults for the DNS search path and some other options are wrong, and we will need a transition to correct that. Then we can probably remove the file, unless something else is stored there. Where would the dhcp-supplied DNS resolver, and DNS search path, go? Ubuntu's default configuration appears to set up a stub resolver on localhost and dnsmasq. Made it somewhat difficult to do any kind of diagnostics, sine the real DNS server IP address seems to get stored entirely within dnsmasq, and not visible anywhere. I like plain text files, in well-defined locations. Makes things much easier to troubleshoot. pgpaH1FVGXQko.pgp Description: PGP signature ___ 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
recent mesa + libglvnd rawhide updates broke ... something?
Hi everybody, It looks like the recent shuffling around of header / pkgconfig / etc. files between mesa and libglvnd introduced some regressions. At least a few packages are failing to build in rawhide since those changes were made, including mutter (probably that's important?) and mutter328 (the 3.28 compat package of mutter), which fail with the following error: ./cogl/cogl/winsys/cogl-winsys-egl.c:900:17: error: 'EGL_WAYLAND_BUFFER_WL' undeclared (first use in this function) Other packages also have started to FTBFS with the same issue (or similar issues, but I'm not sure those have the same root cause), including mir and wlc. Maybe somebody who knows this stuff should check it out? I reported this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1765930 And a similar issue that happened in the f31 cycle, where a similar batch of packages failed: https://bugzilla.redhat.com/show_bug.cgi?id=170 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: scribus-generator now provides python2-tkinter in Fedora 30 ?
Am 05.11.19 um 10:05 schrieb Zbigniew Jędrzejewski-Szmek: That seems to be a bug. Ok, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1768831 (Hopefully we can get this fixed asap because we won't be able to fix this automatically once python2-tkinter was removed in existing installs.) Felix ___ 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: scribus-generator now provides python2-tkinter in Fedora 30 ?
On Tue, Nov 05, 2019 at 09:44:43AM +0100, Felix Schwarz wrote: > Hi, > > I noticed that the latest update for scribus-generator (pushed to stable F30) > now provides + obsoletes python2-tkinter. This removes python2-tkinter (from > Fedora's "python2" package) and will install scribus+dependencies instead. That seems to be a bug. In F31 too: scribus-generator-2.8.1-3.fc31.noarch.rpm has Provides: python2-tkinter = 2.7.17 and Obsoletes: python2-tkinter < 2.7.17 There is no python module in that package, so the Provides is wrong. And anyway, Provides/Obsoletes for an unrelated package have no place in scribus-generator. Zbyszek ___ 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
scribus-generator now provides python2-tkinter in Fedora 30 ?
Hi, I noticed that the latest update for scribus-generator (pushed to stable F30) now provides + obsoletes python2-tkinter. This removes python2-tkinter (from Fedora's "python2" package) and will install scribus+dependencies instead. I don't understand why this change was done so asking here. Felix ___ 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: Encrypted DNS in Fedora
* Michael Cronenworth: > On 11/4/19 2:17 PM, Florian Weimer wrote: >> We are not going to implement this directly in glibc. You should talk >> to a stub resolver on 127.0.0.1 instead. We do not want to link a >> cryptographic library into every process that queries an Internet host >> name. That also applies to DNSSEC. > > The transition to DoT/DoH makes the resolv.conf file obsolete. Any > discussion on removing it entirely? Default to looking at a local > resolver. This is the default today. The issue is that the defaults for the DNS search path and some other options are wrong, and we will need a transition to correct that. Then we can probably remove the file, unless something else is stored there. Thanks, Florian ___ 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: Encrypted DNS in Fedora
On 04/11/2019 23:51, Michael Cronenworth wrote: > On 11/4/19 2:18 PM, Michael Catanzaro wrote: >> On Mon, Nov 4, 2019 at 12:04 pm, Stephen John Smoogen >> wrote: >>> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver >> >> Just in case of any possible confusion: this change proposal was never >> successfully implemented. > > Based on the feedback so far (thank you for the feedback!) it looks like > the best course of action is to revive this Change as a "v2" with a few > updates. The work described in the wiki might end up more complicated then it seems, but if you have enough time to finish this definitely go for it. -- Martin Sehnoutka Software Engineer Red Hat signature.asc Description: OpenPGP digital signature ___ 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
