Re: Getting security updates out to users sooner
On Fri, 17 Apr 2020 06:55:10 +0200, Michel Alexandre Salim wrote: > For kernel updates this is probably not a good idea. Given that updates > potentially introduce regressions, being able to distinguish updates with > known CVEs that we do need to roll out immediately, versus other updates we > can do more compatibility testing on, is critical. Even when there is a kernel regression a -1 vote gets immediately overvoted by the +1s of majority so the update gets pushed anyway. So I do not see what is the purpose of the voting at all. As an example: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3cd64d683c#comment-1258825 = kernel-5.5.6-201.fc31 Jan ___ 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: Getting security updates out to users sooner
Apr 16, 2020 18:02:33 Demi M. Obenour : > > Finally, some packages should have all updates considered as security > updates. This includes anything based on a web browser (Firefox, Thunderbird, > SeaMonkey, Chromium, webkit2gtk, etc), as well the Linux kernel itself. > Virtually every update of these packages fixes security vulnerabilities, so > updates to them should be considered security updates and treated as such. For kernel updates this is probably not a good idea. Given that updates potentially introduce regressions, being able to distinguish updates with known CVEs that we do need to roll out immediately, versus other updates we can do more compatibility testing on, is critical. Cheers, -- -- Michel Alexandre Salim profile: https://keybase.io/michel_slm GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2 ___ 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 Survey
On Saturday, April 11, 2020 4:30:57 AM MST Kevin Kofler wrote: > Alex Scheel wrote: > > > Look folks. This isn't a Fedora-only survey. It is a survey run by Red > > Hat > > members who are looking to engage with a community that includes Fedora, > > Red Hat, CentOS and a bunch of other stakeholders as well. I think we can > > all recognize that Google Apps usage is high among businesses. > > > That is another major concern, that decisions made by Fedora for Fedora > users depend more and more on input from people (and companies) who are NOT > Fedora users. What makes sense for RHEL and/or CentOS does not > necessarily make sense for Fedora (and for that matter, what makes sense > for RHEL also does not necessarily make sense for CentOS). Fedora decisions > should depend ONLY on the input and needs of Fedora users. > > Kevin Kofler Let's be honest, this doesn't even really make sense for RHEL. -- John M. Harris, Jr. 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: Unretire gjots2 (gtk heirarchical note jotter)
Done - https://bugzilla.redhat.com/show_bug.cgi?id=1823599 On Fri, 17 Apr 2020 at 12:50, Bob Hepple wrote: > > Well I eventually woke up, got out of bed and read my email!! > > I'll fix up the address and rebuild, no problemo. > > Cheers > > > Bob > > On Wed, 15 Apr 2020 at 01:06, Petr Pisar wrote: > > > > On Tue, Apr 14, 2020 at 04:51:04PM +0200, Alexander Ploumistos wrote: > > > On Tue, Apr 14, 2020 at 4:40 PM Petr Pisar wrote: > > > > > > > > On Tue, Apr 14, 2020 at 04:27:06PM +0200, Alexander Ploumistos wrote: > > > > > The FSF address should be the most straightforward to fix. > > > > > > > > > Straightforward, but impossible for a pacakger. Because it's a part of > > > > the > > > > license declaration, only an author can change it, as the license reads: > > > > > > > > [...]keep intact all the > > > > notices that refer to this License [...] > > > > > > > > That's the reason why I consider this rpmlint warning quite unhelpful. > > > > > > > > > > Do you mean the author of the software or the license? > > > > Author of the software. Author can replace the license declaration as well > > the > > license text. > > > > > I've seen that debated over and over again and my understanding is that > > > packagers are not supposed to patch the file, but upstream developers > > > (which > > > is the case here) should correct that error. > > > > Exactly. > > > > > Our wiki links to a version of > > > GPL 2 with the correct address: > > > https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address > > > > That's a new revision of GPL 2. Author of the license, updates it whenever > > he > > moves to a different place. That's fine. Author of the software just copies > > the updated revision into his software. That's also fine. > > > > -- Petr > > > > ___ > > 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: Unretire gjots2 (gtk heirarchical note jotter)
Well I eventually woke up, got out of bed and read my email!! I'll fix up the address and rebuild, no problemo. Cheers Bob On Wed, 15 Apr 2020 at 01:06, Petr Pisar wrote: > > On Tue, Apr 14, 2020 at 04:51:04PM +0200, Alexander Ploumistos wrote: > > On Tue, Apr 14, 2020 at 4:40 PM Petr Pisar wrote: > > > > > > On Tue, Apr 14, 2020 at 04:27:06PM +0200, Alexander Ploumistos wrote: > > > > The FSF address should be the most straightforward to fix. > > > > > > > Straightforward, but impossible for a pacakger. Because it's a part of the > > > license declaration, only an author can change it, as the license reads: > > > > > > [...]keep intact all the > > > notices that refer to this License [...] > > > > > > That's the reason why I consider this rpmlint warning quite unhelpful. > > > > > > > Do you mean the author of the software or the license? > > Author of the software. Author can replace the license declaration as well the > license text. > > > I've seen that debated over and over again and my understanding is that > > packagers are not supposed to patch the file, but upstream developers (which > > is the case here) should correct that error. > > Exactly. > > > Our wiki links to a version of > > GPL 2 with the correct address: > > https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address > > That's a new revision of GPL 2. Author of the license, updates it whenever he > moves to a different place. That's fine. Author of the software just copies > the updated revision into his software. That's also fine. > > -- Petr > > ___ > 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: Getting security updates out to users sooner
On Fri, Apr 17, 2020 at 1:01 am, Demi M. Obenour wrote: Finally, some packages should have all updates considered as security updates. This includes anything based on a web browser (Firefox, Thunderbird, SeaMonkey, Chromium, webkit2gtk, etc), as well the Linux kernel itself. Virtually every update of these packages fixes security vulnerabilities, so updates to them should be considered security updates and treated as such. I've yet to see a Linux exploit developed for a web engine vulnerability and deployed against users in the wild. Are you aware of any instance of this happening, ever? Only a very tiny minority of web engine vulnerabilities ever have exploits developed for any platform. The usual workflow is: fuzzer finds HTML that triggers an asan complaint, the end, you have a CVE. Now, that doesn't mean Linux exploits don't exist (they surely do). And it doesn't mean the vulnerabilities don't need to be fixed (they do). But let's be reasonable here. Most users are not at risk because we take some time to get the update out to users. Not unless a nation state is out to get you Cross-platform logic errors are more worrying, but it's unusual that a bug is so truly urgent that it needs to be fixed immediately. I know this happens with Firefox occasionally, but when it does, I don't think a next-day response is so bad. We do need to get updates out in a timely manner, but I would say a couple weeks is sufficiently timely for most security updates. At least with WebKit, regressions are not uncommon and a few days of testing is important to ensure quality user experience. ___ 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: Getting security updates out to users sooner
On Fri, 2020-04-17 at 01:01 +, Demi M. Obenour wrote: > Currently, security updates can take days to get to users. In > particular, Firefox and Thunderbird often take a day or more, even > though virtually every single update contains security fixes. > > We need to ensure that security updates reach stable within hours of > an upstream advisory. Why? -- 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
Getting security updates out to users sooner
Currently, security updates can take days to get to users. In particular, Firefox and Thunderbird often take a day or more, even though virtually every single update contains security fixes. We need to ensure that security updates reach stable within hours of an upstream advisory. Ideally, we should get predisclosure access to source code, so that we have packages ready to distribute the moment the announcement is made. Failing that, we need to start the build as soon as source code is available, and distribute packages as soon as they have been built for the architecture in question. And we need to devote enough resources to the build that it completes quickly. We also need to invalidate old metadata hashes whenever a security update happens. This means that updates must propagate across the update network within an hour or less, preferably minutes. How can this be accomplished? I know that substantial releng and QA effort will be needed, along with close coordination with package maintainers and upstream developers. That said, I have virtually never noticed a regression, so I consider getting a security update out quickly to be much more important. Finally, some packages should have all updates considered as security updates. This includes anything based on a web browser (Firefox, Thunderbird, SeaMonkey, Chromium, webkit2gtk, etc), as well the Linux kernel itself. Virtually every update of these packages fixes security vulnerabilities, so updates to them should be considered security updates and treated as such. Sincerely, Demi ___ 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
Getting security updates out to users sooner
Currently, security updates can take days to get to users. In particular, Firefox and Thunderbird often take a day or more, even though virtually every single update contains security fixes. We need to ensure that security updates reach stable within hours of an upstream advisory. Ideally, we should get predisclosure access to source code, so that we have packages ready to distribute the moment the announcement is made. Failing that, we need to start the build as soon as source code is available, and distribute packages as soon as they have been built for the architecture in question. And we need to devote enough resources to the build that it completes quickly. We also need to invalidate old metadata hashes whenever a security update happens. This means that updates must propagate across the update network within an hour or less, preferably minutes. How can this be accomplished? I know that substantial releng and QA effort will be needed, along with close coordination with package maintainers and upstream developers. That said, I have virtually never noticed a regression, so I consider getting a security update out quickly to be much more important. Finally, some packages should have all updates considered as security updates. This includes anything based on a web browser (Firefox, Thunderbird, SeaMonkey, Chromium, webkit2gtk, etc), as well the Linux kernel itself. Virtually every update of these packages fixes security vulnerabilities, so updates to them should be considered security updates and treated as such. ___ 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 33 System-Wide Change proposal: systemd-resolved
Once upon a time, Lennart Poettering said: > On Do, 16.04.20 07:45, John M. Harris Jr (joh...@splentity.com) wrote: > > If there are no servers configured... Shouldn't it use no servers? > > Well, our assumption is that working DNS is better than DNS that > doesn't work. Talking to servers the admin didn't configure could be an information leak and IMHO should not be on by default. You have no idea why there are no servers, so trying to second-guess it is a bad idea. -- Chris Adams ___ 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 33 System-Wide Change proposal: systemd-resolved
Once upon a time, Lennart Poettering said: > Again, we do not support DNSSEC from client to the stub. If you set CD > we'll return NOTIMP as rcode, indicating that. We do not implement a > full DNS server, but just enough for local stub clients (such as the > one implemented in glibc or Java) to work. If you want the full DNSSEC > client stuff, talk directly to the upstream DNS server. If you want to go in /etc/resolv.conf, you need to be a full resolver. There's no telling what programs expect to be able to talk the full DNS protocol to the "nameserver" lines from /etc/resolv.conf (for example, the perl Net::DNS module gets its servers from there by default, so all kinds of perl scripts could break). dnsmasq defaults to using resolvers from /etc/resolv.conf too IIRC. If you want to be a resolver, be an actual resolver, and in 2020, that includes implementing EDNS0, DNSSEC, etc. -- Chris Adams ___ 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: Why does Koschei not run real builds?
Michael Cronenworth writes: > On 4/15/20 5:52 PM, Dan Čermák wrote: >> That is pretty useful, because as a maintainer you can just update a >> library and you don't have to do a thing to get dependent packages >> rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" and >> "need a provenpackager to rebuild dependent packages of ABC" emails on >> devel. Also, if a package fails to build due to an update, it will be >> noticed right away and not until the next mass rebuild. > > Is it smart enough to only rebuild for SONAME bumps or ABI changes? No, it rebuilds once a dependency actually changes (if it is rebuild and the resulting RPM is unchanged, then no rebuild is kicked of though). > > I wouldn't want rebuilds "just because." Well, you kinda do want them (in Rawhide) because ABI changes & SONAME bumps are not applicable for all programming languages and then people & tools make mistakes. So a "safe" update without a SONAME bump might be one that actually required one and would be undetected unless you rebuild & retest dependent 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 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: ocaml-bisect-ppx and related updates
On Thu, Apr 16, 2020 at 1:00 PM Richard W.M. Jones wrote: > Sure, I can do the rebuild tomorrow, if you push the changes > today. All of the changes have been pushed. I have made utop buildable again, so if that isn't part of your rebuild plan, it would be great if you could include it. (Also, I adopted utop, since it was orphaned.) > Note I'm only going to do this in Rawhide. Sure. Fedora 32 has what it has. I'll be shifting my focus to Rawhide / F33 as well. > Also note, it might all go horribly wrong (but hey, Rawhide?!) Gosh, that's never happened before :-) -- Jerry James http://www.jamezone.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: Why does Koschei not run real builds?
> > and lines like this: > > https://pagure.io/Fedora-Infra/rpmautospec/blob/3c208f17329940977cbe1552f3d1bbee35014f93/f/rpmautospec/tag_package.py#_53 > > are not needed? > > This is not involved in the computation of the next release value. > So, do we use the build history of the package to predict the next release > value? Yes. > Do we pull this information from the build system? No, So where do you pull that information from originally? Milky way? > we push this information > from the build system into dist-git Yes, after you pull it from build system. > giving dist-git enough information to be > self-sufficient. It's not self-sufficient because it will need new and new info from new and new builds and only build system can provide that info in your approach. You are using words like "self-sufficient", "locally-reproducible", "predictable" in such contexts that they completely lose meaning. > Could the build system not push that information? Yes, we're currently > flagging > commits in dist-git upon successful build. We could use another tool to add > the > tags then instead of doing it from koji but it would introduce more delays. > But could we not use the build history of the package? Not with the approach > we > chose. Which is not the approach that formed the "consensus" you mentioned (according to my understanding of what the "consensus" was). > > Now, using the number of commit made since the last version bump would be one > way to generate the release value which would be entirely contained within > dist-git, but it isn't without drawbacks (the upgrade path can very easily be > broken with this approach, it also does not allow to rebuild a package without > doing a new commit to its git repo). We have considered those and chose not to > pursue that idea. Yes, because that idea is not finished. You should have arrived to annotated tags created by users. > Adding a build number in the release field, would require even more > involvement > of the build system than our approach and would break the "contained within > dist-git" idea. You are adding build number to release field through insane machinery. It's, by the way, not what I was suggesting. Not sure if you read what I was saying. I was saying a new field should be allocated for that and that it should be applied to rpm builds only (not srpm ones). "contained within dist-git" is not something that can be associated with your solution because you heavily employ koji/build-system. > There are really multiple ways to solve these questions, we looked at a number > of them including yours I don't think you looked very well. In fact, what I saw was mainly: "Ye, we will let you speak but, in the end, we are the bosses here and we know what to do." You are employing the same approach I have seen here before e.g. from modularity guys and guess what...that approach does not work (I really wanted to say something else than "does not work"). It's an approach of arrogance and ignorance and it leads to bad results because people are just afraid to say: "Hey, you have a point, here." or "Right, I haven't thought of that". So then people keep pushing their massive trains with lots of passengers and they are all sweaty and tired but what they do not know is that 10 meters ahead the railway ends. Still, it will take a long time to arrive at that conclusion. If you enjoy this, ok. > and made a choice that does not align with your idea, I don't think you considered my idea seriously. I haven't seen enough argumentation or enough explanation. In fact, I gave you plenty of reasons not to do what you wanted to do and feedback was zero. > but the approach and POC we're proposing does fit the set of requirements, the > UX we wanted to have and is working. Ok, but I wonder whether your requirements were very well defined then. They should have included "local-reproducibility" and "predictability". These are not satisfied. You wanted to "help with mass rebuilds". Well, what you did will work only for packages that use your black-magic macros which look like rpm macros but they have completely different behavior. E.g. that they will cause insertion of a code snippet into the spec file... Imagine you have a programming language where if you name a variable with a certain name, then it will make some text transformation on the rest of your code. Such language would be immediately considered esoteric. And that's what you have now, magical, esoteric, hardly predictable solution that requires people to know tons of intricacies of how it works. That's really not great for new-comers. And it is also not good for production use because when you start to depend on too many "sources of truth", ongoing processes (running builds), and black-magic, it just immediately starts to break down. > I am not saying your approach could not work either. We just picked two > different approaches, both of which are potentially valid. I don't think you really hear what
Re: Is there a way to mockbuild systemd?
Am 16.04.20 um 20:05 schrieb Göran Uddeborg: > As the suggestion was sent off list, I didn't want to say that. No reason to keep it secret :-) Until now I did not realize I sent you a private message (just wondered about the privat reply ;-) 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: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)
On Wed, Apr 15, 2020 at 09:45:19AM +0200, David Schwörer wrote: > On 4/14/20 11:06 AM, Miro Hrončok wrote: > > orangefs orphan 1 > > weeks ago > > I took orangefs and rebuild it. > However I am not able to close or take the FTBFS bug [1] > The documentation only says I should take the bug, but not how [2] You are affected by our sync script not correctly syncing packager perms to bugzilla: https://pagure.io/fedora-infrastructure/issue/8628 Hopefully we will get it fixed soon. In the mean time, I have manually fixed your user permissions... kevin 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: Why does Koschei not run real builds?
On Thu, Apr 16, 2020 at 03:07:37PM +0200, clime wrote: > On Thu, 16 Apr 2020 at 14:12, Pierre-Yves Chibon wrote: > > > > On Thu, Apr 16, 2020 at 12:16:16PM +0200, clime wrote: > > > On Thu, 16 Apr 2020 at 09:51, Pierre-Yves Chibon > > > wrote: > > > > > > > > On Thu, Apr 16, 2020 at 01:57:40AM +0200, clime wrote: > > > > > On Thu, 16 Apr 2020 at 00:52, Dan Čermák > > > > > wrote: > > > > > > > > > > > > clime writes: > > > > > > > > > > > > > On Mon, 13 Apr 2020 at 10:55, Dan Čermák > > > > > > > wrote: > > > > > > >> > > > > > > >> Hi list, > > > > > > >> > > > > > > >> my question is pretty much $subject: Why doesn't Koschei kick of > > > > > > >> real builds off packages on dependency changes? From my naive > > > > > > >> POV that > > > > > > >> looks like the missing piece to give us the "OBS-experience". > > > > > > >> Having > > > > > > >> that at least in Rawhide sounds like a good thing to me. > > > > > > > > > > > > > > Dan, can I have some basic questions to this because I don't know > > > > > > > OBS. > > > > > > > > > > > > > > Could you describe the feature in more detail with regards to > > > > > > > auto-rebuilding and when it is useful? > > > > > > > > > > > > In a nutshell: OBS will in its default mode rebuild each package > > > > > > once > > > > > > one of its direct or indirect dependencies changes. > > > > > > > > > > > > That is pretty useful, because as a maintainer you can just update a > > > > > > library and you don't have to do a thing to get dependent packages > > > > > > rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" > > > > > > and > > > > > > "need a provenpackager to rebuild dependent packages of ABC" emails > > > > > > on > > > > > > devel. Also, if a package fails to build due to an update, it will > > > > > > be > > > > > > noticed right away and not until the next mass rebuild. > > > > > > > > > > > > Additionally updating a bunch of packages will no longer require > > > > > > that > > > > > > you figure out the build order yourself: the build system figures > > > > > > it out > > > > > > itself by rebuilding your packages until the transitive dependencies > > > > > > stop changing. > > > > > > > > > > > > All of this is of course only really viable for Rawhide and already > > > > > > released Fedora branches should not be run like this, because one > > > > > > wrong > > > > > > update could wreck the whole distro. > > > > > > > > > > Thanks, that was a nice explanation. I personally believe there is a > > > > > good solution in extending koji and rpm. > > > > > > > > > > koji to be able to rebuild the same source package again and again > > > > > while passing a different increasing number to rpmbuild through > > > > > --define and rpm to put that number into rpm name if it was specified > > > > > to the following position: > > > > > > > > > > python3-colcon-ros-bundle-0.0.14-1.fc31..noarch.rpm > > > > > > > > > > It can be just a short build id specific for the given package (i.e. > > > > > how many builds there were for the given package). There might be a > > > > > little bit of trouble to keep meaningfully increasing in > > > > > case of multiple parallel builds but I think it should be possible. > > > > > > > > > > An advantage over the rpmautospec approach is that this will just work > > > > > for all the packages out of the box, i.e. no matter what macros they > > > > > are using. > > > > > > Pierre, maybe we can start understanding each other here. > > > > > > > > > > > Including the build number in the release field was part of the ideas > > > > submitted > > > > for feedback when we started looking at the auto-release question and > > > > there > > > > seemed to be a consensus about not wanting to have the release depend > > > > on the > > > > build system. > > > > > > I have a different understanding here :). What you did in rpmautospec > > > means that release _is_ dependant on build system because it is > > > dependant on information owned by it. > > > > No, the code generating the release field does not rely on any information > > provided by the build system, making it works fine locally. > > Yet another try: > > Are you saying this is not true? ... > > From https://pagure.io/Fedora-Infra/rpmautospec/tree/master: > "- Attempt to automatically calculate release numbers and generate an > RPM changelog from the dist-git repository of a package and the > information available in the Koji build system." Thank you for finding that. The README was definitely out-dated, and it has been fixed. > and lines like this: > https://pagure.io/Fedora-Infra/rpmautospec/blob/3c208f17329940977cbe1552f3d1bbee35014f93/f/rpmautospec/tag_package.py#_53 > are not needed? This is not involved in the computation of the next release value. So, do we use the build history of the package to predict the next release value? Yes. Do we pull this information from the build system? No, we push this information from the build system into dist
Re: ocaml-bisect-ppx and related updates
On Thu, Apr 16, 2020, 21:00 Richard W.M. Jones wrote: > On Thu, Apr 16, 2020 at 10:04:52AM -0600, Jerry James wrote: > > Sorry for the delay. In spite of being stuck in my house, life has > > been amazingly busy lately... > > > > On Mon, Apr 13, 2020 at 2:32 PM Richard W.M. Jones > wrote: > > > Long and the short is this will require some sort of OCaml pre-4.11 > > > package, and a complete rebuild of everything in Rawhide. (I'm not > > > proposing that we bother fixing OCaml for RISC-V in Fedora 32). > > > > > > We could do it this week? If it helps you. If it's going to be a > > > problem then I could delay this until you've rebuilt the packages you > > > mention below. I don't believe the delta from 4.10 to 4.11 is that > > > large, but as with any rebuild of this scale there can always be > > > unexpected problems. > > > > I'm in no hurry. In fact, it might be best if I simply push the > > necessary changes to git, then let the packages be rebuilt as part of > > your update to pre-4.11. If that works for you, I can push the > > changes today. > > Sure, I can do the rebuild tomorrow, if you push the changes > today. > > Note I'm only going to do this in Rawhide. > > Also note, it might all go horribly wrong (but hey, Rawhide?!) > If things might go horribly wrong, I suggest you use a side tag for those rebuilds :) Fabio > Rich. > > > Somebody will need to merge Dan's pull request for > > ocaml-ppx-tools-versioned. Thanks for doing that, Dan. > > -- > > Jerry James > > http://www.jamezone.org/ > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top > ___ > 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: ocaml-bisect-ppx and related updates
On Thu, Apr 16, 2020 at 10:04:52AM -0600, Jerry James wrote: > Sorry for the delay. In spite of being stuck in my house, life has > been amazingly busy lately... > > On Mon, Apr 13, 2020 at 2:32 PM Richard W.M. Jones wrote: > > Long and the short is this will require some sort of OCaml pre-4.11 > > package, and a complete rebuild of everything in Rawhide. (I'm not > > proposing that we bother fixing OCaml for RISC-V in Fedora 32). > > > > We could do it this week? If it helps you. If it's going to be a > > problem then I could delay this until you've rebuilt the packages you > > mention below. I don't believe the delta from 4.10 to 4.11 is that > > large, but as with any rebuild of this scale there can always be > > unexpected problems. > > I'm in no hurry. In fact, it might be best if I simply push the > necessary changes to git, then let the packages be rebuilt as part of > your update to pre-4.11. If that works for you, I can push the > changes today. Sure, I can do the rebuild tomorrow, if you push the changes today. Note I'm only going to do this in Rawhide. Also note, it might all go horribly wrong (but hey, Rawhide?!) Rich. > Somebody will need to merge Dan's pull request for > ocaml-ppx-tools-versioned. Thanks for doing that, Dan. > -- > Jerry James > http://www.jamezone.org/ -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ 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
[Test-Announce] Fedora 32 Final is NO-GO
The release status of Fedora 32 Final is no-go.. Due to open blocker bugs, Fedora 32 Final was declared "no-go". We will reconvene at 1700 UTC on Thursday, 23 April[1] to re-evaluate. If we determine at that time that Fedora 32 is go, it will release on the "target release date #1" of 28 April. For more information, please see the minutes[2] from the Fedora 32 Final Go/No-Go meeting. [1] https://apps.fedoraproject.org/calendar/meeting/9738/ [2] https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-16/f32-final-go_no_go-meeting.2020-04-16-16.59.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@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: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thu, Apr 16, 2020 at 8:07 pm, Florian Weimer wrote: I don't think this change is ready for Fedora, then. Florian, isn't this a quite specialized use-case of the sort where you can simply write your own /etc/resolv.conf and let resolved consume that? Or just disable resolved? How? The address is no longer in /etc/resolv.conf. According to the change proposal, this also endangers Denise, who relies on the request routing in systemd-resolved. Well, I guess you're right, you can't have all of the above. But how many users really need to use Postfix or something else that needs DNSSEC on a machine with multiple VPNs enabled...? I think resolved is a sane default for Workstation users. And for Server users, if you need more control, you can just create your own /etc/resolv.conf and things will work as before, but you lose the split DNS feature. That's OK, right? ___ 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 33 System-Wide Change proposal: systemd-resolved
* Matthew Miller: > On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote: >> > If there are no servers configured... Shouldn't it use no servers? >> Well, our assumption is that working DNS is better than DNS that >> doesn't work. > > I hope no one is using lack of configured DNS as a security measure! But I > can see a case for wanting lack of configuration to be a failure rather than > working but non-obviously not in the way you expected. At the lowest level, lack of configuration (i.e., no name servers in /etc/resolv.conf or no such file at all) currently means that 127.0.0.1 is used as the DNS resolver. This has been the case for such a long time that I think it would not be a good idea to configure different servers instead. 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: Fedora 33 System-Wide Change proposal: systemd-resolved
On Do, 16.04.20 14:07, Matthew Miller (mat...@fedoraproject.org) wrote: > On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote: > > > If there are no servers configured... Shouldn't it use no servers? > > Well, our assumption is that working DNS is better than DNS that > > doesn't work. > > I hope no one is using lack of configured DNS as a security measure! But I > can see a case for wanting lack of configuration to be a failure rather than > working but non-obviously not in the way you expected. Use FallbackDNS= to override the built-in defaults, and set it to the empty string if you want lookups to fail. Lennart -- Lennart Poettering, Berlin ___ 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: Is there a way to mockbuild systemd?
On Thu, Apr 16, 2020 at 08:19:59PM +0200, Göran Uddeborg wrote: > Zbigniew Jędrzejewski-Szmek: > > Some ways to avoid the issue: use a newer kernel, > > It is not completely clear from the bugzilla which version would be > needed, but I built it on a machine using 5.5.6-201.fc31. According > to comment 10 > (https://bugzilla.redhat.com/show_bug.cgi?id=1803070#c10) it even > fails with 5.6.3-300.fc32. How new is needed? Based on this information, it seems that it might not be related to a kernel version. 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
Re: Is there a way to mockbuild systemd?
Göran Uddeborg: > Should I file a bugzilla? Well, obviously not. https://bugzilla.redhat.com/show_bug.cgi?id=1803070 was already filed. I should have found it in my search earlier, but I didn't. ___ 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: Is there a way to mockbuild systemd?
Zbigniew Jędrzejewski-Szmek: > Some ways to avoid the issue: use a newer kernel, It is not completely clear from the bugzilla which version would be needed, but I built it on a machine using 5.5.6-201.fc31. According to comment 10 (https://bugzilla.redhat.com/show_bug.cgi?id=1803070#c10) it even fails with 5.6.3-300.fc32. How new is needed? ___ 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-IoT-32-20200416.0 compose check report
No missing expected images. Passed openQA tests: 8/8 (x86_64) New passes (same test not passed in Fedora-IoT-32-20200414.0): ID: 578977 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/578977 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: 1 services(s) removed since previous compose: zezere_ignition.service Previous test data: https://openqa.fedoraproject.org/tests/576544#downloads Current test data: https://openqa.fedoraproject.org/tests/578972#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: 1 services(s) removed since previous compose: zezere_ignition.service Previous test data: https://openqa.fedoraproject.org/tests/576545#downloads Current test data: https://openqa.fedoraproject.org/tests/578973#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 33 System-Wide Change proposal: systemd-resolved
* Lennart Poettering: > On Do, 16.04.20 17:14, Florian Weimer (fwei...@redhat.com) wrote: > >> > I don't think we can reliably determine whether people have deployed >> > things in a way that relies on /etc/resolv.conf only listing a fully >> > blown DNS server or who are fine with it being a more restricted stub >> > like systemd-resolved. >> >> Unfortunately, I see something similar to what Tom Hughes reported >> earlier: dig +dnssec responses are not even correctly formatted. The CD >> query flag is not handled, either. The AD bit is not set on validated >> responses. I also see some really strange stability issues. It seems >> that resolved is incorrectly blacklisting upstream servers with an >> incompatible-server error after a validation failure. > > Again, we do not support DNSSEC from client to the stub. I don't think this change is ready for Fedora, then. > If you set CD we'll return NOTIMP as rcode, indicating that. We do not > implement a full DNS server, but just enough for local stub clients > (such as the one implemented in glibc or Java) to work. Sorry? RES_USE_DNSSEC is part of the glibc stub resolver. It does not work anymore. The libunbound validator is broken by this, too. > If you want the full DNSSEC client stuff, talk directly to the > upstream DNS server. How? The address is no longer in /etc/resolv.conf. According to the change proposal, this also endangers Denise, who relies on the request routing in systemd-resolved. 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: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote: > > If there are no servers configured... Shouldn't it use no servers? > Well, our assumption is that working DNS is better than DNS that > doesn't work. I hope no one is using lack of configured DNS as a security measure! But I can see a case for wanting lack of configuration to be a failure rather than working but non-obviously not in the way you expected. -- 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: Is there a way to mockbuild systemd?
Pavel Raiskup: > Who gave you this suggestion, As the suggestion was sent off list, I didn't want to say that. I don't know the reason he didn't send it to the public list but just to me. > haven't you tried to fill an issue against > systemd No, I have not. I assumed it was something I did wrong, not a bug in systemd. Should I file a bugzilla? ___ 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 33 System-Wide Change proposal: systemd-resolved
On Do, 16.04.20 17:14, Florian Weimer (fwei...@redhat.com) wrote: > > I don't think we can reliably determine whether people have deployed > > things in a way that relies on /etc/resolv.conf only listing a fully > > blown DNS server or who are fine with it being a more restricted stub > > like systemd-resolved. > > Unfortunately, I see something similar to what Tom Hughes reported > earlier: dig +dnssec responses are not even correctly formatted. The CD > query flag is not handled, either. The AD bit is not set on validated > responses. I also see some really strange stability issues. It seems > that resolved is incorrectly blacklisting upstream servers with an > incompatible-server error after a validation failure. Again, we do not support DNSSEC from client to the stub. If you set CD we'll return NOTIMP as rcode, indicating that. We do not implement a full DNS server, but just enough for local stub clients (such as the one implemented in glibc or Java) to work. If you want the full DNSSEC client stuff, talk directly to the upstream DNS server. We set AD only if we managed to authenticate ourselves, which can either be via DNSSEC if that's enabled to the upstream DNS server. We also set it for hosts we read from /etc/hosts (i.e. a source owned by root). If you saw incompatible server this looks like you left DNSSEC on between resolved and upstream DNS server? Again, this is not what we intend to do in Fedora. Lennart -- Lennart Poettering, Berlin ___ 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 33 System-Wide Change proposal: systemd-resolved
On Do, 16.04.20 07:45, John M. Harris Jr (joh...@splentity.com) wrote: > If there are no servers configured... Shouldn't it use no servers? Well, our assumption is that working DNS is better than DNS that doesn't work. Lennart -- Lennart Poettering, Berlin ___ 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 compose report: 20200416.n.0 changes
OLD: Fedora-32-20200415.n.0 NEW: Fedora-32-20200416.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 3 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 36.70 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 379.93 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: anaconda-32.24.6-1.fc32 Old package: anaconda-32.24.5-1.fc32 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 19.10 MiB Size change: -164.19 KiB Changelog: * Tue Apr 14 2020 Martin Kolman - 32.24.6-1 - network tui: fix getting of network device configurations (#1823011) (rvykydal) Package: appstream-data-32-6.fc32 Old package: appstream-data-32-5.fc32 Summary: Fedora AppStream metadata RPMs: appstream-data Size: 16.73 MiB Size change: 543.43 KiB Changelog: * Mon Apr 13 2020 Richard Hughes 32-6 - New metadata version Package: firewalld-0.8.2-2.fc32 Old package: firewalld-0.8.2-1.fc32 Summary: A firewall daemon with D-Bus interface providing a dynamic firewall RPMs: firewall-applet firewall-config firewalld firewalld-filesystem python3-firewall Size: 885.72 KiB Size change: 707 B Changelog: * Tue Apr 14 2020 Tomas Popela - 0.8.2-2 - Let Silverblue follow the same rules as Workstation (after Silverblue started to use fedora-release-silverblue instead of fedora-release-workstation) = DOWNGRADED 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: ocaml-bisect-ppx and related updates
Sorry for the delay. In spite of being stuck in my house, life has been amazingly busy lately... On Mon, Apr 13, 2020 at 2:32 PM Richard W.M. Jones wrote: > Long and the short is this will require some sort of OCaml pre-4.11 > package, and a complete rebuild of everything in Rawhide. (I'm not > proposing that we bother fixing OCaml for RISC-V in Fedora 32). > > We could do it this week? If it helps you. If it's going to be a > problem then I could delay this until you've rebuilt the packages you > mention below. I don't believe the delta from 4.10 to 4.11 is that > large, but as with any rebuild of this scale there can always be > unexpected problems. I'm in no hurry. In fact, it might be best if I simply push the necessary changes to git, then let the packages be rebuilt as part of your update to pre-4.11. If that works for you, I can push the changes today. Somebody will need to merge Dan's pull request for ocaml-ppx-tools-versioned. Thanks for doing that, Dan. -- Jerry James http://www.jamezone.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
Fedora rawhide compose report: 20200416.n.0 changes
OLD: Fedora-Rawhide-20200415.n.0 NEW: Fedora-Rawhide-20200416.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 5 Dropped packages:4 Upgraded packages: 142 Downgraded packages: 0 Size of added packages: 146.24 MiB Size of dropped packages:2.03 MiB Size of upgraded packages: 3.43 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 93.25 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20200416.n.0.iso Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20200416.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = Package: cri-o-2:1.18.0-0.1.rc1.module_f33+8643+125472ae Summary: Kubernetes Container Runtime Interface for OCI-based containers RPMs:cri-o Size:120.00 MiB Package: golang-github-antchfx-xpath-1.1.5-1.fc33 Summary: XPath package RPMs:golang-github-antchfx-xpath-devel Size:31.72 KiB Package: golang-github-nbutton23-zxcvbn-0.1-1.20200415gitae427f1.fc33 Summary: Zxcvbn password complexity algorithm RPMs:golang-github-nbutton23-zxcvbn golang-github-nbutton23-zxcvbn-devel Size:6.52 MiB Package: openmpi-3.1.6-1.module_f33+8674+f185d4cf Summary: Open Message Passing Interface RPMs:openmpi openmpi-devel openmpi-java openmpi-java-devel python2-openmpi python3-openmpi Size:19.66 MiB Package: python-colcon-ros-bundle-0.0.14-1.fc33 Summary: Plugin for colcon to bundle ros applications RPMs:python3-colcon-ros-bundle Size:31.49 KiB = DROPPED PACKAGES = Package: phpPgAdmin-5.6-12.fc32 Summary: Web-based PostgreSQL administration RPMs:phpPgAdmin Size:612.54 KiB Package: postgresql-dbi-link-2.0.0-21.fc32 Summary: Partial implementation of the SQL/MED portion of the SQL:2003 specification RPMs:postgresql-dbi-link Size:567.39 KiB Package: postgresql-pgpoolAdmin-3.6.1-7.fc32 Summary: PgpoolAdmin - web-based pgpool administration RPMs:postgresql-pgpoolAdmin Size:866.28 KiB Package: postgresql_autodoc-1.41-13.fc32 Summary: PostgreSQL AutoDoc Utility RPMs:postgresql_autodoc Size:28.97 KiB = UPGRADED PACKAGES = Package: NetworkManager-fortisslvpn-1.3.90-7.fc33 Old package: NetworkManager-fortisslvpn-1.3.90-6.fc33 Summary: NetworkManager VPN plugin for Fortinet compatible SSLVPN RPMs: NetworkManager-fortisslvpn NetworkManager-fortisslvpn-gnome Size: 692.75 KiB Size change: 2.53 KiB Changelog: * Wed Apr 15 2020 Simone Caronni - 1.3.90-7 - Update DNS handling patch. Package: WALinuxAgent-2.2.46-1.fc33 Old package: WALinuxAgent-2.2.40-7.fc32 Summary: The Microsoft Azure Linux Agent RPMs: WALinuxAgent Size: 364.21 KiB Size change: 31.78 KiB Changelog: * Wed Apr 15 2020 Vitaly Kuznetsov - 2.2.46-1 - Update to 2.2.46 Package: arduino-1:1.8.12-1.fc33 Old package: arduino-1:1.8.5-11.fc33 Summary: An IDE for Arduino-compatible electronics prototyping platforms RPMs: arduino arduino-core arduino-devel arduino-doc Added RPMs: arduino-devel Size: 8.47 MiB Size change: -2.48 MiB Changelog: * Mon Apr 13 2020 ElXreno - 1:1.8.5-12 - Fixed run script. RHBZ#1823195 * Mon Apr 13 2020 ElXreno - 1:1.8.12-1 - Updated to version 1.8.12 Package: backupninja-1.1.0-5.fc33 Old package: backupninja-1.1.0-4.fc32 Summary: Lightweight, extensible backup system RPMs: backupninja Size: 100.25 KiB Size change: -59 B Changelog: * Wed Apr 15 2020 Denis Fateyev - 1.1.0-5 - Update patch set for backupninja-1.1.0 Package: cjdns-20.6-1.fc33 Old package: cjdns-20.5-2.fc32 Summary: The privacy-friendly network without borders RPMs: cjdns cjdns-graph cjdns-selinux cjdns-tools python3-cjdns Size: 2.46 MiB Size change: -383.34 KiB Changelog: * Mon Mar 16 2020 Stuart Gathman - 20.5-3 - Rebuilt for Fedora 33 - Minor doc updates * Mon Mar 16 2020 Stuart Gathman - 20.6-1 - New upstream release Package: clojure-1:1.10.1-1.fc33 Old package: clojure-1:1.9.0-1.fc33 Summary: A dynamic programming language that targets the Java Virtual Machine RPMs: clojure Size: 3.32 MiB Size change: 190.54 KiB Changelog: * Wed Apr 15 2020 Markku Korkeala - 1:1.10.1-1 - Update to upstream release 1.10.1 - Update clojure-spec-alpha and clojure-core-specs-alpha dependency - Remove jsr166y pom_remove_dep Package: clojure-core-specs-alpha-1:0.2.44-1.fc33 Old package: clojure-core-specs-alpha-1:0.1.24-2.fc33 Summary: Clojure library containing specs to describe Clojure core macros and functions RPMs: clojure-core-specs-alpha Size: 20.00 KiB Size change: 304 B Changelog: * Wed Apr 15 2020 Markku Korkeala - 1:0.2.44-1 - Update upstream to 0.2.44 and clojure dependency to 1.9.0. Package: clojure-spec
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thu, Apr 16, 2020 at 07:41:07AM -0700, John M. Harris Jr wrote: > > Really, it may be best to go about this in the same way as Ubuntu, with nss- > dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done > on Fedora, especially on servers. In fact, I never knew that NetworkManager > would clobber that until this thread. If this isn't mean to wreck everyone's > systems, backwards compatibility is key. Relying on nss_dns causes bugs like https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320 (systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing entries). It still gets (angry) comments, years after it was filled. -- Tomasz Torcz There exists no separation between gods and men: to...@pipebreaker.pl one blends softly casual into the other. — Frank Herbert ___ 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 33 System-Wide Change proposal: systemd-resolved
* Tomas Mraz: > On Wed, 2020-04-15 at 10:02 -0500, Michael Catanzaro wrote: >> On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer >> wrote: >> > Not sure if that's compatible with the new split DNS model because >> > VPN1 >> > could simply start pushing longer names in the scope of VPN2, thus >> > hijacking internal traffic there (and this sort of hijacking is >> > exactly >> > what a DNS sinkhole against typosquatting would need). >> >> You deserve bonus points for thinking like an attacker and exploring >> the security model, but let's assume the configured VPNs are >> trusted. >> Otherwise the user is screwed no matter what. ;) > > Trusted for what? I would expect corporate VPNs doing such tricks to > monitor the user's internet traffic. Which does not mean the user is > fully screwed with such VPN if he for example uses hardcoded > configuration of a caching nameserver. Yes, what I described was given as a motivation for this change. I find the response puzzling. I would definitely like to see greater robustness to hostile networks, but it is a lot of work. Really a lot. Lots of code to review, and quite a few shell scripts as well. 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: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thu, Apr 16, 2020 at 7:55 am, John M. Harris Jr wrote: Correcting what I said above, perhaps it'd be best to use what Lennart mentions as "mode 1" of systemd-resolved, such that /etc/resolv.conf is read, while using nss-resolve. If you want to do that, you can. You just need to make /etc/resolv.conf a regular file, not a symlink. The text of the change proposal is wrong; I'll fix it. ___ 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 33 System-Wide Change proposal: systemd-resolved
* Lennart Poettering: > On Do, 16.04.20 12:49, Florian Weimer (fwei...@redhat.com) wrote: > >> As explained elsewhere, NetworkManager-openvpn extracts the search list >> from OpenVPN parameters, passes that to NetworkManager, which I expect >> will pass ito to systemd-resolved in the future. >> >> >> Ugh. That will have to be fixed, otherwise it will break DANE/TLSA >> >> and >> >> other DNSSEC-mandatory functionality on upgrades: the system used to >> >> have a DNSSEC-clean path to the outside world, and after the switch to >> >> systemd-resolved, it won't. >> > >> > I think that, if you need DNSSEC, you will just need to enable it >> > manually. I think >99% of users won't need to do this, and it's a >> > one-line config file change for power users who do need it, just edit >> > /etc/systemd/resolved.conf and then restart systemd-resolved >> > service. Problem is that DNSSEC is just not safe to enable by >> > default. :( >> >> See my message to Lennart about separate DO/CD query caching. >> >> My point is that these users *have* enabled DNSSEC in their >> infrastructure, and we break what they have during an update (assuming >> that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather >> than just disabling validation). > > Maybe a safer bet might be to leave resolved off during upgrades on > the server edition? A Fedora upgrade can also mean reprovision from start via kickstart/ansible, so I assume that this isn't a proper mitigation, sorry. > I don't think we can reliably determine whether people have deployed > things in a way that relies on /etc/resolv.conf only listing a fully > blown DNS server or who are fine with it being a more restricted stub > like systemd-resolved. Unfortunately, I see something similar to what Tom Hughes reported earlier: dig +dnssec responses are not even correctly formatted. The CD query flag is not handled, either. The AD bit is not set on validated responses. I also see some really strange stability issues. It seems that resolved is incorrectly blacklisting upstream servers with an incompatible-server error after a validation failure. This is with systemd-245.4-1.fc33.x86_64 in rawhide. Is this approximately what will land in Fedora 33? Or is this old code, long replaced upstream? 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: Fedora 33 System-Wide Change proposal: systemd-resolved
On Thursday, April 16, 2020 7:41:07 AM MST John M. Harris Jr wrote: > Really, it may be best to go about this in the same way as Ubuntu, with > nss- dns instead of nss-resolve.. Editing /etc/resolv.conf is still > commonly done on Fedora, especially on servers. In fact, I never knew that > NetworkManager would clobber that until this thread. If this isn't mean to > wreck everyone's systems, backwards compatibility is key. > > If not by using nss-dns, could systemd-resolved be modified such that it > would read /etc/resolv.conf? Correcting what I said above, perhaps it'd be best to use what Lennart mentions as "mode 1" of systemd-resolved, such that /etc/resolv.conf is read, while using nss-resolve. -- 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 33 System-Wide Change proposal: systemd-resolved
On 4/15/20 17:06, James Cassell wrote:
> On Wed, Apr 15, 2020, at 1:27 PM, Daniel Walsh wrote:
>> On 4/15/20 10:07, Lennart Poettering wrote:
>>> On Di, 14.04.20 15:57, James Cassell (fedoraproj...@cyberpear.com) wrote:
>>>
On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/systemd-resolved
>
> == Summary ==
>
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
>
> == Owner ==
> * Name: [[User:catanzaro| Michael Catanzaro]]
> * Email:
>
> == Detailed Description ==
>
> We will enable systemd-resolved by default.
Does this require systemd to be running? How does this affect DNS
resolution on a Fedora 33 container?
>>> Depends.
>>>
>>> If a container manager copies in /etc/resolv.conf from the host into
>>> the container on container *start*, it might be wise to copy in
>>> /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it
>>> exists. That file in /run contains the currently up-to-date upstream
>>> DNS info literally.
>> Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way
>> they can modify it internally,
>>
>> It looks like podman will just follow the link. I setup this simple test
>>
>> # ls -l /etc/resolv.conf
>> lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf
>> # cat /etc/resolv.conf
>> # Generated by NetworkManager
>> search redhat.com
>> nameserver 10.5.30.160
>> nameserver 10.11.5.19
>> nameserver 192.168.1.1
>> # podman run fedora cat /etc/resolv.conf
>> search redhat.com
>> nameserver 10.5.30.160
>> nameserver 10.11.5.19
>> nameserver 192.168.1.1
>>
>> So as long as the
>>
>> /run/systemd/resolve/resolv.conf
>>
>> file is properly formated, our container engines will just work.
>>
> I think there's some existing black magic to handle the case when resolv.conf
> references 127.0.0.1... maybe it already also works for 127.0.0.53.
> Otherwise, maybe it could be patched to handle 127.0.0.0/8 in the same way.
> Then no special casing for resolved would be needed.
>
> V/r,
> James Cassell
Yes I believe the container engines see 127.0.0.1 and switch it to 8.8.8.8
>>> If a container builder copies in /etc/resolv.conf during build time,
>>> it probably should insert something like 8.8.8.8 as DNS servers there,
>>> also replacing whatever is there.
>>>
>>> Note that the logic in systemd and resolved is very defensive: if
>>> /etc/resolv.conf is not a symlink to
>>> /run/systemd/resolve/{stub-,}resolv.conf then resolved will consume
>>> /etc/resolv.conf instead of managing it (see other mail), hence a
>>> container mgr/builder that wants to direct DNS traffic somewhere
>>> should just override the file to whatever it wants, and things will
>>> just work, regarldess if resolved runs in the container or not, and
>>> resolved -- if used -- will honour whatever the container mgr/builder
>>> put there.
>>>
>>> Lennart
>>>
> ___
> 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: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wednesday, April 15, 2020 6:34:56 AM MST Lennart Poettering wrote: > On Di, 14.04.20 12:57, Kevin Fenzi (ke...@scrye.com) wrote: > > > > Can you expand on what that means? > > > > > > > > Does it mean: > > > > > > > > a) systemd-resolved will use DNS over TLS if it detects that > > the nameservers it is querying can do so (ie, it would do a query to > > port 853 of the nameservers dhcp or static config gave it) > > > > > > > > b) systemd-resolved will use DNS over TLS and always use some 'well > > known' public dns servers for queries, ignoring locally configured > > servers. > > > Nah. We will only talk to configured DNS servers. If no DNS servers > are configured at all we'll try to use a default set of DNS servers > however, which can be specified when building systemd. it's a fallback > to make things more robust, i.e. making sure DNS works if possible. > > Lennart > > -- > Lennart Poettering, Berlin If there are no servers configured... Shouldn't it use no servers? -- 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 33 System-Wide Change proposal: systemd-resolved
On Thu, Apr 16, 2020 at 4:18 pm, Tomas Mraz wrote: Trusted for what? I would expect corporate VPNs doing such tricks to monitor the user's internet traffic. Which does not mean the user is fully screwed with such VPN if he for example uses hardcoded configuration of a caching nameserver. In Florian's scenario, one of the VPNs is actively malicious. E.g. public-vpn.example.com tries to hijack DNS for subdomain.corporation.example.com. It might actually be a realistic attack scenario, but it's not something we should attempt to mitigate. Anyway this goes both ways. As explained many times already, without systemd-resolved, the VPN you connect to first gets all the DNS queries currently. Normally users connect to public VPN first, then corporate VPN second. That's broken. Splitting the DNS is just the right thing to do. If you want the corporate VPN to see everything, then do not check "use this VPN only for resources on its network" and it will get everything (but then it needs to have capacity to really handle everything!). Michael ___ 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 33 System-Wide Change proposal: systemd-resolved
On Tuesday, April 14, 2020 12:23:27 PM MST Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/systemd-resolved > > == Summary == > > Enable systemd-resolved by default. glibc will perform name resolution > using nss-resolve rather than nss-dns. > > == Owner == > * Name: [[User:catanzaro| Michael Catanzaro]] > * Email: > > == Detailed Description == > > We will enable systemd-resolved by default. > > # We will change the > [https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233e5 > e984a487e385def0ddca/f/90-default.preset fedora-release presets] to enable > systemd-resolved instead of disable it. > # systemd-libs currently has > [https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede > 5d234b7878753/f/systemd.spec#_606 a %post scriplet] to enable > nss-myhostname and nss-systemd by either (a) modifying authselect's > user-nsswitch.conf template, if authselect is in use, or (b) directly > modifying /etc/nsswitch.conf otherwise. We will work with the systemd > maintainers to enable nss-resolve here as well. > # We will work with the authselect maintainers to update authselect's > minimal and nis profiles to enforce nss-resolve. These profiles modify > the hosts line of /etc/resolv.conf. (By default, Fedora uses > authselect's sssd profile, which does not modify the hosts line and > therefore does not have this problem.) > # We will remove our downstream patch to systemd that prevents systemd > from symlinking /etc/resolv.conf to > /run/systemd/resolve/stub-resolv.conf on new installs. For system > upgrades, a systemd-libs %post scriptlet will be used to reassign the > symlink during upgrade. Upon detecting this symlink, NetworkManager > will automatically enable its systemd-resolved support and configure > split DNS as appropriate. > > systemd-resolved has been enabled by default in Ubuntu since Ubuntu > 16.10, but please note we are doing this differently than Ubuntu has. > Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional > nss-dns provided by glibc upstream, so glibc on Ubuntu continues to > read /etc/resolv.conf, as is traditional. This extra step is not > useful and not recommended by upstream. We want to follow upstream > recommendations in using nss-resolve instead. > > If you do not wish to use systemd-resolved, then manual intervention > will be required to disable it: > > * Modify /etc/authselect/user-nsswitch.conf and remove `resolve > [!UNAVAIL=return]` from the hosts line. Run `authselect > apply-changes`. (If you have disabled authselect, then edit > /etc/nsswitch.conf directly.) > * Disable and stop systemd-resolved.service. > * Restart the NetworkManager service. NetworkManager will then create > a traditional /etc/resolv.conf. (If you are not using NetworkManager, > you may create your own /etc/resolv.conf.) > > == Benefit to Fedora == > > === Standardization === > > Fedora will continue its history of enabling new systemd-provided > services whenever it makes sense to do so. Standardizing on upstream > systemd services is beneficial to the broader Linux ecosystem in > addition to Fedora, since standardizing reduces behavior differences > between different Linux distributions. Sadly, Fedora is no longer > leading in this area. Ubuntu has enabled systemd-resolved by default > since Ubuntu 16.10, so by the time Fedora 33 is released, we will be > three years behind Ubuntu here. > > === resolvectl === > > `resolvectl` has several useful functions (e.g. `resolvectl status` or > `resolvectl query`) that will be enabled out-of-the-box. > > === Caching === > > systemd-resolved caches DNS queries for a short while. This can > [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846 > dramatically] improve performance for applications that do not already > manually cache their own DNS results. (Generally, only web browsers > bother with manually caching DNS results.) > > === Split DNS === > > When systemd-resolved is enabled, users who use multiple VPNs at the > same time will notice that DNS requests are now sent to the correct > DNS server by default. Previously, this scenario would result in > embarrassing "DNS leaks" and, depending on the order that the VPN > connections were established, possible failure to resolve private > resources. These scenarios will now work properly. For example, > consider the scenario of Distrustful Denise, who (quite reasonably) > does not trust her ISP. Denise uses a public VPN service, > public-vpn.example.com, to hide her internet activity from her ISP, > but she also needs to use her employer's corporate VPN, > corporation.example.com, in order to access internal company resources > while working from home. Using the Network panel in System Settings, > Denise has configured her employer's VPN to "use this connection only > for resources on its network." Distrustful Denise expects that her > employer's VPN will receive all traffic for corporation.example.com, > and no
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Wed, 2020-04-15 at 10:02 -0500, Michael Catanzaro wrote: > On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer > wrote: > > Not sure if that's compatible with the new split DNS model because > > VPN1 > > could simply start pushing longer names in the scope of VPN2, thus > > hijacking internal traffic there (and this sort of hijacking is > > exactly > > what a DNS sinkhole against typosquatting would need). > > You deserve bonus points for thinking like an attacker and exploring > the security model, but let's assume the configured VPNs are > trusted. > Otherwise the user is screwed no matter what. ;) Trusted for what? I would expect corporate VPNs doing such tricks to monitor the user's internet traffic. Which does not mean the user is fully screwed with such VPN if he for example uses hardcoded configuration of a caching nameserver. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ 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 33 System-Wide Change proposal: systemd-resolved
* Lennart Poettering: > On Do, 16.04.20 12:53, Florian Weimer (fwei...@redhat.com) wrote: > >> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf. >> >> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will >> still forward queries to the daemon, which contacts the upstream server >> on nss_resolve's behave (possibly with some caching), and eventually >> return the data to the application? > > correct. > >> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the >> data? > > no. Okay, this behavior is nice and what I expect. 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: Fedora 33 System-Wide Change proposal: systemd-resolved
On Do, 16.04.20 12:53, Florian Weimer (fwei...@redhat.com) wrote: > > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf. > > So if /etc/resolv.conf comes from somewhere else, then nss_resolve will > still forward queries to the daemon, which contacts the upstream server > on nss_resolve's behave (possibly with some caching), and eventually > return the data to the application? correct. > Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the > data? no. Lennart -- Lennart Poettering, Berlin ___ 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 33 System-Wide Change proposal: systemd-resolved
On Do, 16.04.20 15:26, Florian Weimer (fwei...@redhat.com) wrote: > If /etc/resolv.conf is a regular file, will systemd-resolved deactivate > itself? Or use the name server configuration found there instead? It will use it. It's smart on this: if it finds a symlink there that points to one of the files resolved manages it will assume it will not read the files, and assume it's the *provider*, not the *consumer* of them. But if it finds a regular file there it understands that and becomes a *consumer* of that file, like any other tool, and knows it doesn't provide the file anymore. Lennart -- Lennart Poettering, Berlin ___ 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 33 System-Wide Change proposal: systemd-resolved
On Do, 16.04.20 12:46, Florian Weimer (fwei...@redhat.com) wrote: > * Lennart Poettering: > > > Long story short: if you experienced issues with DNSSEC on with > > resolved today, then be assured that with DNSSEC off things are much > > much better, and that's how we'd ship it in Fedora if it becomes the > > default. > > Would you please clarify what switching DNSSEC off means? Just no > validation, or no DNSSEC support at all? It means we'd not attempt to validate DNS response we get with DNSSEC and just trust them blindly, i.e. like this always worked. It would still be compiled in, and be opt-in. And it works fine with a well-behaving uptsream DNS servers, but given that so many public networks I know have no well behaved upstream DNS servers it would be opt-in. > I'm worried that the following scenario will break: A Fedora system on a > uses a DNSSEC-capable resolver (validating or not) and performs its own > DNSSEC validation, using data obtained by contacting the name servers in > /etc/resolv.conf. (/etc/resolv.conf is managed by NetworkManager or > cloud-init in this scenario.) So, yes, if you attempt to use a client-side validating resolver against resolved's DNS stub you will not be happy. But you'll get a clean error back, and you will find something about it in syslog. it's not ideal, but it's usually OK. i.e. It's going to be like you talk to a DNS server that simply cannot do DNSSEC, except better, because you get helpful logging in syslog. If you want a client-side validating resolver to work you need to bypass resolved, for example using the DNS server data in /run/systemd/resolve/resolv.conf. Or by using 8.8.8.8 or so directly... > Since /etc/resolv.conf is already managed, I expect that after the > upgrade, systemd-resolved will be active, with the same upstream > recursive resolvers as before. The new /etc/resolv.conf contents will > point to the local systemd-resolved DNS service, though. Exactly. Lennart -- Lennart Poettering, Berlin ___ 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 33 System-Wide Change proposal: systemd-resolved
On Thu, Apr 16, 2020, at 9:26 AM, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > > On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote: > >> * Lennart Poettering: > >> > >> > On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote: > >> > > >> >> On Mi, 15.04.20 15:50, Florian Weimer (fwei...@redhat.com) wrote: > >> >> > >> >> > * Lennart Poettering: > >> >> > > >> >> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it > >> >> > >for DNS configuration, and never change it or modify it or > >> >> > > replace > >> >> > >it. If this mode is selected arbitrary other programs that do DNS > >> >> > >will talk directly to the provided DNS servers, and resolved is > >> >> > > out > >> >> > >of the loop. > >> >> > > >> >> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts > >> >> > > itself into DNS resolution in any way. > >> >> > > >> >> > What will nss_resolve do in this case? Nothing? > >> >> > >> >> The nss_resolve module is just a wrapper around resolved's bus > >> >> API. And the bus API uses resolved's own DNS resolution code. And > >> >> resolved is smart enough to automatically become a *consumer* of > >> >> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular > >> >> file instead of a symlink to resolved's own files in /run. > >> > > >> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf. > >> > >> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will > >> still forward queries to the daemon, which contacts the upstream server > >> on nss_resolve's behave (possibly with some caching), and eventually > >> return the data to the application? > > > > nss-resolve is enabled/disabled through nsswitch.conf. It always talks to > > systemd-resolved using local IPC. It doesn't care about /etc/resolv.conf > > in any way. > > > > What Lennart wrote above applies to systemd-resolved and to things > > which look at /etc/resolv.conf for some reason. If nss-resolve is enabled, > > then only things which do not use nss at all would fall into this category. > > > >> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the > >> data? > > > > nss_resolve fails with UNAVAIL when systemd-resolved is not running. > > So yeah, we use want to use nss_dns as a fallback for that case. I'm not > > sure if that is what you are asking about. > > Let me rephrase: > > If /etc/resolv.conf is a regular file, will systemd-resolved deactivate > itself? Or use the name server configuration found there instead? > Based on earlier replies in the thread, resolved will use the nameservers from the file. There's no mention of it disabling itself. V/r, James Cassell ___ 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 33 System-Wide Change proposal: systemd-resolved
On Do, 16.04.20 12:49, Florian Weimer (fwei...@redhat.com) wrote: > As explained elsewhere, NetworkManager-openvpn extracts the search list > from OpenVPN parameters, passes that to NetworkManager, which I expect > will pass ito to systemd-resolved in the future. > > >> Ugh. That will have to be fixed, otherwise it will break DANE/TLSA > >> and > >> other DNSSEC-mandatory functionality on upgrades: the system used to > >> have a DNSSEC-clean path to the outside world, and after the switch to > >> systemd-resolved, it won't. > > > > I think that, if you need DNSSEC, you will just need to enable it > > manually. I think >99% of users won't need to do this, and it's a > > one-line config file change for power users who do need it, just edit > > /etc/systemd/resolved.conf and then restart systemd-resolved > > service. Problem is that DNSSEC is just not safe to enable by > > default. :( > > See my message to Lennart about separate DO/CD query caching. > > My point is that these users *have* enabled DNSSEC in their > infrastructure, and we break what they have during an update (assuming > that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather > than just disabling validation). Maybe a safer bet might be to leave resolved off during upgrades on the server edition? I don't think we can reliably determine whether people have deployed things in a way that relies on /etc/resolv.conf only listing a fully blown DNS server or who are fine with it being a more restricted stub like systemd-resolved. I'd claim it's reasonably safe to declare that on workstations having a restrictive stub between local clients and a real DNS server is OK, but maybe for servers we don't want to make such a claim, dunno, and just enable this for newly deployed stuff but not on upgraded stuff. Lennart -- Lennart Poettering, Berlin ___ 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-IoT-33-20200416.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Passed openQA tests: 8/8 (x86_64) New passes (same test not passed in Fedora-IoT-33-20200415.0): ID: 578629 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/578629 ID: 578630 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/578630 ID: 578634 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/578634 Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: 2 services(s) removed since previous compose: getty@tty6.service, zezere_ignition.service System load changed from 0.03 to 0.18 Previous test data: https://openqa.fedoraproject.org/tests/577571#downloads Current test data: https://openqa.fedoraproject.org/tests/578629#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: 2 services(s) removed since previous compose: getty@tty6.service, zezere_ignition.service Previous test data: https://openqa.fedoraproject.org/tests/577572#downloads Current test data: https://openqa.fedoraproject.org/tests/578630#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 33 System-Wide Change proposal: systemd-resolved
* Zbigniew Jędrzejewski-Szmek: > On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote: >> * Lennart Poettering: >> >> > On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote: >> > >> >> On Mi, 15.04.20 15:50, Florian Weimer (fwei...@redhat.com) wrote: >> >> >> >> > * Lennart Poettering: >> >> > >> >> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it >> >> > >for DNS configuration, and never change it or modify it or replace >> >> > >it. If this mode is selected arbitrary other programs that do DNS >> >> > >will talk directly to the provided DNS servers, and resolved is out >> >> > >of the loop. >> >> > >> >> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts >> >> > > itself into DNS resolution in any way. >> >> > >> >> > What will nss_resolve do in this case? Nothing? >> >> >> >> The nss_resolve module is just a wrapper around resolved's bus >> >> API. And the bus API uses resolved's own DNS resolution code. And >> >> resolved is smart enough to automatically become a *consumer* of >> >> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular >> >> file instead of a symlink to resolved's own files in /run. >> > >> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf. >> >> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will >> still forward queries to the daemon, which contacts the upstream server >> on nss_resolve's behave (possibly with some caching), and eventually >> return the data to the application? > > nss-resolve is enabled/disabled through nsswitch.conf. It always talks to > systemd-resolved using local IPC. It doesn't care about /etc/resolv.conf > in any way. > > What Lennart wrote above applies to systemd-resolved and to things > which look at /etc/resolv.conf for some reason. If nss-resolve is enabled, > then only things which do not use nss at all would fall into this category. > >> Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the >> data? > > nss_resolve fails with UNAVAIL when systemd-resolved is not running. > So yeah, we use want to use nss_dns as a fallback for that case. I'm not > sure if that is what you are asking about. Let me rephrase: If /etc/resolv.conf is a regular file, will systemd-resolved deactivate itself? Or use the name server configuration found there instead? 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: OrangeFS (was: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs))
On 4/16/20 10:39 AM, Dave Love wrote: > David Schwörer writes: > >> On 4/14/20 11:06 AM, Miro Hrončok wrote: >>> orangefs orphan 1 >>> weeks ago >> >> I took orangefs and rebuild it. >> However I am not able to close or take the FTBFS bug [1] >> The documentation only says I should take the bug, but not how [2] > > Good. I'd fixed it too, but do you know anything about OrangeFS' > status? It seems dead, which is a pity. I mailed a developer some time > ago, who said it wasn't, and someone would get back to me, but I heard > no more. I was going to try Omnibond again. > Upstream said in Februar they where working on a 3.0 release [1]. Not sure where they are working though, because there are no new commits [2]. Omnibond as in omnibond.com? Not sure that helps with orangefs, there link to orangefs is broken, and they only refer to the orangefs.org downloads on orangefs.com ... [1] https://github.com/waltligon/orangefs/issues/78 [2] https://github.com/waltligon/orangefs/commits/master ___ 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: Why does Koschei not run real builds?
On Thu, 16 Apr 2020 at 14:12, Pierre-Yves Chibon wrote: > > On Thu, Apr 16, 2020 at 12:16:16PM +0200, clime wrote: > > On Thu, 16 Apr 2020 at 09:51, Pierre-Yves Chibon > > wrote: > > > > > > On Thu, Apr 16, 2020 at 01:57:40AM +0200, clime wrote: > > > > On Thu, 16 Apr 2020 at 00:52, Dan Čermák > > > > wrote: > > > > > > > > > > clime writes: > > > > > > > > > > > On Mon, 13 Apr 2020 at 10:55, Dan Čermák > > > > > > wrote: > > > > > >> > > > > > >> Hi list, > > > > > >> > > > > > >> my question is pretty much $subject: Why doesn't Koschei kick of > > > > > >> real builds off packages on dependency changes? From my naive POV > > > > > >> that > > > > > >> looks like the missing piece to give us the "OBS-experience". > > > > > >> Having > > > > > >> that at least in Rawhide sounds like a good thing to me. > > > > > > > > > > > > Dan, can I have some basic questions to this because I don't know > > > > > > OBS. > > > > > > > > > > > > Could you describe the feature in more detail with regards to > > > > > > auto-rebuilding and when it is useful? > > > > > > > > > > In a nutshell: OBS will in its default mode rebuild each package once > > > > > one of its direct or indirect dependencies changes. > > > > > > > > > > That is pretty useful, because as a maintainer you can just update a > > > > > library and you don't have to do a thing to get dependent packages > > > > > rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" > > > > > and > > > > > "need a provenpackager to rebuild dependent packages of ABC" emails on > > > > > devel. Also, if a package fails to build due to an update, it will be > > > > > noticed right away and not until the next mass rebuild. > > > > > > > > > > Additionally updating a bunch of packages will no longer require that > > > > > you figure out the build order yourself: the build system figures it > > > > > out > > > > > itself by rebuilding your packages until the transitive dependencies > > > > > stop changing. > > > > > > > > > > All of this is of course only really viable for Rawhide and already > > > > > released Fedora branches should not be run like this, because one > > > > > wrong > > > > > update could wreck the whole distro. > > > > > > > > Thanks, that was a nice explanation. I personally believe there is a > > > > good solution in extending koji and rpm. > > > > > > > > koji to be able to rebuild the same source package again and again > > > > while passing a different increasing number to rpmbuild through > > > > --define and rpm to put that number into rpm name if it was specified > > > > to the following position: > > > > > > > > python3-colcon-ros-bundle-0.0.14-1.fc31..noarch.rpm > > > > > > > > It can be just a short build id specific for the given package (i.e. > > > > how many builds there were for the given package). There might be a > > > > little bit of trouble to keep meaningfully increasing in > > > > case of multiple parallel builds but I think it should be possible. > > > > > > > > An advantage over the rpmautospec approach is that this will just work > > > > for all the packages out of the box, i.e. no matter what macros they > > > > are using. > > > > Pierre, maybe we can start understanding each other here. > > > > > > > > Including the build number in the release field was part of the ideas > > > submitted > > > for feedback when we started looking at the auto-release question and > > > there > > > seemed to be a consensus about not wanting to have the release depend on > > > the > > > build system. > > > > I have a different understanding here :). What you did in rpmautospec > > means that release _is_ dependant on build system because it is > > dependant on information owned by it. > > No, the code generating the release field does not rely on any information > provided by the build system, making it works fine locally. Yet another try: Are you saying this is not true? ... From https://pagure.io/Fedora-Infra/rpmautospec/tree/master: "- Attempt to automatically calculate release numbers and generate an RPM changelog from the dist-git repository of a package and the information available in the Koji build system." and lines like this: https://pagure.io/Fedora-Infra/rpmautospec/blob/3c208f17329940977cbe1552f3d1bbee35014f93/f/rpmautospec/tag_package.py#_53 are not needed? From what I see, you clearly _are_ using build system to generate release information. The fact that you are doing it through some tagging middle step is completely irrelevant cause it is just a middle step. > > > Pierre > ___ > 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 33 System-Wide Change proposal: systemd-resolved
On Mi, 15.04.20 13:27, Daniel J Walsh (dwa...@redhat.com) wrote: > > If a container manager copies in /etc/resolv.conf from the host into > > the container on container *start*, it might be wise to copy in > > /run/systemd/resolve/resolv.conf instead of /etc/resolv.conf, if it > > exists. That file in /run contains the currently up-to-date upstream > > DNS info literally. > > Containers copy the /etc/resolv.conf. /etc/hosts on creation, that way > they can modify it internally, > > It looks like podman will just follow the link. I setup this simple test > > # ls -l /etc/resolv.conf > lrwxrwxrwx. 1 root root 16 Apr 15 13:25 /etc/resolv.conf -> /run/resolv.conf > # cat /etc/resolv.conf > # Generated by NetworkManager > search redhat.com > nameserver 10.5.30.160 > nameserver 10.11.5.19 > nameserver 192.168.1.1 > # podman run fedora cat /etc/resolv.conf > search redhat.com > nameserver 10.5.30.160 > nameserver 10.11.5.19 > nameserver 192.168.1.1 > > So as long as the > > /run/systemd/resolve/resolv.conf > > file is properly formated, our container engines will just work. Yes, /run/systemd/resolve/resolv.conf is properly formatted, the way glibc expects it. It only contains IPv4 + IPv6 "nameserver" stanzas as well as "search" stanzas. The files systemd-resolved generates there look something like this: ``` nameserver 172.31.0.1 nameserver fd00::3a10:d5ff:fe78:6bbe search fritz.box ``` (with some additional explanatory comments at the top, which I stripped here) Key is to access it under its proper path instead of via the symlink, for the aforementioned reasons. Lennart -- Lennart Poettering, Berlin ___ 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 33 System-Wide Change proposal: systemd-resolved
On Mi, 15.04.20 07:10, Pavel Raiskup (prais...@redhat.com) wrote: > On Tuesday, April 14, 2020 9:23:27 PM CEST Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/systemd-resolved > > > > == Summary == > > > > Enable systemd-resolved by default. ... > > We had serious headaches because racy systemd-resolved got enabled for > some unknown reasons on copr builders before (and my host as well, for > example). I filled bug [1] and then I was told that nobody > tests/maintains systemd-resolved... why on earth I'd opt-in to use that. > > Can we fix the bug, so the generated resolv.conf pointing to local server > does work _immediately_ inside mock, and isn't it port-triggered (or what > it is :-))? > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1710699 For the sake of the archives, let's follow-up the discussion on this specific issue on the bug report, instead of the ML. Lennart -- Lennart Poettering, Berlin ___ 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 33 System-Wide Change proposal: systemd-resolved
On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote: > * Lennart Poettering: > > > On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote: > > > >> On Mi, 15.04.20 15:50, Florian Weimer (fwei...@redhat.com) wrote: > >> > >> > * Lennart Poettering: > >> > > >> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it > >> > >for DNS configuration, and never change it or modify it or replace > >> > >it. If this mode is selected arbitrary other programs that do DNS > >> > >will talk directly to the provided DNS servers, and resolved is out > >> > >of the loop. > >> > > >> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts > >> > > itself into DNS resolution in any way. > >> > > >> > What will nss_resolve do in this case? Nothing? > >> > >> The nss_resolve module is just a wrapper around resolved's bus > >> API. And the bus API uses resolved's own DNS resolution code. And > >> resolved is smart enough to automatically become a *consumer* of > >> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular > >> file instead of a symlink to resolved's own files in /run. > > > > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf. > > So if /etc/resolv.conf comes from somewhere else, then nss_resolve will > still forward queries to the daemon, which contacts the upstream server > on nss_resolve's behave (possibly with some caching), and eventually > return the data to the application? nss-resolve is enabled/disabled through nsswitch.conf. It always talks to systemd-resolved using local IPC. It doesn't care about /etc/resolv.conf in any way. What Lennart wrote above applies to systemd-resolved and to things which look at /etc/resolv.conf for some reason. If nss-resolve is enabled, then only things which do not use nss at all would fall into this category. > Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the > data? nss_resolve fails with UNAVAIL when systemd-resolved is not running. So yeah, we use want to use nss_dns as a fallback for that case. I'm not sure if that is what you are asking about. > I'd prefer the first approach, but it really means that resolved is out > of the loop only for queries submitted over the DNS transport (so > res_query and the like, or direct use of UDP & TCP). Hence my > confusion. 8-) 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
Re: Why does Koschei not run real builds?
On Thu, 16 Apr 2020 at 14:12, Pierre-Yves Chibon wrote: > > On Thu, Apr 16, 2020 at 12:16:16PM +0200, clime wrote: > > On Thu, 16 Apr 2020 at 09:51, Pierre-Yves Chibon > > wrote: > > > > > > On Thu, Apr 16, 2020 at 01:57:40AM +0200, clime wrote: > > > > On Thu, 16 Apr 2020 at 00:52, Dan Čermák > > > > wrote: > > > > > > > > > > clime writes: > > > > > > > > > > > On Mon, 13 Apr 2020 at 10:55, Dan Čermák > > > > > > wrote: > > > > > >> > > > > > >> Hi list, > > > > > >> > > > > > >> my question is pretty much $subject: Why doesn't Koschei kick of > > > > > >> real builds off packages on dependency changes? From my naive POV > > > > > >> that > > > > > >> looks like the missing piece to give us the "OBS-experience". > > > > > >> Having > > > > > >> that at least in Rawhide sounds like a good thing to me. > > > > > > > > > > > > Dan, can I have some basic questions to this because I don't know > > > > > > OBS. > > > > > > > > > > > > Could you describe the feature in more detail with regards to > > > > > > auto-rebuilding and when it is useful? > > > > > > > > > > In a nutshell: OBS will in its default mode rebuild each package once > > > > > one of its direct or indirect dependencies changes. > > > > > > > > > > That is pretty useful, because as a maintainer you can just update a > > > > > library and you don't have to do a thing to get dependent packages > > > > > rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" > > > > > and > > > > > "need a provenpackager to rebuild dependent packages of ABC" emails on > > > > > devel. Also, if a package fails to build due to an update, it will be > > > > > noticed right away and not until the next mass rebuild. > > > > > > > > > > Additionally updating a bunch of packages will no longer require that > > > > > you figure out the build order yourself: the build system figures it > > > > > out > > > > > itself by rebuilding your packages until the transitive dependencies > > > > > stop changing. > > > > > > > > > > All of this is of course only really viable for Rawhide and already > > > > > released Fedora branches should not be run like this, because one > > > > > wrong > > > > > update could wreck the whole distro. > > > > > > > > Thanks, that was a nice explanation. I personally believe there is a > > > > good solution in extending koji and rpm. > > > > > > > > koji to be able to rebuild the same source package again and again > > > > while passing a different increasing number to rpmbuild through > > > > --define and rpm to put that number into rpm name if it was specified > > > > to the following position: > > > > > > > > python3-colcon-ros-bundle-0.0.14-1.fc31..noarch.rpm > > > > > > > > It can be just a short build id specific for the given package (i.e. > > > > how many builds there were for the given package). There might be a > > > > little bit of trouble to keep meaningfully increasing in > > > > case of multiple parallel builds but I think it should be possible. > > > > > > > > An advantage over the rpmautospec approach is that this will just work > > > > for all the packages out of the box, i.e. no matter what macros they > > > > are using. > > > > Pierre, maybe we can start understanding each other here. > > > > > > > > Including the build number in the release field was part of the ideas > > > submitted > > > for feedback when we started looking at the auto-release question and > > > there > > > seemed to be a consensus about not wanting to have the release depend on > > > the > > > build system. > > > > I have a different understanding here :). What you did in rpmautospec > > means that release _is_ dependant on build system because it is > > dependant on information owned by it. > > No, the code generating the release field does not rely on any information > provided by the build system, making it works fine locally. Erm, how do you generate the tags? Can you drop the build system relation? You are not making sense at the moment. If your plan is eventually to push those build git tags back to pagure so that people get some kind of temporary reproducibility (i.e. it will work only when no build is running), then that's a duplication of data, i.e. it is still not "dist-git is a single source of truth". You are duplicating what's in koji into dist-git needlessly. And it is _still_dependant on build system. Can you, please, read what I am writing and really think about it? With rpmautospec you are breaking so many software-design and programming common-sense rules that it is hard to even count. Why can't we join forces on a solution that makes sense and that will actually work? clime > > > Pierre > ___ > 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_lis
Re: Why does Koschei not run real builds?
On 4/15/20 5:52 PM, Dan Čermák wrote: That is pretty useful, because as a maintainer you can just update a library and you don't have to do a thing to get dependent packages rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" and "need a provenpackager to rebuild dependent packages of ABC" emails on devel. Also, if a package fails to build due to an update, it will be noticed right away and not until the next mass rebuild. Is it smart enough to only rebuild for SONAME bumps or ABI changes? I wouldn't want rebuilds "just because." ___ 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: Why does Koschei not run real builds?
On Thu, Apr 16, 2020 at 12:16:16PM +0200, clime wrote: > On Thu, 16 Apr 2020 at 09:51, Pierre-Yves Chibon wrote: > > > > On Thu, Apr 16, 2020 at 01:57:40AM +0200, clime wrote: > > > On Thu, 16 Apr 2020 at 00:52, Dan Čermák > > > wrote: > > > > > > > > clime writes: > > > > > > > > > On Mon, 13 Apr 2020 at 10:55, Dan Čermák > > > > > wrote: > > > > >> > > > > >> Hi list, > > > > >> > > > > >> my question is pretty much $subject: Why doesn't Koschei kick of > > > > >> real builds off packages on dependency changes? From my naive POV > > > > >> that > > > > >> looks like the missing piece to give us the "OBS-experience". Having > > > > >> that at least in Rawhide sounds like a good thing to me. > > > > > > > > > > Dan, can I have some basic questions to this because I don't know OBS. > > > > > > > > > > Could you describe the feature in more detail with regards to > > > > > auto-rebuilding and when it is useful? > > > > > > > > In a nutshell: OBS will in its default mode rebuild each package once > > > > one of its direct or indirect dependencies changes. > > > > > > > > That is pretty useful, because as a maintainer you can just update a > > > > library and you don't have to do a thing to get dependent packages > > > > rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" and > > > > "need a provenpackager to rebuild dependent packages of ABC" emails on > > > > devel. Also, if a package fails to build due to an update, it will be > > > > noticed right away and not until the next mass rebuild. > > > > > > > > Additionally updating a bunch of packages will no longer require that > > > > you figure out the build order yourself: the build system figures it out > > > > itself by rebuilding your packages until the transitive dependencies > > > > stop changing. > > > > > > > > All of this is of course only really viable for Rawhide and already > > > > released Fedora branches should not be run like this, because one wrong > > > > update could wreck the whole distro. > > > > > > Thanks, that was a nice explanation. I personally believe there is a > > > good solution in extending koji and rpm. > > > > > > koji to be able to rebuild the same source package again and again > > > while passing a different increasing number to rpmbuild through > > > --define and rpm to put that number into rpm name if it was specified > > > to the following position: > > > > > > python3-colcon-ros-bundle-0.0.14-1.fc31..noarch.rpm > > > > > > It can be just a short build id specific for the given package (i.e. > > > how many builds there were for the given package). There might be a > > > little bit of trouble to keep meaningfully increasing in > > > case of multiple parallel builds but I think it should be possible. > > > > > > An advantage over the rpmautospec approach is that this will just work > > > for all the packages out of the box, i.e. no matter what macros they > > > are using. > > Pierre, maybe we can start understanding each other here. > > > > > Including the build number in the release field was part of the ideas > > submitted > > for feedback when we started looking at the auto-release question and there > > seemed to be a consensus about not wanting to have the release depend on the > > build system. > > I have a different understanding here :). What you did in rpmautospec > means that release _is_ dependant on build system because it is > dependant on information owned by it. No, the code generating the release field does not rely on any information provided by the build system, making it works fine locally. Pierre ___ 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 33 System-Wide Change proposal: systemd-resolved
On 16/04/2020 11:46, Florian Weimer wrote: * Lennart Poettering: Long story short: if you experienced issues with DNSSEC on with resolved today, then be assured that with DNSSEC off things are much much better, and that's how we'd ship it in Fedora if it becomes the default. Would you please clarify what switching DNSSEC off means? Just no validation, or no DNSSEC support at all? If I'm understanding what is expected correctly then it looks to me like it is actually broken regardless of whether or not DNSSEC is switched on... Adding +dnssec to the dig flags results in some additional flags being set in the OPT section of the response but it does not cause RRSIG records to be returned and whether DNSSEC is on or off makes no difference to that. 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: Fedora 33 System-Wide Change proposal: systemd-resolved
* Lennart Poettering: > On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote: > >> On Mi, 15.04.20 15:50, Florian Weimer (fwei...@redhat.com) wrote: >> >> > * Lennart Poettering: >> > >> > > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it >> > >for DNS configuration, and never change it or modify it or replace >> > >it. If this mode is selected arbitrary other programs that do DNS >> > >will talk directly to the provided DNS servers, and resolved is out >> > >of the loop. >> > >> > > In mode #1 resolved neither manages /etc/resolv.conf nor inserts >> > > itself into DNS resolution in any way. >> > >> > What will nss_resolve do in this case? Nothing? >> >> The nss_resolve module is just a wrapper around resolved's bus >> API. And the bus API uses resolved's own DNS resolution code. And >> resolved is smart enough to automatically become a *consumer* of >> /etc/nsswitch.conf (instead of a *manager* of it) if it is a regular >> file instead of a symlink to resolved's own files in /run. > > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf. So if /etc/resolv.conf comes from somewhere else, then nss_resolve will still forward queries to the daemon, which contacts the upstream server on nss_resolve's behave (possibly with some caching), and eventually return the data to the application? Or does nss_resolve fail with UNAVAIL and expects nss_dns to fetch the data? I'd prefer the first approach, but it really means that resolved is out of the loop only for queries submitted over the DNS transport (so res_query and the like, or direct use of UDP & TCP). Hence my confusion. 8-) 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: Fedora 33 System-Wide Change proposal: systemd-resolved
* Michael Catanzaro: > On Wed, Apr 15, 2020 at 10:48 am, Florian Weimer > wrote: >> The second Kubernetes issue I worry about [1] is that the CoreDNS name >> server is installed first, and it does additional rule-based >> processing >> for in-cluster names. External DNS servers are listed later. >> Parallel >> queries and random server selection could bypass the CoreDNS service >> for >> queries that need to be handled by it. > > Hm, CoreDNS might need to construct its own nss module, This is not possible. You cannot realistically inject binary code into the container (see the fun with GPU userspace driver parts). > or you might need to use /etc/resolv.conf in "mode 1" or "mode 3" > described by Lennart. (Or disable systemd-resolved, but that shouldn't > be necessary.) We'll default to Lennart's "mode 2" so it sounds like > that might be a problem indeed. Yeah. >> Does OpenVPN log the list of these domains somewhere? Or do they have >> to be configured manually? > > This managed by NetworkManager and systemd-resolved. You can inspect > with 'resolvectl status'. I don't think OpenVPN knows anything about > it. As explained elsewhere, NetworkManager-openvpn extracts the search list from OpenVPN parameters, passes that to NetworkManager, which I expect will pass ito to systemd-resolved in the future. >> Ugh. That will have to be fixed, otherwise it will break DANE/TLSA >> and >> other DNSSEC-mandatory functionality on upgrades: the system used to >> have a DNSSEC-clean path to the outside world, and after the switch to >> systemd-resolved, it won't. > > I think that, if you need DNSSEC, you will just need to enable it > manually. I think >99% of users won't need to do this, and it's a > one-line config file change for power users who do need it, just edit > /etc/systemd/resolved.conf and then restart systemd-resolved > service. Problem is that DNSSEC is just not safe to enable by > default. :( See my message to Lennart about separate DO/CD query caching. My point is that these users *have* enabled DNSSEC in their infrastructure, and we break what they have during an update (assuming that DNSSEC=off means that systemd-resolved turns DNSSEC-unware, rather than just disabling validation). 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: Fedora 33 System-Wide Change proposal: systemd-resolved
* Lennart Poettering: > Long story short: if you experienced issues with DNSSEC on with > resolved today, then be assured that with DNSSEC off things are much > much better, and that's how we'd ship it in Fedora if it becomes the > default. Would you please clarify what switching DNSSEC off means? Just no validation, or no DNSSEC support at all? I'm worried that the following scenario will break: A Fedora system on a uses a DNSSEC-capable resolver (validating or not) and performs its own DNSSEC validation, using data obtained by contacting the name servers in /etc/resolv.conf. (/etc/resolv.conf is managed by NetworkManager or cloud-init in this scenario.) Since /etc/resolv.conf is already managed, I expect that after the upgrade, systemd-resolved will be active, with the same upstream recursive resolvers as before. The new /etc/resolv.conf contents will point to the local systemd-resolved DNS service, though. If systemd-resolved is not DNSSEC-aware with DNSSEC=off on the DNS interface, this will break DNSSEC validation in the application. It requires an explicit configuration change to fix. In the past, caching resolvers have dealt with this situation by having separate caches for DO (DNSSEC answer OK) or CD (Checking Disabled) queries. This allows non-DNSSEC operations to continue even if the DNSSEC side is broken, so it is safe to enable it by default. It would also ensure that the configuration sketched above would not break (at least not for this reason). 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
Fedora-Cloud-31-20200416.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: Why does Koschei not run real builds?
On Thu, 16 Apr 2020 at 09:51, Pierre-Yves Chibon wrote: > > On Thu, Apr 16, 2020 at 01:57:40AM +0200, clime wrote: > > On Thu, 16 Apr 2020 at 00:52, Dan Čermák > > wrote: > > > > > > clime writes: > > > > > > > On Mon, 13 Apr 2020 at 10:55, Dan Čermák > > > > wrote: > > > >> > > > >> Hi list, > > > >> > > > >> my question is pretty much $subject: Why doesn't Koschei kick of > > > >> real builds off packages on dependency changes? From my naive POV that > > > >> looks like the missing piece to give us the "OBS-experience". Having > > > >> that at least in Rawhide sounds like a good thing to me. > > > > > > > > Dan, can I have some basic questions to this because I don't know OBS. > > > > > > > > Could you describe the feature in more detail with regards to > > > > auto-rebuilding and when it is useful? > > > > > > In a nutshell: OBS will in its default mode rebuild each package once > > > one of its direct or indirect dependencies changes. > > > > > > That is pretty useful, because as a maintainer you can just update a > > > library and you don't have to do a thing to get dependent packages > > > rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" and > > > "need a provenpackager to rebuild dependent packages of ABC" emails on > > > devel. Also, if a package fails to build due to an update, it will be > > > noticed right away and not until the next mass rebuild. > > > > > > Additionally updating a bunch of packages will no longer require that > > > you figure out the build order yourself: the build system figures it out > > > itself by rebuilding your packages until the transitive dependencies > > > stop changing. > > > > > > All of this is of course only really viable for Rawhide and already > > > released Fedora branches should not be run like this, because one wrong > > > update could wreck the whole distro. > > > > Thanks, that was a nice explanation. I personally believe there is a > > good solution in extending koji and rpm. > > > > koji to be able to rebuild the same source package again and again > > while passing a different increasing number to rpmbuild through > > --define and rpm to put that number into rpm name if it was specified > > to the following position: > > > > python3-colcon-ros-bundle-0.0.14-1.fc31..noarch.rpm > > > > It can be just a short build id specific for the given package (i.e. > > how many builds there were for the given package). There might be a > > little bit of trouble to keep meaningfully increasing in > > case of multiple parallel builds but I think it should be possible. > > > > An advantage over the rpmautospec approach is that this will just work > > for all the packages out of the box, i.e. no matter what macros they > > are using. Pierre, maybe we can start understanding each other here. > > Including the build number in the release field was part of the ideas > submitted > for feedback when we started looking at the auto-release question and there > seemed to be a consensus about not wanting to have the release depend on the > build system. I have a different understanding here :). What you did in rpmautospec means that release _is_ dependant on build system because it is dependant on information owned by it. You can have two slightly different ways to implement the dependency, one is externally using public api so that build system doesn't know what is happening. The second is to incorporate build system into the solution and let it generate the field or its part. But in both these implementations, the release field is dependent on build system because if there is no build system, there is no valid release and because you rely on how certain switches (electrons) move in build system's db. Imho, people asked you to implement a solution where the information for Release field is drawn purely from git (dist-git), i.e. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QHZHOOXGR6REIV4HK4BKKNNWVIY6POYE/ to cite the first response. That's when dist-git becomes "single source of truth" for the release field. It is also how things are today. ...So I thought you just eventually ignored the people and ignored the consensus because you eventually pulled the build information in. > > rpmautospec allows to rebuild a commit multiple times and you will get a > different release everytime, that release is computed using the information > from > the build history of the package, made available via git tags, so the build > system is not involved in the computing of the release field (which thus can > be > reproduced locally). Build system _is_ involved in computing the release field because you are querying its API. And therefore the results _cannot_ be reproduced locally because, imho, a solution where you need to query some central service through network does not have "locally-reproducible" property. Or if you avoid that by returning always 1 as a result, that also means the solution does not have "local-re
Re: Announcing new anitya integration and de-orphaning process
On 26. 11. 19 13:13, Pierre-Yves Chibon wrote: * Anitya integration in dist-git Something we lost when loosing pkgdb was the easy integration to anitya (https://release-monitoring.org). With the coming changes we are getting them back. On the left hand-side column, there will be a drop-down button allowing to change the settings for anitya for the project. Existing status will be migrated from the fedora-scm-requests repo on pagure to use this drop-down. Using the fedora-scm-requests repo for the anitya integration will no longer be supported. I have updated https://fedoraproject.org/wiki/Upstream_release_monitoring to reflect this, it still had the old workflow documented. I'd appreciate if somebody can go trough the page and verify it makes sense now. -- 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
OrangeFS (was: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs))
David Schwörer writes: > On 4/14/20 11:06 AM, Miro Hrončok wrote: >> orangefs orphan 1 >> weeks ago > > I took orangefs and rebuild it. > However I am not able to close or take the FTBFS bug [1] > The documentation only says I should take the bug, but not how [2] Good. I'd fixed it too, but do you know anything about OrangeFS' status? It seems dead, which is a pity. I mailed a developer some time ago, who said it wasn't, and someone would get back to me, but I heard no more. I was going to try Omnibond again. ___ 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-Cloud-30-20200416.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: Why does Koschei not run real builds?
On Thu, Apr 16, 2020 at 01:57:40AM +0200, clime wrote: > On Thu, 16 Apr 2020 at 00:52, Dan Čermák > wrote: > > > > clime writes: > > > > > On Mon, 13 Apr 2020 at 10:55, Dan Čermák > > > wrote: > > >> > > >> Hi list, > > >> > > >> my question is pretty much $subject: Why doesn't Koschei kick of > > >> real builds off packages on dependency changes? From my naive POV that > > >> looks like the missing piece to give us the "OBS-experience". Having > > >> that at least in Rawhide sounds like a good thing to me. > > > > > > Dan, can I have some basic questions to this because I don't know OBS. > > > > > > Could you describe the feature in more detail with regards to > > > auto-rebuilding and when it is useful? > > > > In a nutshell: OBS will in its default mode rebuild each package once > > one of its direct or indirect dependencies changes. > > > > That is pretty useful, because as a maintainer you can just update a > > library and you don't have to do a thing to get dependent packages > > rebuilt. So no more "unannounced SONAME bump", "please rebuild XYZ" and > > "need a provenpackager to rebuild dependent packages of ABC" emails on > > devel. Also, if a package fails to build due to an update, it will be > > noticed right away and not until the next mass rebuild. > > > > Additionally updating a bunch of packages will no longer require that > > you figure out the build order yourself: the build system figures it out > > itself by rebuilding your packages until the transitive dependencies > > stop changing. > > > > All of this is of course only really viable for Rawhide and already > > released Fedora branches should not be run like this, because one wrong > > update could wreck the whole distro. > > Thanks, that was a nice explanation. I personally believe there is a > good solution in extending koji and rpm. > > koji to be able to rebuild the same source package again and again > while passing a different increasing number to rpmbuild through > --define and rpm to put that number into rpm name if it was specified > to the following position: > > python3-colcon-ros-bundle-0.0.14-1.fc31..noarch.rpm > > It can be just a short build id specific for the given package (i.e. > how many builds there were for the given package). There might be a > little bit of trouble to keep meaningfully increasing in > case of multiple parallel builds but I think it should be possible. > > An advantage over the rpmautospec approach is that this will just work > for all the packages out of the box, i.e. no matter what macros they > are using. Including the build number in the release field was part of the ideas submitted for feedback when we started looking at the auto-release question and there seemed to be a consensus about not wanting to have the release depend on the build system. rpmautospec allows to rebuild a commit multiple times and you will get a different release everytime, that release is computed using the information from the build history of the package, made available via git tags, so the build system is not involved in the computing of the release field (which thus can be reproduced locally). Pierre ___ 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: Is there a way to mockbuild systemd?
On Mon, Apr 06, 2020 at 09:50:26PM +0200, Göran Uddeborg wrote: > I asked this in ask.fedoraproject > (https://ask.fedoraproject.org/t/is-there-a-way-to-mockbuild-systemd), > but FranciscoD suggested this might be a better place. > > I'm trying to build a slightly modified version of systemd. To start > with, I tried to do a fedpkg mockbuild of systemd without any > modification. The build fails on the test-mountpoint-util test. That's https://bugzilla.redhat.com/show_bug.cgi?id=1803070. It's some issue with name_to_handle_at() workaround for older kernels which don't have it. I never had the time to get to the bottom of this. Some ways to avoid the issue: use a newer kernel, ignore tests with --without tests, or use non-nspawn build as you described. 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
