Re: F30 Self-Contained Change proposal: Bash 5.0
On Mon, Feb 11, 2019 at 3:30 AM Neal Gompa wrote: > > On Sun, Feb 10, 2019 at 9:22 PM Dridi Boukelmoune > wrote: > > > > > I don't read repodata manually, libsolv does it for me. Using libdnf > > > and/or libmodulemd is not something what (for example) OBS would do. They > > > rely on libsolv for all dependency solving operations. And unless it will > > > support modularity (which depends heavily on DNF people's ability to > > > speak to upstream), nothing will improve. > > > > I don't know how things are currently done, but shouldn't modularity > > build on top instead of being bolted in? > > > > "Build on top" does not make sense, because each of the aspects are > crossing into each other in order to provide a useful solution. Yes but dnf provides an API and you can build features on top of it. For example version locks (that could help enforce a stream) protected packages (that could intercept attempts to remove a module outside TheRightWay(tm)) etc. I don't see why we should mess with the RPM dependency solver in an intrusive way and not feed it the result of "module" dependency solving. In other words, I don't understand why we need to special case modules in build roots. > > I assume libsolv can already deal with multiple repodata since yum/dnf > > support having multiple repositories. Shouldn't modules simply provide > > repodata and have the "modularity" plugin figure which repodata to > > fetch depending on the selected streams? That wouldn't require any > > change in libsolv. > > > > This is actually how it works now, but causes all kinds of problems, > even in DNF itself. If you try to get debugsolver data for debugging > issues with DNF, it makes absolutely no sense because the solver > doesn't know anything about RH modularity. This means that solutions > are slower and suboptimal. It also makes development on improving the > technology very hard. It also increases the memory requirements > because everything has to be held in memory while a second solver runs > on the data to apply various filters. And the solution "logic" for > modules is very similar to how yum did solutions for RPMs, so it's > quite slow and prone to issues. I never had the bandwidth to follow modularity in the making, so I'm still very clueless about the implementation. But the fact that I have a fairly good understanding of the "installation process" (in a broad sense) in Fedora and can't grok modularity feels like something was wrong in the base design. > > Disclaimer, I don't know any better but if modules are simply > > parallel-available RPMs, it shouldn't be bothering libsolv (except > > maybe to enforce a stream downgrade). > > > > Modules are effectively mutually conflicting collections of RPMs, > operating like stacked/nested repos with the properties of composition > groups. They also contain all kinds of extra information which is used > to determine availability, usability, and other things. > > If they worked the way you thought they did, we wouldn't be having > these issues. :( To me it feels like Red Hat had an agenda and a time table, and the whole thing was rushed for the sake of RHEL 8's time to market. When people blame Red Hat of using Fedora as a test bed, I can only sympathize because it really feels like that. I don't mind, but when the answer is no, Fedora is an independent community project, I also don't buy it. I really think that the current design shortcomings come from the lack of time allocated to it, or maybe the lack of exposure. Again I don't have the bandwidth to follow major changes in Fedora, for example it took me forever to even start dropping the python2 packages I happen to maintain. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, Feb 10, 2019 at 9:22 PM Dridi Boukelmoune wrote: > > > I don't read repodata manually, libsolv does it for me. Using libdnf and/or > > libmodulemd is not something what (for example) OBS would do. They rely on > > libsolv for all dependency solving operations. And unless it will support > > modularity (which depends heavily on DNF people's ability to speak to > > upstream), nothing will improve. > > I don't know how things are currently done, but shouldn't modularity > build on top instead of being bolted in? > "Build on top" does not make sense, because each of the aspects are crossing into each other in order to provide a useful solution. > I assume libsolv can already deal with multiple repodata since yum/dnf > support having multiple repositories. Shouldn't modules simply provide > repodata and have the "modularity" plugin figure which repodata to > fetch depending on the selected streams? That wouldn't require any > change in libsolv. > This is actually how it works now, but causes all kinds of problems, even in DNF itself. If you try to get debugsolver data for debugging issues with DNF, it makes absolutely no sense because the solver doesn't know anything about RH modularity. This means that solutions are slower and suboptimal. It also makes development on improving the technology very hard. It also increases the memory requirements because everything has to be held in memory while a second solver runs on the data to apply various filters. And the solution "logic" for modules is very similar to how yum did solutions for RPMs, so it's quite slow and prone to issues. > Disclaimer, I don't know any better but if modules are simply > parallel-available RPMs, it shouldn't be bothering libsolv (except > maybe to enforce a stream downgrade). > Modules are effectively mutually conflicting collections of RPMs, operating like stacked/nested repos with the properties of composition groups. They also contain all kinds of extra information which is used to determine availability, usability, and other things. If they worked the way you thought they did, we wouldn't be having these issues. :( -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On to, 07 helmi 2019, Jerry James wrote: On Thu, Feb 7, 2019 at 2:13 AM Adam Samalik wrote: 2) Fedora infra builds of standalone packages — modular content is currently invisible to standalone package builds. That said, the Modularity Team is actively working on making that possible. You might have heard about "Ursa Major" which is a funny name for a solution that injects default module streams into the traditional buildroot. Alternatives have been also discussed in the past few weeks. But please understand this the reason it doesn't work at this moment is not the design, but rather the work still being in progress. And before that's done, we do not allow packages used as build dependencies to be completely moved to a default module before we fix this — so nothing should break for you. A couple of days ago, Mikolaj Izdebski announced on this mailing list, in a thread entitled "Orphaned some Java packages" that 259 packages are being converted into modules. So none of those are used as build dependencies? I can tell you for sure that one of them SHOULD be used as a build dependency: https://bugzilla.redhat.com/show_bug.cgi?id=1599015 What should happen is that coq has antlr4 as a build dependency, uses it to generate some python code, then depends on the antlr4 python3 runtime. Since that isn't possible at the moment, I've been forced into the stupid, wrong workaround of (a) using upstream's generated python code, since our antlr4 package is incapable of regenerating it, and (b) bundling the antlr4 python3 runtime with coq, since it is not available from Fedora in any package. Now what is going to happen? If antlr4 becomes a module, how will this situation be resolved? Coq might become a module stream itself, with its modular content being exposed through a default profile that is available without explicit enabling of a coq module to any (non-buildroot) use of Fedora packages. It is another option, not worse than others. For my experience with modules... We didn't go with modules for FreeIPA in Fedora yet but I spent last year doing modularization of RHEL IdM. My worries were basically on having a lot of overhead for maintaining packages. They did not really came through: apart from a need to coordinate rebuilds, modular RHEL IdM is actually helping us to be more clear with the dependencies and their use. In Fedora the use for our dependencies is wider than in RHEL, so the same benefits might not be so apparent. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Thu, Feb 7, 2019 at 2:13 AM Adam Samalik wrote: > 2) Fedora infra builds of standalone packages — modular content is currently > invisible to standalone package builds. That said, the Modularity Team is > actively working on making that possible. You might have heard about "Ursa > Major" which is a funny name for a solution that injects default module > streams into the traditional buildroot. Alternatives have been also discussed > in the past few weeks. But please understand this the reason it doesn't work > at this moment is not the design, but rather the work still being in > progress. And before that's done, we do not allow packages used as build > dependencies to be completely moved to a default module before we fix this — > so nothing should break for you. A couple of days ago, Mikolaj Izdebski announced on this mailing list, in a thread entitled "Orphaned some Java packages" that 259 packages are being converted into modules. So none of those are used as build dependencies? I can tell you for sure that one of them SHOULD be used as a build dependency: https://bugzilla.redhat.com/show_bug.cgi?id=1599015 What should happen is that coq has antlr4 as a build dependency, uses it to generate some python code, then depends on the antlr4 python3 runtime. Since that isn't possible at the moment, I've been forced into the stupid, wrong workaround of (a) using upstream's generated python code, since our antlr4 package is incapable of regenerating it, and (b) bundling the antlr4 python3 runtime with coq, since it is not available from Fedora in any package. Now what is going to happen? If antlr4 becomes a module, how will this situation be resolved? I am very concerned that the coq situation is going from bad to worse. Give me some hope. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
> I don't read repodata manually, libsolv does it for me. Using libdnf and/or > libmodulemd is not something what (for example) OBS would do. They rely on > libsolv for all dependency solving operations. And unless it will support > modularity (which depends heavily on DNF people's ability to speak to > upstream), nothing will improve. I don't know how things are currently done, but shouldn't modularity build on top instead of being bolted in? I assume libsolv can already deal with multiple repodata since yum/dnf support having multiple repositories. Shouldn't modules simply provide repodata and have the "modularity" plugin figure which repodata to fetch depending on the selected streams? That wouldn't require any change in libsolv. Disclaimer, I don't know any better but if modules are simply parallel-available RPMs, it shouldn't be bothering libsolv (except maybe to enforce a stream downgrade). Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
I can't speak on behalf of Neal, but I think I will try to answer. On Thu, Feb 7, 2019, 10:21 Adam Samalik > > On Thu, Jan 31, 2019 at 6:19 PM Neal Gompa wrote: > >> On Thu, Jan 31, 2019 at 6:07 AM Matthew Miller >> wrote: >> > >> > On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote: >> > > Please don't do that. You'll basically break the distribution for all >> > > third-party packagers. Modules are not supported by anyone at all, and >> > > it's too difficult to integrate as it currently stands (and I'm >> > > actually trying because of the impending doom that is RHEL 8). >> > >> > Can you elaborate? How would this break third-party packagers? >> > >> >> I've mentioned this before in other places, but the Fedora Modularity >> initiative, as currently designed and implemented, is functionally >> impossible for me as a third-party packager to use. As stuff moves from the >> regular repository to the modular repo, I lose access to that content for >> dependencies. This affects my ability to ship software for Fedora as part >> of the work I do for my day job. And once the distribution starts requiring >> modules to function or to access entire ecosystems (like Java), I'm SOL. >> > > I'm not quite sure I'm following right, but let me try. How are you > loosing content? > It moves to different repo where you can't rely on normal behavior of dependency solving between RPMs (unless you have support for modularity in your tooling). During runtime, DNF picks up content (meaning RPM packages) regardless them > being in a default module or standalone. For example, "dnf install dwm" > works the same way on f28 where dwm is a standalone package, and f29 where > dwm is in a default module. > I think the main problem here is that you always say "dnf", "Koji". Other distributions (let's take openSUSE) have their buildsystems and tooling which doesn't use neither dnf or Koji. > During build, it's a bit more complex because you can build standalone > packages or modules, and you can do local builds or builds in the Fedora > infra — that's four different scenarios in total: > > 1) Local builds of standalone packages — just adding the modular repo into > your mock config makes DNF to pick up packages for the buildroot the same > way as described above, it doesn't really matter if they are in a default > module or standalone. This is, however, not enabled by default to be > consistent with 2). > But not any other package manager / dependency solver. 2) Fedora infra builds of standalone packages — modular content is > currently invisible to standalone package builds. That said, the Modularity > Team is actively working on making that possible. You might have heard > about "Ursa Major" which is a funny name for a solution that injects > default module streams into the traditional buildroot. Alternatives have > been also discussed in the past few weeks. But please understand this the > reason it doesn't work at this moment is not the design, but rather the > work still being in progress. And before that's done, we do not allow > packages used as build dependencies to be completely moved to a default > module before we fix this — so nothing should break for you. > Which is Koji-specific and is not integrated in any other buildsystem. 3) Local module builds — I'll just point you to the docs [1] here. Although > the current experience is not ideal, it's functional and remains on the > Modularity Team's list of things to tackle. We'd appreciate your input if > you're interested in building modules locally. > > 4) Fedora infra builds of modules — I'll point you to the docs [2] again. > There should be no issues with module builds in the infra. > If your module contains some number of build levels (buildorder), then you'd need to wait at least few hours. Did you try to build such modules? (I did) So... I'm not sure how are you loosing content right now, you shouldn't be. > Do you have an example? > > [1] > https://docs.fedoraproject.org/en-US/modularity/making-modules/building-modules-locally/ > [2] > https://docs.fedoraproject.org/en-US/modularity/making-modules/building-modules/ > > >> >> I was horrified when I found out that RHEL 8 was "modularized" in this >> manner, because I can't construct a build environment for it right now. >> There was no thought into the broader ecosystem, or even solving the >> problem in a reasonably compatible manner. >> > > Did you hear about the CodeReady Linux Builder [3] repository? > > Regarding the broader ecosystem and the amount of thoughts that went to > it, and I'm just speculating now, if Modularity ever gets to EPEL, wouldn't > modules actually make it easier to build content for RHEL 8? You could in > theory even build alternative versions of packages that replace RHEL > content thanks to non-default modules. I feel like that would be a huge > benefit. > That would be, for some parts. But you still can't build your own RPM/DNF stack and use new features of this stack
Re: F30 Self-Contained Change proposal: Bash 5.0
On Thu, Jan 31, 2019 at 6:19 PM Neal Gompa wrote: > On Thu, Jan 31, 2019 at 6:07 AM Matthew Miller > wrote: > > > > On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote: > > > Please don't do that. You'll basically break the distribution for all > > > third-party packagers. Modules are not supported by anyone at all, and > > > it's too difficult to integrate as it currently stands (and I'm > > > actually trying because of the impending doom that is RHEL 8). > > > > Can you elaborate? How would this break third-party packagers? > > > > I've mentioned this before in other places, but the Fedora Modularity > initiative, as currently designed and implemented, is functionally > impossible for me as a third-party packager to use. As stuff moves from the > regular repository to the modular repo, I lose access to that content for > dependencies. This affects my ability to ship software for Fedora as part > of the work I do for my day job. And once the distribution starts requiring > modules to function or to access entire ecosystems (like Java), I'm SOL. > I'm not quite sure I'm following right, but let me try. How are you loosing content? During runtime, DNF picks up content (meaning RPM packages) regardless them being in a default module or standalone. For example, "dnf install dwm" works the same way on f28 where dwm is a standalone package, and f29 where dwm is in a default module. During build, it's a bit more complex because you can build standalone packages or modules, and you can do local builds or builds in the Fedora infra — that's four different scenarios in total: 1) Local builds of standalone packages — just adding the modular repo into your mock config makes DNF to pick up packages for the buildroot the same way as described above, it doesn't really matter if they are in a default module or standalone. This is, however, not enabled by default to be consistent with 2). 2) Fedora infra builds of standalone packages — modular content is currently invisible to standalone package builds. That said, the Modularity Team is actively working on making that possible. You might have heard about "Ursa Major" which is a funny name for a solution that injects default module streams into the traditional buildroot. Alternatives have been also discussed in the past few weeks. But please understand this the reason it doesn't work at this moment is not the design, but rather the work still being in progress. And before that's done, we do not allow packages used as build dependencies to be completely moved to a default module before we fix this — so nothing should break for you. 3) Local module builds — I'll just point you to the docs [1] here. Although the current experience is not ideal, it's functional and remains on the Modularity Team's list of things to tackle. We'd appreciate your input if you're interested in building modules locally. 4) Fedora infra builds of modules — I'll point you to the docs [2] again. There should be no issues with module builds in the infra. So... I'm not sure how are you loosing content right now, you shouldn't be. Do you have an example? [1] https://docs.fedoraproject.org/en-US/modularity/making-modules/building-modules-locally/ [2] https://docs.fedoraproject.org/en-US/modularity/making-modules/building-modules/ > > I was horrified when I found out that RHEL 8 was "modularized" in this > manner, because I can't construct a build environment for it right now. > There was no thought into the broader ecosystem, or even solving the > problem in a reasonably compatible manner. > Did you hear about the CodeReady Linux Builder [3] repository? Regarding the broader ecosystem and the amount of thoughts that went to it, and I'm just speculating now, if Modularity ever gets to EPEL, wouldn't modules actually make it easier to build content for RHEL 8? You could in theory even build alternative versions of packages that replace RHEL content thanks to non-default modules. I feel like that would be a huge benefit. [3] https://developers.redhat.com/blog/2018/11/15/introducing-codeready-linux-builder/ > A lot of my tools just flat out break because the assumption that rpm-md > is always XML was broken by modulemd for repodata being YAML instead of > XML. My ability to hack together even a jerry-rigged solution has been > hampered by the fact that I can't even access all the different options > easily either. The repository looks like nonsense and everything is > basically broken to conventional tools because of the massive collection of > conflicting sets of packages with odd NVRs that make version comparisons > behave oddly. > All right, "looks like nonsense" and "everything is basically broken" mean nothing specific to me, and it's hard to help you here even when I really want to. But it sounds like you're reading the repodata manually — wouldn't using DNF / libdnf / libmodulemd help? Or are you writing your own tools? > > > -- > 真実はいつも一つ！/ Always, there's only one truth!
Re: F30 Self-Contained Change proposal: Bash 5.0
On Thu, Jan 31, 2019 at 6:07 AM Matthew Miller wrote: > > On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote: > > Please don't do that. You'll basically break the distribution for all > > third-party packagers. Modules are not supported by anyone at all, and > > it's too difficult to integrate as it currently stands (and I'm > > actually trying because of the impending doom that is RHEL 8). > > Can you elaborate? How would this break third-party packagers? > I've mentioned this before in other places, but the Fedora Modularity initiative, as currently designed and implemented, is functionally impossible for me as a third-party packager to use. As stuff moves from the regular repository to the modular repo, I lose access to that content for dependencies. This affects my ability to ship software for Fedora as part of the work I do for my day job. And once the distribution starts requiring modules to function or to access entire ecosystems (like Java), I'm SOL. I was horrified when I found out that RHEL 8 was "modularized" in this manner, because I can't construct a build environment for it right now. There was no thought into the broader ecosystem, or even solving the problem in a reasonably compatible manner. A lot of my tools just flat out break because the assumption that rpm-md is always XML was broken by modulemd for repodata being YAML instead of XML. My ability to hack together even a jerry-rigged solution has been hampered by the fact that I can't even access all the different options easily either. The repository looks like nonsense and everything is basically broken to conventional tools because of the massive collection of conflicting sets of packages with odd NVRs that make version comparisons behave oddly. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Thu, Jan 31, 2019 at 4:23 AM Matthew Miller wrote: > > On Tue, Jan 29, 2019 at 03:01:55PM +0100, Igor Gnatenko wrote: > > > But wait also: can't the module just refer to the release-branch (base) > > > dist-git? Why maintain two copies? > > Well, they can. But someone needs to build it twice: once using fedpkg > > build and once using fedpkg module-build from the different repo > > (which always requires at least empty commit). > > That's kind of annoying. Can we use Freshmaker or similar to auto-build the > module? > We have stuff like that? I don't think we do. Automation for making release package builds seems to scare people here. :/ > > > [2] hey, what happened to sgallagh's "hybrid" proposal where output from > > > modules could just be *tagged into* base? That seemed perfect for > > > cases > > > like this. > > Well, it is called UM which is stuck in the FESCo loop. > > That seems significantly more complicated to me. Ursa Major is about adding > modules to the buildroot; the "hybrid" idea was that the modular package > builds could also be tagged as "regular" builds and land in the non-modular > repo. > This proposal is completely new to me. I've never heard *anyone* talking about that. If we did that, I'd be considerably happier, since it won't break the world, and packages that we build with module tooling don't need to require modularity enablement at runtime. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Tue, Jan 29, 2019 at 11:06:25PM -0500, Neal Gompa wrote: > Please don't do that. You'll basically break the distribution for all > third-party packagers. Modules are not supported by anyone at all, and > it's too difficult to integrate as it currently stands (and I'm > actually trying because of the impending doom that is RHEL 8). Can you elaborate? How would this break third-party packagers? -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Tue, Jan 29, 2019 at 03:01:55PM +0100, Igor Gnatenko wrote: > > But wait also: can't the module just refer to the release-branch (base) > > dist-git? Why maintain two copies? > Well, they can. But someone needs to build it twice: once using fedpkg > build and once using fedpkg module-build from the different repo > (which always requires at least empty commit). That's kind of annoying. Can we use Freshmaker or similar to auto-build the module? > > [2] hey, what happened to sgallagh's "hybrid" proposal where output from > > modules could just be *tagged into* base? That seemed perfect for cases > > like this. > Well, it is called UM which is stuck in the FESCo loop. That seems significantly more complicated to me. Ursa Major is about adding modules to the buildroot; the "hybrid" idea was that the modular package builds could also be tagged as "regular" builds and land in the non-modular repo. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Wed, 2019-01-30 at 10:32 +0100, Adam Williamson wrote: > > and the results show up in Bodhi (albeit under the heading > 'undefined', which is a bug we should fix): > https://bodhi.fedoraproject.org/updates/FEDORA-2019-9d006f6254 (see > Automated Tests tab) https://github.com/fedora-infra/bodhi/pull/2969 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
- Original Message - > From: "Adam Williamson" > To: "Development discussions related to Fedora" > , "Neal Gompa" > Cc: "Stef Walter" , svashi...@redhat.com > Sent: Wednesday, January 30, 2019 10:32:32 AM > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > So for the record, I looked into this a bit further, and in fact it has > already been done. There are tests in bash dist-git: > > https://src.fedoraproject.org/rpms/bash/blob/master/f/tests > > and they are actually being run by the pipeline: > > https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-f29-build-pipeline/detail/fedora-f29-build-pipeline/282/pipeline > > and the results show up in Bodhi (albeit under the heading > 'undefined', which is a bug we should fix): > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-9d006f6254 (see > Automated Tests tab) > > which means Greenwave knows about them, because Bodhi now uses > Greenwave as its source of result data (so anything that shows up in > Bodhi is definitely in Greenwave). > > I don't know if the tests that have been imported into dist-git are > *all* of RH's internal tests - Sitesh might know. But certainly some or > all of them have been upstreamed, and are properly set up such that > they will run on any builds done in Fedora and will be available for > the Rawhide gating stuff once that's fully implemented. Currently there are just 3 tests that have been upstreamed from our internal repos[1]. I wanted to get all of them upstreamed in fedora, but it can't be done due to other priorities. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > [1] https://src.fedoraproject.org/tests/shell/tree/master -- -- Siteshwar Vashisht ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Mon, 2019-01-28 at 08:56 +0100, Adam Williamson wrote: > > > Have you run these tests on bash 5.0 rebase yet? Also, would it be > > possible to get this into Fedora Dist-Git so that the checks could be > > run as part of any build/update/PR to the package? > > Great point, Neal - that would indeed be super helpful, if it's > possible. Siteshwar, in case you haven't seen it, > https://fedoraproject.org/wiki/CI/Quick_Start_Guide is the quick start > version of how to do this, and the longer write-ups are in: > > https://fedoraproject.org/wiki/CI/Tests > https://fedoraproject.org/wiki/CI/Share_Test_Code > https://fedoraproject.org/wiki/CI/Pull_Requests > https://fedoraproject.org/wiki/CI/Examples > > the higher-level https://fedoraproject.org/wiki/CI page has an overview > of the whole system, and other useful links. So for the record, I looked into this a bit further, and in fact it has already been done. There are tests in bash dist-git: https://src.fedoraproject.org/rpms/bash/blob/master/f/tests and they are actually being run by the pipeline: https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-f29-build-pipeline/detail/fedora-f29-build-pipeline/282/pipeline and the results show up in Bodhi (albeit under the heading 'undefined', which is a bug we should fix): https://bodhi.fedoraproject.org/updates/FEDORA-2019-9d006f6254 (see Automated Tests tab) which means Greenwave knows about them, because Bodhi now uses Greenwave as its source of result data (so anything that shows up in Bodhi is definitely in Greenwave). I don't know if the tests that have been imported into dist-git are *all* of RH's internal tests - Sitesh might know. But certainly some or all of them have been upstreamed, and are properly set up such that they will run on any builds done in Fedora and will be available for the Rawhide gating stuff once that's fully implemented. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Tue, Jan 29, 2019 at 11:05 PM Matthew Miller wrote: > > On Tue, Jan 29, 2019 at 02:43:39AM -0500, Siteshwar Vashisht wrote: > > I agree that it would be much safer to target it for Fedora 31. I have no > > objection if we change target release. > > What about building it as a module, with Bash 4 as the default stream for > F30 and a plan to switch that to 5 for F31? > Please don't do that. You'll basically break the distribution for all third-party packagers. Modules are not supported by anyone at all, and it's too difficult to integrate as it currently stands (and I'm actually trying because of the impending doom that is RHEL 8). -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Tue, Jan 29, 2019 at 2:59 PM Matthew Miller wrote: > > On Tue, Jan 29, 2019 at 01:28:06PM +0100, Igor Gnatenko wrote: > > That doesn't help until there is Ursa Major or some alternative deployed. > > > > The reason for that is that we would need to maintain 2 copies of > > bash, one for users and one for buildroot. I do that for libgit2 and > > it is painful. > > Okay, yeah. But modules can override base, right? So what if 4 is left as > the default in F30 and a module for 5 added, and then in F31 hopefully there > will be ursa major¹ in place. Only on the user' systems, not in the buildroot. At least at this moment. > But wait also: can't the module just refer to the release-branch (base) > dist-git? Why maintain two copies? Well, they can. But someone needs to build it twice: once using fedpkg build and once using fedpkg module-build from the different repo (which always requires at least empty commit). > > [1] a funny name for "allowing modules in buildroot"² > > [2] hey, what happened to sgallagh's "hybrid" proposal where output from > modules could just be *tagged into* base? That seemed perfect for cases > like this. Well, it is called UM which is stuck in the FESCo loop. > -- > 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://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Tue, Jan 29, 2019 at 01:28:06PM +0100, Igor Gnatenko wrote: > That doesn't help until there is Ursa Major or some alternative deployed. > > The reason for that is that we would need to maintain 2 copies of > bash, one for users and one for buildroot. I do that for libgit2 and > it is painful. Okay, yeah. But modules can override base, right? So what if 4 is left as the default in F30 and a module for 5 added, and then in F31 hopefully there will be ursa major¹ in place. But wait also: can't the module just refer to the release-branch (base) dist-git? Why maintain two copies? [1] a funny name for "allowing modules in buildroot"² [2] hey, what happened to sgallagh's "hybrid" proposal where output from modules could just be *tagged into* base? That seemed perfect for cases like this. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
That doesn't help until there is Ursa Major or some alternative deployed. The reason for that is that we would need to maintain 2 copies of bash, one for users and one for buildroot. I do that for libgit2 and it is painful. On Tue, Jan 29, 2019 at 11:53 AM Matthew Miller wrote: > > On Tue, Jan 29, 2019 at 02:43:39AM -0500, Siteshwar Vashisht wrote: > > I agree that it would be much safer to target it for Fedora 31. I have no > > objection if we change target release. > > What about building it as a module, with Bash 4 as the default stream for > F30 and a plan to switch that to 5 for F31? > > > -- > 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://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Tue, Jan 29, 2019 at 02:43:39AM -0500, Siteshwar Vashisht wrote: > I agree that it would be much safer to target it for Fedora 31. I have no > objection if we change target release. What about building it as a module, with Bash 4 as the default stream for F30 and a plan to switch that to 5 for F31? -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
- Original Message - > From: "Adam Williamson" > To: "Development discussions related to Fedora" > > Sent: Monday, January 28, 2019 11:38:58 PM > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > It's not the "only" issue, because it was submitted over two weeks > *after* the deadline for system-wide changes. > > I am somewhat concerned about dropping in a major new bash version > quite late in the cycle and just before the mass rebuild, particularly > when there are bits like this in the announcement: > > "There are a number of changes to the > expansion of $@ and $* in various contexts where word splitting is not > performed to conform to a Posix standard interpretation, and additional > changes to resolve corner cases for Posix conformance." (are you *sure* > all our corner cases are expecting Posix-conformant behaviour? I'm not) > > "The `globasciiranges' shell option > is now enabled by default; it can be set to off by default at > configuration time." (OK, so we can turn it off again if necessary, but > still, could be interesting) > > "There are a few incompatible changes between bash-4.4 and bash-5.0" > (sure, these are in 'rarely used' things, but we have an awful *lot* of > shell scripts in us. We're a Linux distribution, it comes with the > territory. I'm pretty sure we use those 'rarely used' thing at least > somewhere) > > that *plus* the required readline version bump *plus* the suggestion > that some significant bugs were already discovered in the .0 release > makes me a little hesitant about this. I'm not saying "no!", but...it > certainly strikes me as a potentially disruptive change that needs some > kind of justification to go in late beyond "NEW SHINY". I agree that it would be much safer to target it for Fedora 31. I have no objection if we change target release. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > 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://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- -- Siteshwar Vashisht ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Mon, 2019-01-28 at 22:24 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 28 January 2019 at 03:57, Neal Gompa wrote: > [...] > > My understanding is that generally script breakage is considered a bug > > and would have priority for fixing in bash anyway, so I *really* don't > > think there's any harm in doing this. GCC is an order of magnitude > > worse than bash, and we do fine with that *every year*. Something that > > straight up says it's not intending to break scripts that just happens > > to say it's a 5.0 release should not be as much of a cause for > > concern. > > We do (upgrade GCC), but it's always a System Wide Change, and that > is the only issue with this proposal (which was submitted as a > Self-contained Change). It's not the "only" issue, because it was submitted over two weeks *after* the deadline for system-wide changes. I am somewhat concerned about dropping in a major new bash version quite late in the cycle and just before the mass rebuild, particularly when there are bits like this in the announcement: "There are a number of changes to the expansion of $@ and $* in various contexts where word splitting is not performed to conform to a Posix standard interpretation, and additional changes to resolve corner cases for Posix conformance." (are you *sure* all our corner cases are expecting Posix-conformant behaviour? I'm not) "The `globasciiranges' shell option is now enabled by default; it can be set to off by default at configuration time." (OK, so we can turn it off again if necessary, but still, could be interesting) "There are a few incompatible changes between bash-4.4 and bash-5.0" (sure, these are in 'rarely used' things, but we have an awful *lot* of shell scripts in us. We're a Linux distribution, it comes with the territory. I'm pretty sure we use those 'rarely used' thing at least somewhere) that *plus* the required readline version bump *plus* the suggestion that some significant bugs were already discovered in the .0 release makes me a little hesitant about this. I'm not saying "no!", but...it certainly strikes me as a potentially disruptive change that needs some kind of justification to go in late beyond "NEW SHINY". -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Monday, 28 January 2019 at 03:57, Neal Gompa wrote: [...] > My understanding is that generally script breakage is considered a bug > and would have priority for fixing in bash anyway, so I *really* don't > think there's any harm in doing this. GCC is an order of magnitude > worse than bash, and we do fine with that *every year*. Something that > straight up says it's not intending to break scripts that just happens > to say it's a 5.0 release should not be as much of a cause for > concern. We do (upgrade GCC), but it's always a System Wide Change, and that is the only issue with this proposal (which was submitted as a Self-contained Change). Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, 2019-01-27 at 21:52 -0500, Neal Gompa wrote: > On Sun, Jan 27, 2019 at 9:49 PM Siteshwar Vashisht > wrote: > > - Original Message - > > > From: "Nico Kadel-Garcia" > > > To: "Development discussions related to Fedora" > > > > > > Sent: Saturday, January 26, 2019 11:06:39 PM > > > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > > > > > It's also only been released for barely 2 weeks, it's marked as a > > > major revision number, and it seems a bit late to accept for Fedora > > > 30. Mark it as a candidate for Fedora 31, and move on? > > > > I am fine with doing that. But we are missing a chance to get some early > > testing on the latest release. > > > > Is there some way we can (ab)use Koschei to see how things would look > for bash 5.0 in Rawhide? Personally, I really don't think we'd have as > many problems as people fear, but if there's a way we could do > something interesting to prove it, that'd be great too. Koschei only builds things, so that would only catch issues in bash scripts used at build time (and only ones that caused a package build failure, at that). It would not catch any issues that didn't cause a package build failure, or any runtime issues in the vast swathes of bash that are used at runtime. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, 2019-01-27 at 22:28 -0500, Neal Gompa wrote: > On Sun, Jan 27, 2019 at 10:01 PM Siteshwar Vashisht > wrote: > > - Original Message - > > > From: "Neal Gompa" > > > To: "Development discussions related to Fedora" > > > > > > Cc: "Mikolaj Izdebski" , "Michael Simacek" > > > > > > Sent: Monday, January 28, 2019 3:52:32 AM > > > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > > > > > Is there some way we can (ab)use Koschei to see how things would look > > > for bash 5.0 in Rawhide? Personally, I really don't think we'd have as > > > many problems as people fear, but if there's a way we could do > > > something interesting to prove it, that'd be great too. > > > > During bash-4.4 rebase, I ran all Red Hat internal tests on it to verify > > nothing would break. I would check about the option to test with Koschei > > too. > > > > Have you run these tests on bash 5.0 rebase yet? Also, would it be > possible to get this into Fedora Dist-Git so that the checks could be > run as part of any build/update/PR to the package? Great point, Neal - that would indeed be super helpful, if it's possible. Siteshwar, in case you haven't seen it, https://fedoraproject.org/wiki/CI/Quick_Start_Guide is the quick start version of how to do this, and the longer write-ups are in: https://fedoraproject.org/wiki/CI/Tests https://fedoraproject.org/wiki/CI/Share_Test_Code https://fedoraproject.org/wiki/CI/Pull_Requests https://fedoraproject.org/wiki/CI/Examples the higher-level https://fedoraproject.org/wiki/CI page has an overview of the whole system, and other useful links. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
- Original Message - > From: "Neal Gompa" > To: "Development discussions related to Fedora" > > Cc: "Stef Walter" > Sent: Monday, January 28, 2019 4:28:15 AM > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > Have you run these tests on bash 5.0 rebase yet? Also, would it be > possible to get this into Fedora Dist-Git so that the checks could be > run as part of any build/update/PR to the package? I have not managed to do the rebase yet. Ideally these tests should be put in Fedora dist-git by our QE people, but it's really upto them how they handle it. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- -- Siteshwar Vashisht ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, Jan 27, 2019 at 10:01 PM Siteshwar Vashisht wrote: > > - Original Message - > > From: "Neal Gompa" > > To: "Development discussions related to Fedora" > > > > Cc: "Mikolaj Izdebski" , "Michael Simacek" > > > > Sent: Monday, January 28, 2019 3:52:32 AM > > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > > > Is there some way we can (ab)use Koschei to see how things would look > > for bash 5.0 in Rawhide? Personally, I really don't think we'd have as > > many problems as people fear, but if there's a way we could do > > something interesting to prove it, that'd be great too. > > During bash-4.4 rebase, I ran all Red Hat internal tests on it to verify > nothing would break. I would check about the option to test with Koschei too. > Have you run these tests on bash 5.0 rebase yet? Also, would it be possible to get this into Fedora Dist-Git so that the checks could be run as part of any build/update/PR to the package? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
- Original Message - > From: "Neal Gompa" > To: "Development discussions related to Fedora" > > Cc: "Mikolaj Izdebski" , "Michael Simacek" > > Sent: Monday, January 28, 2019 3:52:32 AM > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > Is there some way we can (ab)use Koschei to see how things would look > for bash 5.0 in Rawhide? Personally, I really don't think we'd have as > many problems as people fear, but if there's a way we could do > something interesting to prove it, that'd be great too. During bash-4.4 rebase, I ran all Red Hat internal tests on it to verify nothing would break. I would check about the option to test with Koschei too. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- -- Siteshwar Vashisht ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, Jan 27, 2019 at 9:55 PM Siteshwar Vashisht wrote: > > - Original Message - > > From: "Frantisek Zatloukal" > > To: "Development discussions related to Fedora" > > > > Sent: Friday, January 25, 2019 4:16:45 PM > > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > > > Why is this Self-Contained Change and not a System Wide Change? > > > > It seems, at least to me, that it should be System Wide Change, according to > > https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes . > > Although it's a major version, upstream is not intending to break any > existing scripts. That's why I kept it as a self-contained change. > My understanding is that generally script breakage is considered a bug and would have priority for fixing in bash anyway, so I *really* don't think there's any harm in doing this. GCC is an order of magnitude worse than bash, and we do fine with that *every year*. Something that straight up says it's not intending to break scripts that just happens to say it's a 5.0 release should not be as much of a cause for concern. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
- Original Message - > From: "Frantisek Zatloukal" > To: "Development discussions related to Fedora" > > Sent: Friday, January 25, 2019 4:16:45 PM > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > Why is this Self-Contained Change and not a System Wide Change? > > It seems, at least to me, that it should be System Wide Change, according to > https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes . Although it's a major version, upstream is not intending to break any existing scripts. That's why I kept it as a self-contained change. > > > > -- > > Best regards / S pozdravem, > > František Zatloukal > Quality Engineer > Red Hat > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- -- Siteshwar Vashisht ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sun, Jan 27, 2019 at 9:49 PM Siteshwar Vashisht wrote: > > - Original Message - > > From: "Nico Kadel-Garcia" > > To: "Development discussions related to Fedora" > > > > Sent: Saturday, January 26, 2019 11:06:39 PM > > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > > > It's also only been released for barely 2 weeks, it's marked as a > > major revision number, and it seems a bit late to accept for Fedora > > 30. Mark it as a candidate for Fedora 31, and move on? > > I am fine with doing that. But we are missing a chance to get some early > testing on the latest release. > Is there some way we can (ab)use Koschei to see how things would look for bash 5.0 in Rawhide? Personally, I really don't think we'd have as many problems as people fear, but if there's a way we could do something interesting to prove it, that'd be great too. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
- Original Message - > From: "Nico Kadel-Garcia" > To: "Development discussions related to Fedora" > > Sent: Saturday, January 26, 2019 11:06:39 PM > Subject: Re: F30 Self-Contained Change proposal: Bash 5.0 > > It's also only been released for barely 2 weeks, it's marked as a > major revision number, and it seems a bit late to accept for Fedora > 30. Mark it as a candidate for Fedora 31, and move on? I am fine with doing that. But we are missing a chance to get some early testing on the latest release. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- -- Siteshwar Vashisht ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Sat, Jan 26, 2019 at 12:05 PM Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 26 January 2019 at 17:15, John Reiser wrote: > [...] > > Already bash-5.0 has two official patches in three weeks. The first one > > fixes a bug in glob filename expansion. Use of globbing is almost > > universal, > > but the test cases did not catch the bug before release of bash-5.0. > > Often that is an indication that more bugs should be expected. > > > > The risk may be large. *EVERY* Fedora package uses bash. > > rpm .spec file sections such as %build, %install, %clean, %post use /bin/sh, > > and Fedora links /bin/sh -> bash. That surely is "system-wide". > > +1. > > Upgrading the default system shell should be treated similarly to > upgrading glibc. A System-Wide Change is definitely in order. > > Regards, > Dominik It's also only been released for barely 2 weeks, it's marked as a major revision number, and it seems a bit late to accept for Fedora 30. Mark it as a candidate for Fedora 31, and move on? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Saturday, 26 January 2019 at 17:15, John Reiser wrote: [...] > Already bash-5.0 has two official patches in three weeks. The first one > fixes a bug in glob filename expansion. Use of globbing is almost universal, > but the test cases did not catch the bug before release of bash-5.0. > Often that is an indication that more bugs should be expected. > > The risk may be large. *EVERY* Fedora package uses bash. > rpm .spec file sections such as %build, %install, %clean, %post use /bin/sh, > and Fedora links /bin/sh -> bash. That surely is "system-wide". +1. Upgrading the default system shell should be treated similarly to upgrading glibc. A System-Wide Change is definitely in order. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On 1/25/19 15:27 UTC, Neal Gompa wrote: On Fri, Jan 25, 2019 at 10:17 AM Frantisek Zatloukal wrote: Why is this Self-Contained Change and not a System Wide Change? It seems, at least to me, that it should be System Wide Change, according to https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes . Is it really that complicated? It's just a readline bump and bash itself getting bumped. From the Fedora perspective, it means we get to drop a whole bunch of patches we were already carrying since they are part of the 5.0 release. Yes, it is that complicated. "git diff --stat bash-4.4 bash-5.0" shows 528 files changed, 81767 insertions(+), 63829 deletions(-) in the 2 years and 3 months between releases. Some of the changes are included in Fedora's bash-4.4.3-23.1 but some are not. From the shell script language point of view, there is only one notable backwards incompatible change: a behavior change to namerefs, which are not commonly used at all. Already bash-5.0 has two official patches in three weeks. The first one fixes a bug in glob filename expansion. Use of globbing is almost universal, but the test cases did not catch the bug before release of bash-5.0. Often that is an indication that more bugs should be expected. The risk may be large. *EVERY* Fedora package uses bash. rpm .spec file sections such as %build, %install, %clean, %post use /bin/sh, and Fedora links /bin/sh -> bash. That surely is "system-wide". -- [[signature snipped]] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
On Fri, Jan 25, 2019 at 10:17 AM Frantisek Zatloukal wrote: > > Why is this Self-Contained Change and not a System Wide Change? > > It seems, at least to me, that it should be System Wide Change, according to > https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes . > Is it really that complicated? It's just a readline bump and bash itself getting bumped. From the Fedora perspective, it means we get to drop a whole bunch of patches we were already carrying since they are part of the 5.0 release. From the shell script language point of view, there is only one notable backwards incompatible change: a behavior change to namerefs, which are not commonly used at all. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 Self-Contained Change proposal: Bash 5.0
Why is this Self-Contained Change and not a System Wide Change? It seems, at least to me, that it should be System Wide Change, according to https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes . On Fri, Jan 25, 2019 at 3:45 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Bash_5.0 > > == Summary == > > Upgrade bash to 5.0 release. This release fixes several outstanding > bugs in bash-4.4 and introduces several > new features. The most significant bug fixes are an overhaul of how > nameref variables resolve and a number of potential out-of-bounds memory > errors discovered via fuzzing. > > == Owner == > * Name: [[User:svashisht| Siteshwar Vashisht]] > > * Email: svashi...@redhat.com > * Release notes owner: > > == Detailed Description == > > There are a number of changes to the > expansion of $@ and $* in various contexts where word splitting is not > performed to conform to a Posix standard interpretation, and additional > changes to resolve corner cases for Posix conformance. > > The most notable new features are several new shell variables: BASH_ARGV0, > EPOCHSECONDS, and EPOCHREALTIME. The `history` builtin can remove ranges of > history entries and understands negative arguments as offsets from the end > of the history list. There is an option to allow local variables to inherit > the value of a variable with the same name at a preceding scope. There is > a new shell option that, when enabled, causes the shell to attempt to > expand associative array subscripts only once (this is an issue when they > are used in arithmetic expressions). The `globasciiranges' shell option > is now enabled by default; it can be set to off by default at configuration > time. > > There are a few incompatible changes between bash-4.4 and bash-5.0. The > changes to how nameref variables are resolved means that some uses of > namerefs will behave differently, though upstream has tried to minimize the > compatibility issues. > > == Benefit to Fedora == > > Bash is the default shell in Fedora and it will benefit from new > features and performance improvements of the latest release. > > == Scope == > * Proposal owners: Upgrade bash to 5.0 > * Other developers: N/A (not a System Wide Change) > * Release engineering: [https://pagure.io/releng/issues #Releng issue > number] (a check of an impact with Release Engineering is needed) > ** List of deliverables]: N/A (not a System Wide Change) > * Policies and guidelines: N/A (not a System Wide Change) > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > Code related to resolving namerefs was changed, so some scripts may > break. But impact should be minimum as this release is largely > backward compatible. > > == Dependencies == > N/A (not a System Wide Change) > > > > == Documentation == > N/A (not a System Wide Change) > > == Release Notes == > https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063.html > > > > -- > Ben Cotton > Fedora Program Manager > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Best regards / S pozdravem, František Zatloukal Quality Engineer Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
