Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)
On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: previous-release-blocker(s) and previous-previous-release-blockers(s), since the changes would need to be deployed in F32 and F31. Also note that the last time when the upgrade plugins run code is in upgrade phase between two reboots, and the plugin is running pre-upgrade code. This code would then invoke post-upgrade rpm. It's certainly doable, but seems a bit funky. Right, requiring changes to previous versions is not okay. I seem to be thinking our upgrade tooling had gotten fixed at some point to perform the upgrade on the target distro packaging management stack as it would really need to be, but guess that was just a dream. Relying on the target distro management stack sound nice, but is actually problematic: how do you run the next version before you install the next version? Sure, you can install stuff to some temporary location and run the tools from there, but then you are running in a very custom franken-environment. Such a mode of running would face the same issue as anaconda installer: it would only get tested during the upgrade season, languishing otherwise. Mock has this cool bootstrap image thing now. It seems to me we could use that image to run the system upgrades too [*]. And if/when we get koji to use that, it'll solve a number of ages old problems on the build system, AND that image will get heavily tested 24/7 so it wouldn't be any once in a full moon franken-thing. [*] Mount the host filesystem from mock and perform a dnf --instalroot=... distro-upgrade on that, turning the whole landscape inside out. So nowadays we have a much simpler mechanism: reboot to a special system target without most daemons running (to avoid interference during the upgrade), run the update there, reboot into the new environment. The biggest advantage is that this way we reduce the amount of "custom": we're running normal installed dnf + rpm in a normal boot environment, we just stop the boot from progressing all the way to the usual graphical environment. I think it's fair to say that amount of bugs related to the upgrade mechanism has been greatly reduced compared to previous schemes. We still have various upgrade issues, but they are in the rpms themselves, and not how we install them. Such a scheme may be feasible in a fast-moving distro like Fedora where you can always afford to sit out the next six months waiting for the new thing to become available also in rawhide-1 version, but it's totally non-feasible in something like RHEL. RHEL/CentOS 7 to 8 upgrades with such a scheme only happen to "work" because of bugs such as missing rpmlib() dependency on file triggers kinda let things stumble through the cracks. - Panu - ___ 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: Upgrade tooling
On 3/27/20 9:04 AM, Panu Matilainen wrote: On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: previous-release-blocker(s) and previous-previous-release-blockers(s), since the changes would need to be deployed in F32 and F31. Also note that the last time when the upgrade plugins run code is in upgrade phase between two reboots, and the plugin is running pre-upgrade code. This code would then invoke post-upgrade rpm. It's certainly doable, but seems a bit funky. Right, requiring changes to previous versions is not okay. I seem to be thinking our upgrade tooling had gotten fixed at some point to perform the upgrade on the target distro packaging management stack as it would really need to be, but guess that was just a dream. Relying on the target distro management stack sound nice, but is actually problematic: how do you run the next version before you install the next version? Sure, you can install stuff to some temporary location and run the tools from there, but then you are running in a very custom franken-environment. Such a mode of running would face the same issue as anaconda installer: it would only get tested during the upgrade season, languishing otherwise. You can also boot into live cd of the next version, mount the existing filesystems similarly to what the rescue image does, and run dnf --installroot=... upgrade from there. Whether manually, or using special tooling. Tooling which would still all be from the next version and thus issues fixable without pushing changes to multiple old versions. - Panu - ___ 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: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)
On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: > On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: > >On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: > >>> previous-release-blocker(s) and previous-previous-release-blockers(s), > >>> since the changes would need to be deployed in F32 and F31. Also > >>> note that the last time when the upgrade plugins run code is in > >>> upgrade phase between two reboots, and the plugin is running > >>> pre-upgrade code. This code would then invoke post-upgrade rpm. It's > >>> certainly doable, but seems a bit funky. > >> > >>Right, requiring changes to previous versions is not okay. I seem to > >>be thinking our upgrade tooling had gotten fixed at some point to > >>perform the upgrade on the target distro packaging management stack > >>as it would really need to be, but guess that was just a dream. > > > >Relying on the target distro management stack sound nice, but is > >actually problematic: how do you run the next version before you > >install the next version? Sure, you can install stuff to some temporary > >location and run the tools from there, but then you are running in > >a very custom franken-environment. Such a mode of running would face > >the same issue as anaconda installer: it would only get tested during > >the upgrade season, languishing otherwise. > > Mock has this cool bootstrap image thing now. It seems to me we > could use that image to run the system upgrades too [*]. And if/when > we get koji to use that, it'll solve a number of ages old problems > on the build system, AND that image will get heavily tested 24/7 so > it wouldn't be any once in a full moon franken-thing. > > [*] Mount the host filesystem from mock and perform a dnf > --instalroot=... distro-upgrade on that, turning the whole landscape > inside out. Where would mock be executing from? The same filesystem it is modifying? Somehow it seems that this doesn't change much, but just brings in another layer. Or will a complete copy of the system be made in memory to execute the upgrade tools from? Let's consider a concrete example that came up recently: grub wants to rewrite something in the bootloader area on disk to help upgrades from very old installations. In current "offline upgrade" scheme, the upgrade tools are running on the real system, with udev active. They can query and touch hardware, can see all the disks as they are, etc. If we went through mock, it'd be running in an nspawn environment w/o access to hardware. (Something like os-tree's atomic replacement of things, that's of course a completely different story. But so far we're talking about traditional systems.) > >So nowadays we have a much simpler mechanism: reboot to a special > >system target without most daemons running (to avoid interference > >during the upgrade), run the update there, reboot into the new > >environment. The biggest advantage is that this way we reduce the > >amount of "custom": we're running normal installed dnf + rpm in a > >normal boot environment, we just stop the boot from progressing all > >the way to the usual graphical environment. > > > >I think it's fair to say that amount of bugs related to the upgrade > >mechanism has been greatly reduced compared to previous schemes. We > >still have various upgrade issues, but they are in the rpms > >themselves, and not how we install them. > > Such a scheme may be feasible in a fast-moving distro like Fedora > where you can always afford to sit out the next six months waiting > for the new thing to become available also in rawhide-1 version, but > it's totally non-feasible in something like RHEL. RHEL/CentOS 7 to 8 > upgrades with such a scheme only happen to "work" because of bugs > such as missing rpmlib() dependency on file triggers kinda let > things stumble through the cracks. The premise is that the upgrade is really a normal dnf upgrade, i.e. a normal 'rpm -U' operation under the hood. The differences are: 1: package count, 2: setting up the machine in a mode where the graphical env. and other non-essential daemons are not active. So if requirements in rpms are specified correctly, the upgrade always should go through. If they are specified incorrectly — then the same problems would occur on smaller updates. So the upgrade path is something to test to catch such issues in packaging. (And in general, the less scriptlets, the better. This solves the issue even better.) 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
Fedora-Cloud-30-20200327.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: Upgrade tooling
On 3/27/20 9:55 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: previous-release-blocker(s) and previous-previous-release-blockers(s), since the changes would need to be deployed in F32 and F31. Also note that the last time when the upgrade plugins run code is in upgrade phase between two reboots, and the plugin is running pre-upgrade code. This code would then invoke post-upgrade rpm. It's certainly doable, but seems a bit funky. Right, requiring changes to previous versions is not okay. I seem to be thinking our upgrade tooling had gotten fixed at some point to perform the upgrade on the target distro packaging management stack as it would really need to be, but guess that was just a dream. Relying on the target distro management stack sound nice, but is actually problematic: how do you run the next version before you install the next version? Sure, you can install stuff to some temporary location and run the tools from there, but then you are running in a very custom franken-environment. Such a mode of running would face the same issue as anaconda installer: it would only get tested during the upgrade season, languishing otherwise. Mock has this cool bootstrap image thing now. It seems to me we could use that image to run the system upgrades too [*]. And if/when we get koji to use that, it'll solve a number of ages old problems on the build system, AND that image will get heavily tested 24/7 so it wouldn't be any once in a full moon franken-thing. [*] Mount the host filesystem from mock and perform a dnf --instalroot=... distro-upgrade on that, turning the whole landscape inside out. Where would mock be executing from? The same filesystem it is modifying? Where is the offline upgrade executing from? How's this fundamentally different? Somehow it seems that this doesn't change much, but just brings in another layer. Or will a complete copy of the system be made in memory to execute the upgrade tools from? Oh come on. Running from a bootstrap image allows using full native capabilities of rpm/dnf in any new version, without having to consider what the previous versions support. How's that "not much"? Let's consider a concrete example that came up recently: grub wants to rewrite something in the bootloader area on disk to help upgrades from very old installations. In current "offline upgrade" scheme, the upgrade tools are running on the real system, with udev active. They can query and touch hardware, can see all the disks as they are, etc. If we went through mock, it'd be running in an nspawn environment w/o access to hardware. And still that offline upgrade will be running on the old systems kernel which will simply *prevent* certain types of actions to be performed in an upgrade, just like using host system packaging stack *prevents* use of native capabilities in the next version, just because the old version doesn't support them, which is just totally a** backwards. Really. Note that I'm talking about a high-level idea here. I haven't looked at what a mock bootstrap image looks like, I haven't looked at what offline upgrade looks like. Sure there would be technical details, perhaps obstacles even to sort out. (Something like os-tree's atomic replacement of things, that's of course a completely different story. But so far we're talking about traditional systems.) So nowadays we have a much simpler mechanism: reboot to a special system target without most daemons running (to avoid interference during the upgrade), run the update there, reboot into the new environment. The biggest advantage is that this way we reduce the amount of "custom": we're running normal installed dnf + rpm in a normal boot environment, we just stop the boot from progressing all the way to the usual graphical environment. I think it's fair to say that amount of bugs related to the upgrade mechanism has been greatly reduced compared to previous schemes. We still have various upgrade issues, but they are in the rpms themselves, and not how we install them. Such a scheme may be feasible in a fast-moving distro like Fedora where you can always afford to sit out the next six months waiting for the new thing to become available also in rawhide-1 version, but it's totally non-feasible in something like RHEL. RHEL/CentOS 7 to 8 upgrades with such a scheme only happen to "work" because of bugs such as missing rpmlib() dependency on file triggers kinda let things stumble through the cracks. The premise is that the upgrade is really a normal dnf upgrade, i.e. a normal 'rpm -U' operation under the hood. The differences are: 1: package count, 2: setting up the machine in a mode where the graphical env. and other non-essential daemons are not active. So if requirements in rpms are specified correctly, the
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): > On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: >> >> Dne 25. 03. 20 v 20:22 James Cassell napsal(a): >>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): > Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): >>> [snip] >> We can come up with guidelines, for example: >> >> 1) Try to find a way to resolve the issue without any conditionals first. >> >> There should be a reason why package X needs a dependency Y in Fedora >> and there should be a reason why it is a required dependency and not a >> recommended one. So why in that case downstream wants it differently? >> The first approach is just to talk through it. I can assume cases >> where downstream adds a dependency, as well as Fedora package removing >> them. >> >> Note that bloated dependency trees is a common problem for all binary >> distributions, it is not an "EL-thing" and we can work on that >> together. >> >> Nicolas has pointed out to another reason why we would get >> EL-conditionals: the outdated rpm stack in RHEL. But we don't have >> this problem with ELN, as we are building Rawhide, and rpm stack is >> going to be the Rawhide rpm stack as well. >> >> 2) Minimize and isolate the conditional, and track the reason. >> >> As ELN SIG we need to have a place where we collect known reasons for >> such conditionals. The overall goal is to reduce this set, not to grow >> indefinitely. As Stephen said we expect it to be about couple of >> hundred packages. We will be able to track each one of them. (We have >> rpminspect to run package diffs for us). >> >> 3) In complex cases - bring it to community and FESCo. >> >> We don't know what those complex cases might be, one of the goals is >> to find them. So we keep it as an option to bring individual case to a >> wider audience. To ask for help and to decide on it. >> > It seems there are missing real life examples of what we sometimes do in > RHEL, so please see attached patch. This patch is coming from RHEL > version of the espeak-ng. Now somebody tell me what it does for what > purpose and which scenario from the above three should be applied here. > > > Vít > And here is another example for the curious. >>> Both of these examples have to do with docs generation and trying to reduce >>> dependencies for that process. "Process the man page using kramdown and >>> remove the ronn dependency." >> >> The point is that these types of changes are not upstreamable. And the >> conditions would also be awful. Having these changes in separate branch >> would be much preferable IMO, because honestly, I would like every >> Fedora maintainer save from this cruft not because I would like to hide >> something, but for their own sanity. > I disagree actually. > > Disabling docs to reduce dependencies makes sense. And it is not a > RHEL-only thing. I am sorry but you have not passed the test. The test question was "Now somebody tell me what it does for what purpose and which scenario from the above three should be applied here." I would really appreciate, if you could pay attention to the two patches I post and what they do. Including careful analysis why they were applied and why they were not put into Fedora nor upstreamed. Hint: They don't disable any documentation. Thank you. Vít P.S. I really thinking if I should write this and if and how much I am offended, because I typically try to remove my feeling from these discussions. But really, I and other colleagues have spent quite some effort to untangle the whole dependency mess, to provide our users as much as we can, to give back to fedora and upstream as much as we can and stay sane. That were not easy decisions. I spent the time to dig out these specific examples of what we did and why I think it is important to have branches instead of "just conditions", but you don't pay enough attention and you dismiss them as "Disabling docs". I am sorry, but this is not fair. > > I had the conversation at the latest Devconf with people who are > aiming to build Linux distribution with a reduced buildroot footprint > for security purposes. So that they can audit the content of the > buildroot, and get to a certain level of certification with it. > I think It can not be done directly in Fedora, but if we add the > flexibility into our builds (with conditionals), then we could > eventually get a new downstream supported by a certain governmental > entity. > > What we should avoid is using conditionals randomly and inconsistently. > > So let's agree that we are not scattering "%if 0%{?rhel} && (! > 0%{?epel})" all over the spec file, but rather define it once at the > top of the spec file: > > %if 0%{?rhel} && (! 0%{?epel}) > %bcond_with docs > %else > %bcond_without
Fedora-Cloud-31-20200327.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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch wrote: > > > Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): > > On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: > >> > >> Dne 25. 03. 20 v 20:22 James Cassell napsal(a): > >>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: > Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): > > Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): > >>> [snip] > >> We can come up with guidelines, for example: > >> > >> 1) Try to find a way to resolve the issue without any conditionals > >> first. > >> > >> There should be a reason why package X needs a dependency Y in Fedora > >> and there should be a reason why it is a required dependency and not a > >> recommended one. So why in that case downstream wants it differently? > >> The first approach is just to talk through it. I can assume cases > >> where downstream adds a dependency, as well as Fedora package removing > >> them. > >> > >> Note that bloated dependency trees is a common problem for all binary > >> distributions, it is not an "EL-thing" and we can work on that > >> together. > >> > >> Nicolas has pointed out to another reason why we would get > >> EL-conditionals: the outdated rpm stack in RHEL. But we don't have > >> this problem with ELN, as we are building Rawhide, and rpm stack is > >> going to be the Rawhide rpm stack as well. > >> > >> 2) Minimize and isolate the conditional, and track the reason. > >> > >> As ELN SIG we need to have a place where we collect known reasons for > >> such conditionals. The overall goal is to reduce this set, not to grow > >> indefinitely. As Stephen said we expect it to be about couple of > >> hundred packages. We will be able to track each one of them. (We have > >> rpminspect to run package diffs for us). > >> > >> 3) In complex cases - bring it to community and FESCo. > >> > >> We don't know what those complex cases might be, one of the goals is > >> to find them. So we keep it as an option to bring individual case to a > >> wider audience. To ask for help and to decide on it. > >> > > It seems there are missing real life examples of what we sometimes do in > > RHEL, so please see attached patch. This patch is coming from RHEL > > version of the espeak-ng. Now somebody tell me what it does for what > > purpose and which scenario from the above three should be applied here. > > > > > > Vít > > > And here is another example for the curious. > > >>> Both of these examples have to do with docs generation and trying to > >>> reduce dependencies for that process. "Process the man page using > >>> kramdown and remove the ronn dependency." > >> > >> The point is that these types of changes are not upstreamable. And the > >> conditions would also be awful. Having these changes in separate branch > >> would be much preferable IMO, because honestly, I would like every > >> Fedora maintainer save from this cruft not because I would like to hide > >> something, but for their own sanity. > > I disagree actually. > > > > Disabling docs to reduce dependencies makes sense. And it is not a > > RHEL-only thing. > > > I am sorry but you have not passed the test. The test question was "Now > somebody tell me what it does for what > purpose and which scenario from the above three should be applied here." > I would really appreciate, if you could pay attention to the two > patches I post and what they do. Including careful analysis why they > were applied and why they were not put into Fedora nor upstreamed. > > Hint: They don't disable any documentation. You put two patches on the thread without context. I assumed that they remove the fancy dependency needed to build the doc, and instead create the doc in a more "old-school" ways. It maybe a wrong assumption. It happens. Could you then explain the context, and what these patches actually do? > Thank you. > > > Vít > > > P.S. I really thinking if I should write this and if and how much I am > offended, because I typically try to remove my feeling from these > discussions. But really, I and other colleagues have spent quite some > effort to untangle the whole dependency mess, to provide our users as > much as we can, to give back to fedora and upstream as much as we can > and stay sane. That were not easy decisions. > > I spent the time to dig out these specific examples of what we did and > why I think it is important to have branches instead of "just > conditions", but you don't pay enough attention and you dismiss them as > "Disabling docs". I am sorry, but this is not fair. If I were offended every time people don't get my point and the effort I made to make it, I would give up about 15 years ago. But that is what discussions are all about: going through a lot of misunderstanding, trying to actually reach the point where we can understan
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Thu, Mar 26, 2020 at 3:55 PM Petr Viktorin wrote: > > On 2020-03-25 17:33, Aleksandra Fedorova wrote: > > [Branching] removes community maintainer from the conversation about what > > downstream is doing. While we want to give community member a voice in > > that conversation. > > I fear that this proposal *forces* the community member to participate > in the discussion. That is a very different thing than giving them a voice. > > > On 2020-03-25 17:10, Miro Hrončok wrote: > > On 25. 03. 20 16:47, Stephen Gallagher wrote: > >> I think we managed to miss a few key points in the Change Proposal > >> which is directly resulting in a bit of the confusion here. > > > > Reading the rest of you e-mail I must agree that this is what happened. > > Would you mind putting the change back to incomplete state and resend it > > once more for feedback once this is addressed? > > > >> The first and most important of these is that ELN will*not* be > >> building the complete Fedora package set. We're going to be building a > >> selected subset of packages (derived from packages in RHEL 8 and > >> EPEL). Our current expectation is that we are going to be looking at > >> fewer than 2500 source packages. We are still working up the initial > >> list of these and we will update the Change Proposal with it (as well > >> as providing a fedora-devel post breaking down the known owners). > > > > Glad to hear that. > > > >> Second, from this reduced subset, we expect that the overwhelming > >> majority of the maintainers are Red Hat employees that already work on > >> RHEL. With this in mind, we think that the level of concern about how > >> this will affect non-Red Hat contributors is premature. We will reach > >> out directly to those non-Red Hat contributors we identify. > > This actually worries me very much. > > The subset of packages will need to form a working system; it will > include the most important packages. I hope this doesn't end up limiting > maintainers of Fedora's most central packages to only Red Hatters or > those that agree to play by RHEL rules that they have no say in. > > I am pretty sure that most packages/packagers will be OK with the ELN > change. But "most" is not enough. We do need to take the "worst cases" > into account. Consider a package that: > - is needed in RHEL, but only as a dependency of something vital; the > RHEL maintainer doesn't care too much about it outside their work duties > - has an enthusiastic packager in Fedora, who prefers to leave RHEL work > to paid developers > > (As member of a team that, some time ago, used to be catch-all RHEL > maintainer for anything that happened to be written in Python, I can > definitely imagine situations similar to this.) > > For such a package, we need to avoid pushing ELN macros into the > package, otherwise we lose an enthusiastic contributor who does amazing > work in Fedora. > > Such a package might even be hypothetical right now, but the case still > needs to be adressed. A package can fall into this category at any time > in the future. It's not enough to identifying packagers that are > affected now, and work with them. There needs to be a process for cases > like these, and it can't be "merge these ELN macros now, there's a > deadline coming; maybe we'll come up with a better process in the > future". (Especially if Red Hat is unlikely to drive setting up a better > process.) > > IMO, any changes needed in EL need to be opt-in, with the understanding > that opting in will be (almost always) beneficial for everyone involved. > They need to feel like a gift ("Hello fedora packager, please accept > this PR with EL macros; it'll make it easier to work on this together!") > rather than forced ("Red Hat needs this; merge it or else"). I wonder how we ended up with people feeling like we are proposing latter rather than the former. I guess I took couple of wrong turns in this discussion, and I'd like to step back and try again. Me, Stephen and Troy are going to update the proposal, and come up with a better description of how opt-in will look like. > To borrow Neal Gompa's words, ELN needs to not feel "like it's written > for Red Hat people to move their sandbox outside of Red Hat into Fedora > without anyone else to be able to play in the sandbox." > > > For ELN changes to be to be opt-in, there essentially needs to be a > place to diverge -- a place for ELN hotfixes to live while polishing > them and debating their usefulness in Fedora and further upstreams. > Here by "hotfix" I need something required in RHEL that is not yet ready > for upstream. It is healthy to have a place for such things: it removes > time pressure from discussions (people from the community very often > have good ideas but less time), but allows the fix to be used now (so > the rest of ELN isn't blocked). > Forks are good if they're not permanent (but, making them not permanent > needs effort). > > > As Miro Hrončok continues: > > As a Red employee if I need to diver
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a): > On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch wrote: >> >> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): >>> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: Dne 25. 03. 20 v 20:22 James Cassell napsal(a): > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): > [snip] We can come up with guidelines, for example: 1) Try to find a way to resolve the issue without any conditionals first. There should be a reason why package X needs a dependency Y in Fedora and there should be a reason why it is a required dependency and not a recommended one. So why in that case downstream wants it differently? The first approach is just to talk through it. I can assume cases where downstream adds a dependency, as well as Fedora package removing them. Note that bloated dependency trees is a common problem for all binary distributions, it is not an "EL-thing" and we can work on that together. Nicolas has pointed out to another reason why we would get EL-conditionals: the outdated rpm stack in RHEL. But we don't have this problem with ELN, as we are building Rawhide, and rpm stack is going to be the Rawhide rpm stack as well. 2) Minimize and isolate the conditional, and track the reason. As ELN SIG we need to have a place where we collect known reasons for such conditionals. The overall goal is to reduce this set, not to grow indefinitely. As Stephen said we expect it to be about couple of hundred packages. We will be able to track each one of them. (We have rpminspect to run package diffs for us). 3) In complex cases - bring it to community and FESCo. We don't know what those complex cases might be, one of the goals is to find them. So we keep it as an option to bring individual case to a wider audience. To ask for help and to decide on it. >>> It seems there are missing real life examples of what we sometimes do in >>> RHEL, so please see attached patch. This patch is coming from RHEL >>> version of the espeak-ng. Now somebody tell me what it does for what >>> purpose and which scenario from the above three should be applied here. >>> >>> >>> Vít >>> >> And here is another example for the curious. >> > Both of these examples have to do with docs generation and trying to > reduce dependencies for that process. "Process the man page using > kramdown and remove the ronn dependency." The point is that these types of changes are not upstreamable. And the conditions would also be awful. Having these changes in separate branch would be much preferable IMO, because honestly, I would like every Fedora maintainer save from this cruft not because I would like to hide something, but for their own sanity. >>> I disagree actually. >>> >>> Disabling docs to reduce dependencies makes sense. And it is not a >>> RHEL-only thing. >> >> I am sorry but you have not passed the test. The test question was "Now >> somebody tell me what it does for what >> purpose and which scenario from the above three should be applied here." >> I would really appreciate, if you could pay attention to the two >> patches I post and what they do. Including careful analysis why they >> were applied and why they were not put into Fedora nor upstreamed. >> >> Hint: They don't disable any documentation. > You put two patches on the thread without context. I assumed that they > remove the fancy dependency needed to build the doc, and instead > create the doc in a more "old-school" ways. > It maybe a wrong assumption. It happens. > > Could you then explain the context, and what these patches actually do? There is much more to this. One think of course is to limit the dependencies. So therefore we didn't want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned upstream. If Ronn is abandoned upstream, the biggest problem is with its dependencies, which are officially deprecated upstream. While it is abandoned upstream, it is still valuable tool, which can easily generate man pages from markdown. So now on top of the question "should we have Ronn in RHEL or not" you have suddenly other issues: * Should we save upstream Ronn? And how to do this if upstream is unresponsive. * How to provide the documentation to our users if we don't have Ronn available. * Should I go to Fedora and push the Ronn removal out of the package and possible from all packages, while we still have Ronn in Fedora? * Should I go to all upstreams and convince them, that they should not use Ronn, just beca
ActionNotAllowed: policy violation (build_from_srpm)
Hey guys, I am trying to build a SRPM since mockbuild does not work due to (1). # fedpkg srpm # fedpkg build --srpm /home/lzap/work/fedpkg/workrave/workrave-1.10.37-1.fc33.src.rpm But getting %SUBJ%: https://koji.fedoraproject.org/koji/taskinfo?taskID=42794359 What is wrong? I believe my kerberos is correct: # kinit Ticket cache: KEYRING:persistent:1000:1000 Default principal: l...@fedoraproject.org Valid starting Expires Service principal 27.3.2020 11:19:54 28.3.2020 08:57:58 HTTP/koji.fedoraproject@fedoraproject.org renew until 3.4.2020 09:57:58 27.3.2020 10:21:05 28.3.2020 08:57:58 HTTP/src.fedoraproject@fedoraproject.org renew until 3.4.2020 09:57:58 27.3.2020 08:57:59 28.3.2020 08:57:58 krbtgt/fedoraproject@fedoraproject.org renew until 3.4.2020 09:57:58 (1) https://bugzilla.redhat.com/show_bug.cgi?id=1812872 ___ 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: ActionNotAllowed: policy violation (build_from_srpm)
Lukas Zapletal píše v Pá 27. 03. 2020 v 10:30 +: > Hey guys, I am trying to build a SRPM since mockbuild does not work > due to (1). > > # fedpkg srpm > # fedpkg build --srpm /home/lzap/work/fedpkg/workrave/workrave- > 1.10.37-1.fc33.src.rpm Real builds from SRPM are not allowed for Fedora packages (and IMO never were). Use a scratch build for testing: fedpkg scratch-build --srpm ... > But getting %SUBJ%: > https://koji.fedoraproject.org/koji/taskinfo?taskID=42794359 > > What is wrong? I believe my kerberos is correct: > > # kinit > Ticket cache: KEYRING:persistent:1000:1000 > Default principal: l...@fedoraproject.org > > Valid starting Expires Service principal > 27.3.2020 11:19:54 28.3.2020 08:57:58 > HTTP/koji.fedoraproject@fedoraproject.org > renew until 3.4.2020 09:57:58 > 27.3.2020 10:21:05 28.3.2020 08:57:58 > HTTP/src.fedoraproject@fedoraproject.org > renew until 3.4.2020 09:57:58 > 27.3.2020 08:57:59 28.3.2020 08:57:58 > krbtgt/fedoraproject@fedoraproject.org > renew until 3.4.2020 09:57:58 > > (1) https://bugzilla.redhat.com/show_bug.cgi?id=1812872 > ___ > 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: ELN Buildroot and Compose
On 27. 03. 20 10:59, Vít Ondruch wrote: As you can see, there is much more to this just to "put some conditional somewhere". There are very complex considerations and a lot of work. I would also like to point out the obvious: The RHEL only patch needs to be rebased every time the package is updated to a new version. - RHEL doesn't generally do updates like this - Fedora generally does updates like this often A Fedora contributor will try to build the updated package in mock and it will work, they will submit a PR (better case) or push directly. When the package is attempted to be built in ELN, the patch(es) won't apply. If the update was submitted via a PR and the PR pipeline/CI will provide this kind of feedback, the Fedora contributor will be intimidated by this. If the package will be gated on ELN, the Fedora contributor will be intimidated by this. If there is no gating and there is a direct push, the ELN build will be broken. The RHEL/ELN maintianer will need to push a fixup patch-rebase commit or live with a broken ELN package. This might happen several times between RHEL 8 and 9, while the patch would only be rebased/created once trough 1 major RHEL release lifetime. -- 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
Need help from Provenpackager
Hello! Lutris broken completely on F32 and many users asking what happens with package. Lutris always up to day in Fedora and i personally doesn't have any issues with it or all this time until this, but seems like this time ' bunnyapocalypse' just busy [1] to fix it and merge my PR [2]. Can we merge PR and build it for F32? It's already tested and it works. [1] https://src.fedoraproject.org/rpms/lutris/pull-request/1#comment-36580 [2] https://src.fedoraproject.org/rpms/lutris/pull-request/2 ___ 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: ELN Buildroot and Compose
On 26. 03. 20 16:13, Miro Hrončok wrote: On 25. 03. 20 17:10, Miro Hrončok wrote: Finally, of the set of packages that we're going to be including, we anticipate around 200-300 of them will have distro conditionals that need investigation (with fewer needing actual modification). The ELN SIG will be doing this initial investigation and will provide guidance (and/or PRs) to affected packagers. My concerns still remain, although I am now not so scared that this will alienate the community. Now the concern is more personal (= previously I was worried that everybody will be encouraged to use the conditionals, while now I'm mostly concerned they I will be encouraged to use the conditionals). Also, to make this more clear: I am not worried about the conditionals because I would need to maintain them. I am worried that "my" packages will be harder to co-maintain (or generally changed) by people from the community. As an example, I will know the RHEL 9 (10, 11...) plans and I can structure my specs accordingly. However if there is a passionate Fedora contributor who would like so submit a Pull Request for e.g. python-virtualenv to update it to a new fancy version that does things differently, they are not familiar about our RHEL plans and they would not be capable to wrap their head around such conditionals. They would also need to rebase any RHEL-only patches for this to work. At the end, they are more likely to just go away and not do it at all. Another example. In a corporate meeting with the product owners/managers, we decide that the next major RHEL release will include Brainfuck 7 because it an LTS release. Fedora rawhide is updated to Brainfuck 7 and everything is nice and fine. Later, Brainfuck 8 is released. The Fedora community wants this new version, because it finally has a support for Brainloller and the Ook! stack depends on this new feature. The Ook! stack is not planned to be in RHEL, so from RHEL perspective, this new feature is not that important. But the Ook! SIG obviously wants this. The RHEL maintainer now needs to artificially block the Brainfuck 8 update from rawhide until next RHEL is branched (they probably cannot even share when this is going to be with the Fedora community because NDA). This prevents the "First" foundation of Fedora (and TBH it also prevents "Friends", the RHEL maintainer is actively blocking the Ook SIG here by their (in)action). The conditional approach will only allow this: %if 0%{?rhel} Version: 7.4.5 %else Version: 8.0.0~rc1 %endif (And I assume the rest of the spec file would need major %if/%else mess as well, because Brainfuck 8 is built with meson, while Brainfuck 7 is built with autotools. Or the implementation language changed from C to Rust...) And trust me, you don't want to maintain that. It is not maintainable. And it has problems like this: https://pagure.io/copr/copr/issue/1315 Another approach is compat packages, but Brainfuck 8 is backwards compatible with 7, so it brings no benefit for Fedora. Another approach is modularity, but the Ook! SIG doesn't want to use modules because they want their Ook-based apps to be easily available to Fedora users. Sorry for going artificial with the example, but I didn't want you to say "you are always talking about Python, what you say is Python specific" -- because it isn't. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
Dne 27. 03. 20 v 12:32 Miro Hrončok napsal(a): > > And trust me, you don't want to maintain that. It is not maintainable. > And it has problems like this: > https://pagure.io/copr/copr/issue/1315 > Heh, nice one :) Thanks for sharing Ví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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch wrote: > > > Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a): > > On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch wrote: > >> > >> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): > >>> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: > Dne 25. 03. 20 v 20:22 James Cassell napsal(a): > > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: > >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): > >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): > > [snip] > We can come up with guidelines, for example: > > 1) Try to find a way to resolve the issue without any conditionals > first. > > There should be a reason why package X needs a dependency Y in Fedora > and there should be a reason why it is a required dependency and not > a > recommended one. So why in that case downstream wants it differently? > The first approach is just to talk through it. I can assume cases > where downstream adds a dependency, as well as Fedora package > removing > them. > > Note that bloated dependency trees is a common problem for all binary > distributions, it is not an "EL-thing" and we can work on that > together. > > Nicolas has pointed out to another reason why we would get > EL-conditionals: the outdated rpm stack in RHEL. But we don't have > this problem with ELN, as we are building Rawhide, and rpm stack is > going to be the Rawhide rpm stack as well. > > 2) Minimize and isolate the conditional, and track the reason. > > As ELN SIG we need to have a place where we collect known reasons for > such conditionals. The overall goal is to reduce this set, not to > grow > indefinitely. As Stephen said we expect it to be about couple of > hundred packages. We will be able to track each one of them. (We have > rpminspect to run package diffs for us). > > 3) In complex cases - bring it to community and FESCo. > > We don't know what those complex cases might be, one of the goals is > to find them. So we keep it as an option to bring individual case to > a > wider audience. To ask for help and to decide on it. > > >>> It seems there are missing real life examples of what we sometimes do > >>> in > >>> RHEL, so please see attached patch. This patch is coming from RHEL > >>> version of the espeak-ng. Now somebody tell me what it does for what > >>> purpose and which scenario from the above three should be applied > >>> here. > >>> > >>> > >>> Vít > >>> > >> And here is another example for the curious. > >> > > Both of these examples have to do with docs generation and trying to > > reduce dependencies for that process. "Process the man page using > > kramdown and remove the ronn dependency." > The point is that these types of changes are not upstreamable. And the > conditions would also be awful. Having these changes in separate branch > would be much preferable IMO, because honestly, I would like every > Fedora maintainer save from this cruft not because I would like to hide > something, but for their own sanity. > >>> I disagree actually. > >>> > >>> Disabling docs to reduce dependencies makes sense. And it is not a > >>> RHEL-only thing. > >> > >> I am sorry but you have not passed the test. The test question was "Now > >> somebody tell me what it does for what > >> purpose and which scenario from the above three should be applied here." > >> I would really appreciate, if you could pay attention to the two > >> patches I post and what they do. Including careful analysis why they > >> were applied and why they were not put into Fedora nor upstreamed. > >> > >> Hint: They don't disable any documentation. > > You put two patches on the thread without context. I assumed that they > > remove the fancy dependency needed to build the doc, and instead > > create the doc in a more "old-school" ways. > > It maybe a wrong assumption. It happens. > > > > Could you then explain the context, and what these patches actually do? > > > There is much more to this. > > One think of course is to limit the dependencies. So therefore we didn't > want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned > upstream. If Ronn is abandoned upstream, the biggest problem is with its > dependencies, which are officially deprecated upstream. While it is > abandoned upstream, it is still valuable tool, which can easily generate > man pages from markdown. So now on top of the question "should we have > Ronn in RHEL or not" you have suddenly other issues: > > * Should we save upstream Ronn? And how to do this if upstream is > unresponsiv
Re: Need help from Provenpackager
On 27. 03. 20 12:31, Artem Tim wrote: Hello! Lutris broken completely on F32 and many users asking what happens with package. Lutris always up to day in Fedora and i personally doesn't have any issues with it or all this time until this, but seems like this time ' bunnyapocalypse' just busy [1] to fix it and merge my PR [2]. Can we merge PR and build it for F32? It's already tested and it works. [1] https://src.fedoraproject.org/rpms/lutris/pull-request/1#comment-36580 [2] https://src.fedoraproject.org/rpms/lutris/pull-request/2 Done. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5481ea07eb -- 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
Please keep an eye on AskFedora as we approach F32 release
Hello, Just a general request: could more community folks please spend a few minutes a day to check AskFedora[1]. With the beta release, we're already seeing some users asking questions, which often turn out to be bugs. So, if the package maintainers in the community can please keep an eye on these, that'll be helpful. https://ask.fedoraproject.org -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: Need help from Provenpackager
Thank you! ___ 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: ELN Buildroot and Compose
On 3/27/20 1:32 PM, Miro Hrončok wrote: > The conditional approach will only allow this: %if 0%{?rhel} Version: 7.4.5 %else Version: 8.0.0~rc1 %endif (And I assume the rest of the spec file would need major %if/%else mess as well, because Brainfuck 8 is built with meson, while Brainfuck 7 is built with autotools. Or the implementation language changed from C to Rust...) And trust me, you don't want to maintain that. It is not maintainable. And it has problems like this: https://pagure.io/copr/copr/issue/1315 Ough. - Panu - ___ 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: ActionNotAllowed: policy violation (build_from_srpm)
Facepalm. ___ 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
Missing gtk2 library in workrave - build help
Hey, I am trying to bump version of package named workrave which was not originally added by me, I have been able to fix all the issues so far except one: https://kojipkgs.fedoraproject.org//work/tasks/7540/42797540/build.log error: File not found: /builddir/build/BUILDROOT/workrave-1.10.37-1.fc33.x86_64/usr/lib64/libworkrave-gtk2-private-1.0.so.* Here is the SPEC: https://src.fedoraproject.org/rpms/workrave/blob/master/f/workrave.spec I am trying to find out why autotools is not building this library, can you give me advice how to get there? Thanks. ___ 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: ELN Buildroot and Compose
Hi, Miro, On Fri, Mar 27, 2020 at 12:35 PM Miro Hrončok wrote: > > On 26. 03. 20 16:13, Miro Hrončok wrote: > > On 25. 03. 20 17:10, Miro Hrončok wrote: > >>> Finally, of the set of packages that we're going to be including, we > >>> anticipate around 200-300 of them will have distro conditionals that > >>> need investigation (with fewer needing actual modification). The ELN > >>> SIG will be doing this initial investigation and will provide guidance > >>> (and/or PRs) to affected packagers. > >> > >> My concerns still remain, although I am now not so scared that this will > >> alienate the community. Now the concern is more personal (= previously I > >> was > >> worried that everybody will be encouraged to use the conditionals, while > >> now > >> I'm mostly concerned they I will be encouraged to use the conditionals). > > > > Also, to make this more clear: > > > > I am not worried about the conditionals because I would need to maintain > > them. > > > > I am worried that "my" packages will be harder to co-maintain (or generally > > changed) by people from the community. > > > > As an example, I will know the RHEL 9 (10, 11...) plans and I can structure > > my > > specs accordingly. However if there is a passionate Fedora contributor who > > would > > like so submit a Pull Request for e.g. python-virtualenv to update it to a > > new > > fancy version that does things differently, they are not familiar about our > > RHEL > > plans and they would not be capable to wrap their head around such > > conditionals. > > They would also need to rebase any RHEL-only patches for this to work. At > > the > > end, they are more likely to just go away and not do it at all. > > Another example. In a corporate meeting with the product owners/managers, we > decide that the next major RHEL release will include Brainfuck 7 because it an > LTS release. Fedora rawhide is updated to Brainfuck 7 and everything is nice > and > fine. > > Later, Brainfuck 8 is released. The Fedora community wants this new version, > because it finally has a support for Brainloller and the Ook! stack depends on > this new feature. The Ook! stack is not planned to be in RHEL, so from RHEL > perspective, this new feature is not that important. But the Ook! SIG > obviously > wants this. > > The RHEL maintainer now needs to artificially block the Brainfuck 8 update > from > rawhide until next RHEL is branched (they probably cannot even share when this > is going to be with the Fedora community because NDA). This prevents the > "First" > foundation of Fedora (and TBH it also prevents "Friends", the RHEL maintainer > is > actively blocking the Ook SIG here by their (in)action). > > > The conditional approach will only allow this: > >%if 0%{?rhel} >Version: 7.4.5 >%else >Version: 8.0.0~rc1 >%endif > > (And I assume the rest of the spec file would need major %if/%else mess as > well, > because Brainfuck 8 is built with meson, while Brainfuck 7 is built with > autotools. Or the implementation language changed from C to Rust...) Thank you for bringing this example. I agree with your point that in case of choices like this, conditionals do not make sense. It is a branch. But this branch in my opinion has nothing to do with ELN. ELN is not RHEL. It is a development tool, which gives us a preview, so that we can plan the work better. We are not planning to release RHEL from ELN packages. Therefore ELN is all about the form, not the content. The goal of this project is to apply downstream form to Fedora Rawhide content and see what issues RHEL or downstream in general will have in the future. But the work itself doesn't always have to happen in Fedora Rawhide. ELN doesn't bring any new changes here, as you keep working with upstream and downstream the way you as package maintainer worked before. So while we may ask for some adjustments to Fedora spec files to fit into that EL-form, these adjustments are structural. And in the case you have described I am against branching not because I would like to have conditional instead, but because I don't want to fork Fedora Rawhide content into something else in ELN at all. I think the kind of branching you have described should happen somewhere down the line, in RHEL(CentOS Stream maybe). > And trust me, you don't want to maintain that. It is not maintainable. And it > has problems like this: >https://pagure.io/copr/copr/issue/1315 If I understand it correctly, this only illustrates the issue which may happen, not the example itself. As the reasons to have conditional in that particular spec file are not relevant to ELN. > Another approach is compat packages, but Brainfuck 8 is backwards compatible > with 7, so it brings no benefit for Fedora. > > Another approach is modularity, but the Ook! SIG doesn't want to use modules > because they want their Ook-based apps to be easily available to Fedora users. > > Sorry for going artificial with the example, but I didn't want you
Re: Missing gtk2 library in workrave - build help
On Fri, 27 Mar 2020, Lukas Zapletal wrote: Hey, I am trying to bump version of package named workrave which was not originally added by me, I have been able to fix all the issues so far except one: https://kojipkgs.fedoraproject.org//work/tasks/7540/42797540/build.log error: File not found: /builddir/build/BUILDROOT/workrave-1.10.37-1.fc33.x86_64/usr/lib64/libworkrave-gtk2-private-1.0.so.* Here is the SPEC: https://src.fedoraproject.org/rpms/workrave/blob/master/f/workrave.spec I am trying to find out why autotools is not building this library, can you give me advice how to get there? Thanks. Just from a casual glance, it appears that workrave now supports GTK3 for MATE and XFCE, so it may not build those GTK2 libraries any more if GTK3 is found. See: https://github.com/rcaelers/workrave/commit/49663e583549dccacd60461443cf3651ea0ac9a3 Scott ___ 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: ELN Buildroot and Compose
Dne 27. 03. 20 v 12:48 Aleksandra Fedorova napsal(a): > On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch wrote: >> >> Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a): >>> On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch wrote: Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): > On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: >> Dne 25. 03. 20 v 20:22 James Cassell napsal(a): >>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): > Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): >>> [snip] >> We can come up with guidelines, for example: >> >> 1) Try to find a way to resolve the issue without any conditionals >> first. >> >> There should be a reason why package X needs a dependency Y in Fedora >> and there should be a reason why it is a required dependency and not >> a >> recommended one. So why in that case downstream wants it differently? >> The first approach is just to talk through it. I can assume cases >> where downstream adds a dependency, as well as Fedora package >> removing >> them. >> >> Note that bloated dependency trees is a common problem for all binary >> distributions, it is not an "EL-thing" and we can work on that >> together. >> >> Nicolas has pointed out to another reason why we would get >> EL-conditionals: the outdated rpm stack in RHEL. But we don't have >> this problem with ELN, as we are building Rawhide, and rpm stack is >> going to be the Rawhide rpm stack as well. >> >> 2) Minimize and isolate the conditional, and track the reason. >> >> As ELN SIG we need to have a place where we collect known reasons for >> such conditionals. The overall goal is to reduce this set, not to >> grow >> indefinitely. As Stephen said we expect it to be about couple of >> hundred packages. We will be able to track each one of them. (We have >> rpminspect to run package diffs for us). >> >> 3) In complex cases - bring it to community and FESCo. >> >> We don't know what those complex cases might be, one of the goals is >> to find them. So we keep it as an option to bring individual case to >> a >> wider audience. To ask for help and to decide on it. >> > It seems there are missing real life examples of what we sometimes do > in > RHEL, so please see attached patch. This patch is coming from RHEL > version of the espeak-ng. Now somebody tell me what it does for what > purpose and which scenario from the above three should be applied > here. > > > Vít > And here is another example for the curious. >>> Both of these examples have to do with docs generation and trying to >>> reduce dependencies for that process. "Process the man page using >>> kramdown and remove the ronn dependency." >> The point is that these types of changes are not upstreamable. And the >> conditions would also be awful. Having these changes in separate branch >> would be much preferable IMO, because honestly, I would like every >> Fedora maintainer save from this cruft not because I would like to hide >> something, but for their own sanity. > I disagree actually. > > Disabling docs to reduce dependencies makes sense. And it is not a > RHEL-only thing. I am sorry but you have not passed the test. The test question was "Now somebody tell me what it does for what purpose and which scenario from the above three should be applied here." I would really appreciate, if you could pay attention to the two patches I post and what they do. Including careful analysis why they were applied and why they were not put into Fedora nor upstreamed. Hint: They don't disable any documentation. >>> You put two patches on the thread without context. I assumed that they >>> remove the fancy dependency needed to build the doc, and instead >>> create the doc in a more "old-school" ways. >>> It maybe a wrong assumption. It happens. >>> >>> Could you then explain the context, and what these patches actually do? >> >> There is much more to this. >> >> One think of course is to limit the dependencies. So therefore we didn't >> want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned >> upstream. If Ronn is abandoned upstream, the biggest problem is with its >> dependencies, which are officially deprecated upstream. While it is >> abandoned upstream, it is still valuable tool, which can easily generate >> man pages from markdown. So now on top of the question "should we have >> Ronn in RHEL or not" you have suddenly other issues: >> >> * Should we save upstr
Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There has been a lot of (really good!) discussion on the original proposal thread, but as it has grown too large to follow anymore, I'm restarting it. I have made numerous changes to the Change Proposal page to improve the scope of the proposal as well as clarify some of the questions that have come up repeatedly in the original thread. Please see the newly-updated https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose for more details[1]. == Summary == ELN is a new buildroot and compose process for Fedora that will take Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux compose. Feedback from this build, compose and integration testing will be provided to Fedora packagers so that they can see the potential impact of their changes on RHEL development. == Owner == * Name: [[User:Bookwar| Aleksandra Fedorova]] * Email: al...@bookwar.info * Name: [[User:Sgallagh | Stephen Gallagher]] * Email: sgall...@redhat.com [1] List of changes between the original and new versions: https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569655&oldid=569549 -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q 6DnLPiZt =42JI -END PGP SIGNATURE- ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-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: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 4:12 PM Stephen Gallagher wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > There has been a lot of (really good!) discussion on the original > proposal thread, but as it has grown too large to follow anymore, I'm > restarting it. I have made numerous changes to the Change Proposal > page to improve the scope of the proposal as well as clarify some of > the questions that have come up repeatedly in the original thread. I still think the only way to resolve conflicts (at least in some cases) will be to have the option of a separate eln branch in dist-git. Multiple people other than myself have voiced this opinion in the original thread, but this option is still not mentioned in the Change Proposal at all. Maybe my suggestions were not clear enough, so let me try again. Proposal: Use an (optional) eln branch in dist-git to resolve conflicts. ## Case 1: Improvements are applicable to both fedora and RHEL-next In this case, there should be no conflict and no need for %if spaghetti, changes can go into the master branch directly, without conditionals. The eln branch can either merge from master directly, or be a symbolic link to it (TIL about symbolic refs in git). ## Case 2: Changes can easily be expressed with %if conditionals and are clear to understand and easy to maintain In this case, I think some maintainers might accept such changes in rawhide. Same result as for Case 1. If maintainers do not accept those changes, "goto Case 3". ## Case 3: Changes are big and/or not accepted for master by the fedora maintainer In this case, conditional-based solutions are probably ugly and need special care. I assume any regular rawhide change will break ELN builds, since the conditionals will not be in effect for rawhide builds, and fedora packages will probably not care. Here, the eln branch can contain "downstream" changes, and it can be rebased on top of master/rawhide automatically. If an automatic rebase does not work, the ELN maintainer would have had to adapt the .spec file manually anyway, so it does not matter to them if this happens in the eln branch, or in the master branch (additionally, this kind of maintenance should be easier, since neither the fedora, nor the ELN maintainer has to deal with %if spaghetti!). Additionally, since you're only going to build a reduced package set for ELN, and I think you mentioned that you expect the number of packages which will require "bigger" changes to be small, this should scale very well. It would also give maintainers an "upgrade path" in the case the eln and master branches are initially the same, but would need to diverge later. I hope this makes it clearer why I think using branches as a conflict resolution tool - like for any other "release stream" - is more general, and superior to "[we] will discuss alternative approaches on an individual basis". Please at least seriously consider this suggestion - up until now, you only dismissed using branches with "this will not work / scale". Fabio > Please see the newly-updated > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > for more details[1]. > > == Summary == > ELN is a new buildroot and compose process for Fedora that will take > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux > compose. Feedback from this build, compose and integration testing > will be provided to Fedora packagers so that they can see the > potential impact of their changes on RHEL development. > > == Owner == > > * Name: [[User:Bookwar| Aleksandra Fedorova]] > * Email: al...@bookwar.info > * Name: [[User:Sgallagh | Stephen Gallagher]] > * Email: sgall...@redhat.com > > > > [1] List of changes between the original and new versions: > https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose&type=revision&diff=569655&oldid=569549 > -BEGIN PGP SIGNATURE- > > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo > bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K > jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ > 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D > 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z > Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ > mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg > lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED > pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q > 6DnLPiZt > =42JI > -END PGP SIGNATURE- > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-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/devel-an
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote: As Ben is on PTO, I'd like to present the System-Wide Change https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose [snip] It has taken me some time, but I have read through the entire thread in addition to the change proposal. The idea sounds really interesting to me and a lot of points have come up on the thread. I decided to group my responses together as this single email after reading through the entire thread to make it a bit easier to read (and to write). TL;DR -- I think this proposal should be broken up in to 2 proposals The turning point for me in the change proposal was the discussion of the RPM spec file macros and getting in to the mechanics of how ELN will work. It looks like a lot of other people had the same reaction because many of the responses get in to the technical details and for some questions, there are no answers yet. After thinking about it for a while, it would make sense to me to have ELN come up in multiple phases/proposals. Suggested Proposals: 1) ELN buildroot and install media In this proposal, I'd like to see the ELN buildroot defined, the Koji changes implemented, the automated builds implemented, and install media composes happening. The expectation here should be that it is rough around the edges. But doing this gives the community something to see, use, and discuss further when reviewing the next change proposals. We should have some community goals with this proposal to capture a list of EL vs. Fedora differences and how to address those per package and in the context of ELN. 2) ELN lifecycle This gets in to more of the mechanics of how ELN builds can be handled by the community. I do not think there is a one size fits all and we should give developers control over how best to handle this for the packages they maintain. The spec file macros, git branch ideas, inheritance, pull request workflow, what builds block what composes, who is responsible for ELN failures, and other expectations of package maintainers (both Fedora and RHEL) should be discussed here. This proposal is definitely the policy side of things, but I think it would be easier to talk about after #1 is done. Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called rhel-rawhide at one point), the ELN idea is one where the work is being targeted in the right place. As a Fedora contributor, I see RHEL as a customer and if we can make their work easier, I want to do that. As a RHEL package maintainer, I see Fedora as a place where I can make my job easier as a RHEL package maintainer. The more things we get right on the community side of things, the easier it is to produce RHEL. Various comments from reading the thread: * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el' instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro that covers all three of those. * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL major release. This should be ok in the community since Red Hat ultimately makes the decision to version RHEL. This is an engineering decision and I think it would help imply that ELN is _not_ meant for current RHEL. This also lets us entertain the idea of multiple ELN major versions concurrently should we ever want to do that. * There has to be a deliverable for ELN. What I would prefer is a live or install .iso. Something I can install on a spare system or in a virt guest. If it is only available as a buildroot in Koji, that becomes "black box" development which makes me less interested in working on it. * There were a lot of comments about build differences between RHEL and Fedora where certain features are disabled or build dependencies reduced (e.g., docs). I think this is something that the community could even discuss rearchitecting at the package level in Fedora. Things like vim-minimal, for instance. Having different packages built with different features enabled/disabled. Some of these things may be easiest handled with macros and others might be something we could handle by refactoring the packages themselves. * Regardless of the mechanics, there is going to be more work here. We all need to understand the expectations of the work required of a package maintainer and how best to coordinate with RHEL downstream. In many cases, the package maintainers between RHEL and Fedora are the same. But in many other cases they are not. As a community we should set some clear guidelines on where the responsibility lies and have the right communication workflow in place to make sure that's easy for everyone. * On that same note, RHEL package maintainers should have an expectation to co-maintain the corresponding package(s) in Fedora if they do not already. Most of my comments here are on the mechanic
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
Stephen Gallagher writes: > Please see the newly-updated > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > for more details[1]. This page states: > The fix will be done via a pull request that states a time limit. We > want the regular maintainers to see / comment / commit, but we also > don't want things to stall for months and get forgotten about. What happens at the end of the time limit? Do you ProvenPackager the PR in? > What if I do not want to have %if's in my spec files? > > As long as your package builds in ELN then just maintain your package > like normal. If there is a build failure, the ELN SIG may provide a PR > as described above or will discuss alternative approaches on an > individual basis with you. So... if we don't want %ifs in our spec files, the ELN SIG will provide us some? > Post build result to Fedora Messaging, so that it appears in Bodhi and > can be used as a gating test. So regular package updates are going to be gated on ELN. This doesn't sound like something non-RHEL maintainers will want. What am I missing? > It is under discussion whether this snapshot will have its own > installation media. For now the preferred way to test ELN composes > would be to use standard Fedora Rawhide images and then include ELN as > an additional repository. Is there a dnf change that goes with this to prefer ELN content, then? > ELN artifacts will be made available for testing and development > purposes, but we will not be shipping any content produced from ELN > directly to the general public (such as on the standard mirror network > or via getfedora.org). > > ... > > Though it is a System-Wide Change it has no user-facing component. We > may announce it through other channels. I'm confused. This is going to be installable and testable, but has no user-facing component? What's a user-facing component then? Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 32 compose report: 20200327.n.0 changes
OLD: Fedora-32-20200326.n.0 NEW: Fedora-32-20200327.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = 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: proxying fedora mirrors with HTTPS
On Thu, Mar 26, 2020 at 10:54:25AM -0600, Ken Dreyer wrote: > I see pykickstart supports https URLs for --proxy, so I think I can > just do --proxy https://squid.example.com:3128 ? > > I don't understand how I would get the installer to trust my custom CA > to communicate with the HTTPS proxy, though. You should be able to use the new --sslcacert, etc. arguments. https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#url There has been some discussion about replacing them with a way to specify a full repo config file, but that hasn't gone anywhere yet so the arguments should be around at least until there is a suitable replacement for them. -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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: Coq build issues in F32
On Thu, Mar 26, 2020 at 10:28 AM Richard W.M. Jones wrote: > I don't know, now I can't even get the ‘fedpkg local’ to reproduce it :-( > > Jerry, I suggest this bug is real, but is also likely to be a bug in > Coq (most likely) or the OCaml runtime, possibly in the Weak module. > You might have more luck asking the upstream developers for help. > > As for what to do about Fedora 32, how about disabling _smp_mflags, on > the basis that it might be load-related? That should at least reduce > the non-determinism. Okay, I will give that a try. I'm worried that even if I get a "good" build, that it's going to explode on the hapless Fedora users who install it. Thank you for all the work you put into this, Richard. I appreciate the investigation. I'll keep poking at it, too. -- 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > Stephen Gallagher writes: > > > Please see the newly-updated > > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > > for more details[1]. > > This page states: [..] > > Post build result to Fedora Messaging, so that it appears in Bodhi and > > can be used as a gating test. > > So regular package updates are going to be gated on ELN. This doesn't > sound like something non-RHEL maintainers will want. What am I missing? "Can be used as a gating test" is different from "will be used for gating". What this line says is that the results from the tests will flow in with all the other test results and as very every tests at the moment, the packager maintainers can chose to gate on some tests or others, or chose not to gate their packages at all. Pierre 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: Coq build issues in F32
On Wed, Mar 25, 2020 at 10:21 PM Stephen J. Turnbull wrote: > Hi Jerry! Long time no see. Hi Stephen! It's good to hear from yet another person I've worked with via network for years. I think Richard addressed most of the points you raised. > Where is the segfault? Is it in coqc or is it in the generated code > or is it in the OCaml compiler or is it somewhere else? It's in coqc. Richard's evidence seems to point to garbage collector involvement, with weak references possibly playing a role. > Stay healthy! You, too, and likewise for everybody in the Fedora community. -- 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:03 AM Jerry James wrote: > Okay, I will give that a try. Except I can't. We're already not using %_smp_mflags. Ugh. -- 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:15:01AM -0600, Jerry James wrote: > On Fri, Mar 27, 2020 at 11:03 AM Jerry James wrote: > > Okay, I will give that a try. > > Except I can't. We're already not using %_smp_mflags. Ugh. We are. Did you trying putting '%global _smp_mflags -j1' somewhere near the top of the spec file? 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:30 AM Zbigniew Jędrzejewski-Szmek wrote: > We are. Did you trying putting '%global _smp_mflags -j1' somewhere > near the top of the spec file? We are? Where? The spec file does this to build: make world VERBOSE=1 -- 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: Coq build issues in F32
On Thu, Mar 26, 2020 at 10:28 AM Richard W.M. Jones wrote: > Jerry, I suggest this bug is real, but is also likely to be a bug in > Coq (most likely) or the OCaml runtime, possibly in the Weak module. > You might have more luck asking the upstream developers for help. Coq issue: https://github.com/coq/coq/issues/11939 I looked around in the ocaml issue tracker and found a possibility: https://github.com/ocaml/ocaml/issues/9391 Coq uses ephemerons. -- 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-20200327.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 8/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200326.n.0): ID: 558478 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/558478 ID: 558480 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/558480 ID: 558514 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/558514 ID: 558595 Test: x86_64 universal install_simple_free_space URL: https://openqa.fedoraproject.org/tests/558595 ID: 558601 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/558601 ID: 558613 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/558613 Old failures (same test failed in Fedora-Rawhide-20200326.n.0): ID: 558481 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/558481 ID: 558495 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/558495 ID: 558530 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/558530 Soft failed openQA tests: 21/171 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20200326.n.0): ID: 558548 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/558548 ID: 558574 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/558574 Old soft failures (same test soft failed in Fedora-Rawhide-20200326.n.0): ID: 558451 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558451 ID: 558452 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/558452 ID: 558456 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/558456 ID: 558460 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558460 ID: 558463 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/558463 ID: 558464 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/558464 ID: 558486 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/558486 ID: 558509 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/558509 ID: 558511 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/558511 ID: 558543 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/558543 ID: 558565 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/558565 ID: 558575 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/558575 ID: 558584 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/558584 ID: 558593 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/558593 ID: 558609 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/558609 ID: 558617 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/558617 ID: 558618 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/558618 ID: 558621 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/558621 ID: 558623 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/558623 Passed openQA tests: 128/171 (x86_64) New passes (same test not passed in Fedora-Rawhide-20200326.n.0): ID: 558532 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558532 ID: 558541 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/558541 ID: 558596 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/558596 Skipped gating openQA tests: 4/171 (x86_64) New skipped gating tests (same test not skipped in Fedora-Rawhide-20200326.n.0): ID: 558522 Test: x86_64 KDE-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/558522 ID: 558523 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://open
Fedora-32-20200327.n.0 compose check report
No missing expected images. Failed openQA tests: 3/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-32-20200326.n.0): ID: 558825 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/558825 ID: 558944 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/558944 Old failures (same test failed in Fedora-32-20200326.n.0): ID: 558851 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/558851 ID: 558864 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/558864 Soft failed openQA tests: 19/171 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-32-20200326.n.0): ID: 558785 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558785 ID: 558786 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/558786 ID: 558790 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/558790 ID: 558794 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558794 ID: 558797 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/558797 ID: 558798 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/558798 ID: 558820 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/558820 ID: 558843 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/558843 ID: 558845 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/558845 ID: 558877 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/558877 ID: 558899 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/558899 ID: 558909 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/558909 ID: 558918 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/558918 ID: 558927 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/558927 ID: 558943 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/558943 ID: 558951 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/558951 ID: 558952 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/558952 ID: 558955 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/558955 ID: 558957 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/558957 Passed openQA tests: 149/171 (x86_64) New passes (same test not passed in Fedora-32-20200326.n.0): ID: 558823 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/558823 Skipped non-gating openQA tests: 1 of 173 Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.01 to 0.24 Previous test data: https://openqa.fedoraproject.org/tests/558087#downloads Current test data: https://openqa.fedoraproject.org/tests/558828#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.57 to 0.83 Average CPU usage changed from 15.48571429 to 4.51428571 Previous test data: https://openqa.fedoraproject.org/tests/558089#downloads Current test data: https://openqa.fedoraproject.org/tests/558830#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 4 MiB to 8 MiB Previous test data: https://openqa.fedoraproject.org/tests/558090#downloads Current test data: https://openqa.fedoraproject.org/tests/558831#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 1.46 to 1.18 Average CPU usage changed from 39.62857143 to 29.05714286 Previous test data: https://openqa.fedoraproject.org/tests/558106#downloads Current test data: https://openqa.fedoraproject.org/tests/558847#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: System load changed from 1.06 to 1.20 Previous test data: https://openqa.fedoraproject.org/tests/558107#downloads Current test data: https://openqa.fedoraproject.org/tests/558848#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Used swap changed from 9 MiB to 8 MiB Previous test data: https://openqa.fedoraproje
Re: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:36:38AM -0600, Jerry James wrote: > On Fri, Mar 27, 2020 at 11:30 AM Zbigniew Jędrzejewski-Szmek > wrote: > > We are. Did you trying putting '%global _smp_mflags -j1' somewhere > > near the top of the spec file? > > We are? Where? That is what the packaging guidelines say [1]: > Whenever possible, invocations of make should be done as > %make_build (which is defined as $ rpmbuild --showrc |grep make_build make_build %{__make} %{_make_output_sync} %{?_smp_mflags} %{_make_verbose}). [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_parallel_make > The spec file does this to build: > > make world VERBOSE=1 So it seems that this particular Makefile enables parallelization internally. (make defaults -j1 unless told otherwise). But it should be possible to somehow disable it wherever it is enabled. 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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote: > > On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote: > >As Ben is on PTO, I'd like to present the System-Wide Change > > > >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > [snip] > > It has taken me some time, but I have read through the entire thread in > addition to the change proposal. The idea sounds really interesting to me and > a lot of points have come up on the thread. I decided to group my responses > together as this single email after reading through the entire thread to make > it a bit easier to read (and to write). > > TL;DR -- I think this proposal should be broken up in to 2 proposals > > The turning point for me in the change proposal was the discussion of the RPM > spec file macros and getting in to the mechanics of how ELN will work. It > looks like a lot of other people had the same reaction because many of the > responses get in to the technical details and for some questions, there are no > answers yet. After thinking about it for a while, it would make sense to me > to have ELN come up in multiple phases/proposals. > > Suggested Proposals: > > 1) ELN buildroot and install media > > In this proposal, I'd like to see the ELN buildroot defined, the Koji > changes implemented, the automated builds implemented, and install media > composes happening. > > The expectation here should be that it is rough around the edges. But > doing this gives the community something to see, use, and discuss further > when reviewing the next change proposals. > > We should have some community goals with this proposal to capture a list > of > EL vs. Fedora differences and how to address those per package and in the > context of ELN. > > 2) ELN lifecycle > > This gets in to more of the mechanics of how ELN builds can be handled by > the community. I do not think there is a one size fits all and we should > give developers control over how best to handle this for the packages they > maintain. > > The spec file macros, git branch ideas, inheritance, pull request > workflow, > what builds block what composes, who is responsible for ELN failures, and > other expectations of package maintainers (both Fedora and RHEL) should be > discussed here. This proposal is definitely the policy side of things, > but > I think it would be easier to talk about after #1 is done. > > Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called > rhel-rawhide at one point), the ELN idea is one where the work is being > targeted in the right place. As a Fedora contributor, I see RHEL as a > customer and if we can make their work easier, I want to do that. As a RHEL > package maintainer, I see Fedora as a place where I can make my job easier as > a RHEL package maintainer. The more things we get right on the community side > of things, the easier it is to produce RHEL. > > Various comments from reading the thread: > > * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el' >instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro >that covers all three of those. > The %{?rhel} macro name currently exists and is in use in some packages as I recall. > * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL >major release. This should be ok in the community since Red Hat ultimately >makes the decision to version RHEL. This is an engineering decision and I >think it would help imply that ELN is _not_ meant for current RHEL. This >also lets us entertain the idea of multiple ELN major versions concurrently >should we ever want to do that. > I rather equate this to RHELhide, it should be evolving. Once N is branched (CentOS?) and moving on, this is N+1. This is the rolling development location. ___ 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: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote: On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote: On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote: >As Ben is on PTO, I'd like to present the System-Wide Change > >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose [snip] It has taken me some time, but I have read through the entire thread in addition to the change proposal. The idea sounds really interesting to me and a lot of points have come up on the thread. I decided to group my responses together as this single email after reading through the entire thread to make it a bit easier to read (and to write). TL;DR -- I think this proposal should be broken up in to 2 proposals The turning point for me in the change proposal was the discussion of the RPM spec file macros and getting in to the mechanics of how ELN will work. It looks like a lot of other people had the same reaction because many of the responses get in to the technical details and for some questions, there are no answers yet. After thinking about it for a while, it would make sense to me to have ELN come up in multiple phases/proposals. Suggested Proposals: 1) ELN buildroot and install media In this proposal, I'd like to see the ELN buildroot defined, the Koji changes implemented, the automated builds implemented, and install media composes happening. The expectation here should be that it is rough around the edges. But doing this gives the community something to see, use, and discuss further when reviewing the next change proposals. We should have some community goals with this proposal to capture a list of EL vs. Fedora differences and how to address those per package and in the context of ELN. 2) ELN lifecycle This gets in to more of the mechanics of how ELN builds can be handled by the community. I do not think there is a one size fits all and we should give developers control over how best to handle this for the packages they maintain. The spec file macros, git branch ideas, inheritance, pull request workflow, what builds block what composes, who is responsible for ELN failures, and other expectations of package maintainers (both Fedora and RHEL) should be discussed here. This proposal is definitely the policy side of things, but I think it would be easier to talk about after #1 is done. Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called rhel-rawhide at one point), the ELN idea is one where the work is being targeted in the right place. As a Fedora contributor, I see RHEL as a customer and if we can make their work easier, I want to do that. As a RHEL package maintainer, I see Fedora as a place where I can make my job easier as a RHEL package maintainer. The more things we get right on the community side of things, the easier it is to produce RHEL. Various comments from reading the thread: * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el' instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro that covers all three of those. The %{?rhel} macro name currently exists and is in use in some packages as I recall. Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work. I would prefer a new macro for the ELN work to distinguish it from the existing macros. * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL major release. This should be ok in the community since Red Hat ultimately makes the decision to version RHEL. This is an engineering decision and I think it would help imply that ELN is _not_ meant for current RHEL. This also lets us entertain the idea of multiple ELN major versions concurrently should we ever want to do that. I rather equate this to RHELhide, it should be evolving. Once N is branched (CentOS?) and moving on, this is N+1. This is the rolling development location. I agree. The 'N' value seen in this dist tag should always be greater than the latest major version we see for RHEL and CentOS. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ 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: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 2:09 PM David Cantrell wrote: > > On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote: > >On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote: > >> > >> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote: > >> >As Ben is on PTO, I'd like to present the System-Wide Change > >> > > >> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > >> [snip] > >> > >> It has taken me some time, but I have read through the entire thread in > >> addition to the change proposal. The idea sounds really interesting to me > >> and > >> a lot of points have come up on the thread. I decided to group my > >> responses > >> together as this single email after reading through the entire thread to > >> make > >> it a bit easier to read (and to write). > >> > >> TL;DR -- I think this proposal should be broken up in to 2 proposals > >> > >> The turning point for me in the change proposal was the discussion of the > >> RPM > >> spec file macros and getting in to the mechanics of how ELN will work. It > >> looks like a lot of other people had the same reaction because many of the > >> responses get in to the technical details and for some questions, there > >> are no > >> answers yet. After thinking about it for a while, it would make sense to > >> me > >> to have ELN come up in multiple phases/proposals. > >> > >> Suggested Proposals: > >> > >> 1) ELN buildroot and install media > >> > >> In this proposal, I'd like to see the ELN buildroot defined, the Koji > >> changes implemented, the automated builds implemented, and install > >> media > >> composes happening. > >> > >> The expectation here should be that it is rough around the edges. But > >> doing this gives the community something to see, use, and discuss > >> further > >> when reviewing the next change proposals. > >> > >> We should have some community goals with this proposal to capture a > >> list of > >> EL vs. Fedora differences and how to address those per package and in > >> the > >> context of ELN. > >> > >> 2) ELN lifecycle > >> > >> This gets in to more of the mechanics of how ELN builds can be handled > >> by > >> the community. I do not think there is a one size fits all and we > >> should > >> give developers control over how best to handle this for the packages > >> they > >> maintain. > >> > >> The spec file macros, git branch ideas, inheritance, pull request > >> workflow, > >> what builds block what composes, who is responsible for ELN failures, > >> and > >> other expectations of package maintainers (both Fedora and RHEL) > >> should be > >> discussed here. This proposal is definitely the policy side of > >> things, but > >> I think it would be easier to talk about after #1 is done. > >> > >> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even > >> called > >> rhel-rawhide at one point), the ELN idea is one where the work is being > >> targeted in the right place. As a Fedora contributor, I see RHEL as a > >> customer and if we can make their work easier, I want to do that. As a > >> RHEL > >> package maintainer, I see Fedora as a place where I can make my job easier > >> as > >> a RHEL package maintainer. The more things we get right on the community > >> side > >> of things, the easier it is to produce RHEL. > >> > >> Various comments from reading the thread: > >> > >> * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el' > >>instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' > >> macro > >>that covers all three of those. > >> > > > >The %{?rhel} macro name currently exists and is in use in some > >packages as I recall. > > Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work. > I would prefer a new macro for the ELN work to distinguish it from the > existing macros. > > >> * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL > >>major release. This should be ok in the community since Red Hat > >> ultimately > >>makes the decision to version RHEL. This is an engineering decision > >> and I > >>think it would help imply that ELN is _not_ meant for current RHEL. > >> This > >>also lets us entertain the idea of multiple ELN major versions > >> concurrently > >>should we ever want to do that. > >> > > > >I rather equate this to RHELhide, it should be evolving. Once N is > >branched (CentOS?) and moving on, this is N+1. This is the rolling > >development location. > > I agree. The 'N' value seen in this dist tag should always be greater than > the latest major version we see for RHEL and CentOS. Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of this seems it should carry no number, similar to the rawhide it is inheriting from. Let them deal with numbers in CentOS and RHEL. Justin ___ devel mai
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On 27. 03. 20 20:20, Justin Forbes wrote: Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of this seems it should carry no number, similar to the rawhide it is inheriting from. Let them deal with numbers in CentOS and RHEL. But rawhide also has a number (currently 33). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 11:07:41AM -0400, Stephen Gallagher wrote: > == Summary == > ELN is a new buildroot and compose process for Fedora that will take > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux > compose. Feedback from this build, compose and integration testing > will be provided to Fedora packagers so that they can see the > potential impact of their changes on RHEL development. Thanks, the new page is much better. Esp. this new summary is massively better. Some specific things which are still unclear: > Setup automation to trigger new ELN build every time there is a new > update submitted to Fedora Rawhide. Does "update" in this context mean the automatic bodhi update used for gating? What does "submitted" mean — the time when the update is requested, on when the update is pushed to rawhide, or ... ? > Post build result to Fedora Messaging, so that it appears in Bodhi > and can be used as a gating test Continuing with the previous question, is the "gating test" for the original rawhide update? > The SIG will [...] maintain infrastructure required to build packages and > composes; Does this mean that some new person will join releng? > we will not be shipping any content produced from ELN directly to > the general public (such as on the standard mirror network Hmm, so those packages will be pulled directly from koji? Is the additional load acceptable? > Contingency mechanism: If this effort doesn’t land in Fedora 33 we > review it and decide whether it needs to be moved further to Fedora > 34 or be cancelled. OK, and what about the case where it is enabled, and then during the way it turns out to be too much hassle? Is there some sunset procedure planned? > What if there is a feature RHEL wants in a package, how will that go in? > That is not in the scope of ELN. Does "not in scope" mean that the question is not answered, or does it mean that ELN is not relevant to the question? The latter seems a bit impossible. ELN is all about making rawhide packages more like the packages in RHEL, and this naturally means adding and removing features or changing dependencies or configuration falls into the scope of ELN. I.e. if I'm a RHEL maintainer, opening a PR against Fedora dist-git with a bunch of '%if %{eln}' conditionals or not seems the most straightforward way to push towards having a feature in RHEL... 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > Stephen Gallagher writes: > > It is under discussion whether this snapshot will have its own > > installation media. For now the preferred way to test ELN composes > > would be to use standard Fedora Rawhide images and then include ELN as > > an additional repository. > > Is there a dnf change that goes with this to prefer ELN content, then? Yeah, that's something I was trying to figure out too. As discussed before, for rpm '.eln < .fc33', so if the same package is available from both sources, the rawhide one will win. > > ELN artifacts will be made available for testing and development > > purposes, but we will not be shipping any content produced from ELN > > directly to the general public (such as on the standard mirror network > > or via getfedora.org). > > ... > > > > Though it is a System-Wide Change it has no user-facing component. We > > may announce it through other channels. > > I'm confused. This is going to be installable and testable, but has no > user-facing component? What's a user-facing component then? FWIW, I think it's OK to have to first install rawhide and then to enable eln repos on top to have a working installation. Or to do 'dnf --installroot'. Building an an installer image and such doesn't seem necessary, esp. in the beginning. 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 3:42 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > > Stephen Gallagher writes: > > > It is under discussion whether this snapshot will have its own > > > installation media. For now the preferred way to test ELN composes > > > would be to use standard Fedora Rawhide images and then include ELN as > > > an additional repository. > > > > Is there a dnf change that goes with this to prefer ELN content, then? > > Yeah, that's something I was trying to figure out too. As discussed > before, for rpm '.eln < .fc33', so if the same package is available > from both sources, the rawhide one will win. > If there was a "dnf distro-sync --prefer-repo=foo" kind of feature, maybe that'd work? Maybe repo priorities? I'm not sure how this would work... > > > ELN artifacts will be made available for testing and development > > > purposes, but we will not be shipping any content produced from ELN > > > directly to the general public (such as on the standard mirror network > > > or via getfedora.org). > > > ... > > > > > > Though it is a System-Wide Change it has no user-facing component. We > > > may announce it through other channels. > > > > I'm confused. This is going to be installable and testable, but has no > > user-facing component? What's a user-facing component then? > > FWIW, I think it's OK to have to first install rawhide and then to > enable eln repos on top to have a working installation. Or to do > 'dnf --installroot'. Building an an installer image and such doesn't > seem necessary, esp. in the beginning. > I would argue that it is necessary, if it's intended to be as interesting and useful as this Change proposes. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20200327.n.0 changes
OLD: Fedora-Rawhide-20200326.n.0 NEW: Fedora-Rawhide-20200327.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 20 Dropped packages:1 Upgraded packages: 88 Downgraded packages: 0 Size of added packages: 1.34 GiB Size of dropped packages:6.87 MiB Size of upgraded packages: 2.62 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 82.25 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: algobox-1.0.3-1.fc33 Summary: Algorithmic software RPMs:algobox Size:2.77 MiB Package: ghc-8.10.1-93.module_f33+8393+d9235bfb Summary: Glasgow Haskell Compiler RPMs:ghc ghc-Cabal ghc-Cabal-devel ghc-Cabal-doc ghc-Cabal-prof ghc-array ghc-array-devel ghc-array-doc ghc-array-prof ghc-base ghc-base-devel ghc-base-doc ghc-base-prof ghc-binary ghc-binary-devel ghc-binary-doc ghc-binary-prof ghc-bytestring ghc-bytestring-devel ghc-bytestring-doc ghc-bytestring-prof ghc-compiler ghc-containers ghc-containers-devel ghc-containers-doc ghc-containers-prof ghc-deepseq ghc-deepseq-devel ghc-deepseq-doc ghc-deepseq-prof ghc-devel ghc-directory ghc-directory-devel ghc-directory-doc ghc-directory-prof ghc-doc ghc-doc-index ghc-exceptions ghc-exceptions-devel ghc-exceptions-doc ghc-exceptions-prof ghc-filepath ghc-filepath-devel ghc-filepath-doc ghc-filepath-prof ghc-ghc ghc-ghc-boot ghc-ghc-boot-devel ghc-ghc-boot-doc ghc-ghc-boot-prof ghc-ghc-boot-th ghc-ghc-boot-th-devel ghc-ghc-boot-th-doc ghc-ghc-boot-th-prof ghc-ghc-compact ghc-ghc-compact-devel ghc-ghc-compact-doc ghc-ghc-compact-prof ghc-ghc-devel ghc-ghc-doc ghc-ghc-heap ghc-ghc-heap-devel ghc-ghc-heap-doc ghc-ghc-heap-prof ghc-ghc-prof ghc-ghci ghc-ghci-devel ghc-ghci-doc ghc-ghci-prof ghc-haskeline ghc-haskeline-devel ghc-haskeline-doc ghc-haskeline-prof ghc-hpc ghc-hpc-devel ghc-hpc-doc ghc-hpc-prof ghc-libiserv ghc-libiserv-devel ghc-libiserv-doc ghc-libiserv-prof ghc-manual ghc-mtl ghc-mtl-devel ghc-mtl-doc ghc-mtl-prof ghc-parsec ghc-parsec-devel ghc-parsec-doc ghc-parsec-prof ghc-pretty ghc-pretty-devel ghc-pretty-doc ghc-pretty-prof ghc-process ghc-process-devel ghc-process-doc ghc-process-prof ghc-prof ghc-stm ghc-stm-devel ghc-stm-doc ghc-stm-prof ghc-template-haskell ghc-template-haskell-devel ghc-template-haskell-doc ghc-template-haskell-prof ghc-terminfo ghc-terminfo-devel ghc-terminfo-doc ghc-terminfo-prof ghc-text ghc-text-devel ghc-text-doc ghc-text-prof ghc-time ghc-time-devel ghc-time-doc ghc-time-prof ghc-transformers ghc-transformers-devel ghc-transformers-doc ghc-transformers-prof ghc-unix ghc-unix-devel ghc-unix-doc ghc-unix-prof ghc-xhtml ghc-xhtml-devel ghc-xhtml-doc ghc-xhtml-prof Size:1.25 GiB Package: gnome-applets-3.36.1-1.fc33 Summary: Small applications for the GNOME Flashback panel RPMs:gnome-applets Size:40.19 MiB Package: gnome-flashback-3.36.0-1.fc33 Summary: GNOME Flashback session RPMs:gnome-flashback Size:2.76 MiB Package: gnome-panel-3.36.0-1.fc33 Summary: GNOME Flashback panel RPMs:gnome-panel gnome-panel-devel gnome-panel-doc gnome-panel-libs Size:8.44 MiB Package: goloris-0-0.1.20200326gita59fafb.fc33 Summary: Slowloris for NGINX DoS RPMs:golang-github-valyala-goloris-devel goloris Size:7.14 MiB Package: goverlay-0.2.3-1.fc33 Summary: Graphical UI to help manage Linux overlays RPMs:goverlay Size:8.83 MiB Package: home-assistant-cli-0.8.0-2.fc33 Summary: Command-line tool for Home Assistant RPMs:home-assistant-cli Size:79.54 KiB Package: libqmatrixclient-0.5.2-1.fc33 Summary: Qt5 library to write cross-platform clients for Matrix RPMs:libqmatrixclient libqmatrixclient-devel Size:3.41 MiB Package: non-daw-1.2.0-19.20200307gitbbe8386.fc33 Summary: A digital audio workstation for JACK RPMs:non-daw non-mixer non-mixer-doc non-sequencer non-sequencer-doc non-session-manager non-session-manager-doc Size:16.96 MiB Package: python-asysocks-0.0.2-1.fc33 Summary: Socks5/Socks4 client and server library RPMs:python3-asysocks Size:33.69 KiB Package: python-bibtexparser-1.1.0-2.fc33 Summary: A BibTeX parsing library RPMs:python-bibtexparser-doc python3-bibtexparser Size:317.08 KiB Package: python-friendlyloris-1.0.1-1.fc33 Summary: A Slow Loris package for Python RPMs:python3-friendlyloris Size:15.16 KiB Package: python-makeelf-0.3.2-1.fc33 Summary: ELF reader-writer library RPMs:python3-makeelf Size:56.95 KiB Package: python-readability-lxml-0.7.1-2.20200326gitede4d01.fc33 Summary: Fast html to text parser (article readability tool) RPMs:python3-readability-lxml Size:40.23 KiB Package: python-registry-1.3.1-2.fc33 Summary: Read access to Windows Registry files RPMs:python3-registry Size:45.52 KiB Package: python-requests-pkcs12-1.7-1.fc33 Summary: Add PKCS12 support to the requests library RPMs:python3-requests-pkcs12
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 2:42 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > > Stephen Gallagher writes: > > > It is under discussion whether this snapshot will have its own > > > installation media. For now the preferred way to test ELN composes > > > would be to use standard Fedora Rawhide images and then include ELN as > > > an additional repository. > > > > Is there a dnf change that goes with this to prefer ELN content, then? > > Yeah, that's something I was trying to figure out too. As discussed > before, for rpm '.eln < .fc33', so if the same package is available > from both sources, the rawhide one will win. > Can this be handled with the existing 'priority' directive in repository config files? ___ 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: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)
On Fri, Mar 27, 2020 at 1:56 AM Zbigniew Jędrzejewski-Szmek wrote: > > Where would mock be executing from? The same filesystem it is modifying? > Somehow it seems that this doesn't change much, but just brings > in another layer. Or will a complete copy of the system be made in > memory to execute the upgrade tools from? Snapshot it. If it doesn't work, throw away the snapshot. > > Let's consider a concrete example that came up recently: grub wants to > rewrite something in the bootloader area on disk to help upgrades from > very old installations. In current "offline upgrade" scheme, the upgrade > tools are running on the real system, with udev active. They can query > and touch hardware, can see all the disks as they are, etc. If we > went through mock, it'd be running in an nspawn environment w/o access > to hardware. This particular example affected BIOS GRUB, where the embedded "core.img" isn't ever updated. i.e. grub-install is called once at original install time, and never again. I'm not certain whether installation is, or could be, atomic. On UEFI, the "core.img" makes up most of grubx64.efi, and it's updated anytime grub2-efi-x64 package is updated. Not only system upgrades. I don't know how RPM replaces it. But since it's on FAT, atomicity is limited to the VFS operation. There is a window where it could be interrupted and things wouldn't be in either working state. > (Something like os-tree's atomic replacement of things, that's of > course a completely different story. But so far we're talking about > traditional systems.) Perhaps ironically, rpm-ostree + UEFI systems, don't have the bootloader updated. And it doesn't really want to be responsible for it. GRUB is very cool in many ways, but having a strategy for keeping itself up to date is not one of them; so far upstream GRUB development considers this a distribution problem, not a problem in search of a generic solution. One idea is a service that ensures boot related things are in the proper state, including mirroring the EFI system partition for raid1 sysroot setups. It's not decided if it should be fwupd function or made into a separate boot daemon. -- Chris Murphy ___ 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:15:01AM -0600, Jerry James wrote: > On Fri, Mar 27, 2020 at 11:03 AM Jerry James wrote: > > Okay, I will give that a try. > > Except I can't. We're already not using %_smp_mflags. Ugh. I realized that my build machine has MAKEFLAGS=-j24 which is why it's building coq in parallel (and quickly). So it seems like you could be using _smp_mflags. Another thing I tried today was enabling debugging in the GC (see patch below). However it also didn't find any problems, so I'm still at a loss. Rich. diff --git a/coq.spec b/coq.spec index df2a847..1e590cc 100644 --- a/coq.spec +++ b/coq.spec @@ -164,6 +164,10 @@ done %global opt_option -bytecode-compiler yes -byte-only -coqide byte %endif +# Use debug runtime. +sed -i 's/^\(OCAMLC :=.*\)/\1 -runtime-variant d/' Makefile.build +sed -i 's/^\(OCAMLOPT :=.*\)/\1 -runtime-variant d/' Makefile.build + %global coqdocdir %{?_pkgdocdir}%{!?_pkgdocdir:%{_docdir}/coq-%{version}} %global coqdatadir %{_libdir}/coq -- 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
Re: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:54:44AM -0600, Jerry James wrote: > On Thu, Mar 26, 2020 at 10:28 AM Richard W.M. Jones wrote: > > Jerry, I suggest this bug is real, but is also likely to be a bug in > > Coq (most likely) or the OCaml runtime, possibly in the Weak module. > > You might have more luck asking the upstream developers for help. > > Coq issue: https://github.com/coq/coq/issues/11939 > > I looked around in the ocaml issue tracker and found a possibility: > > https://github.com/ocaml/ocaml/issues/9391 > > Coq uses ephemerons. Yup, and the stack trace shows the failure happening when creating an ephemeron. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 02:20:29PM -0500, Justin Forbes wrote: On Fri, Mar 27, 2020 at 2:09 PM David Cantrell wrote: On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote: >On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote: >> >> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote: >> >As Ben is on PTO, I'd like to present the System-Wide Change >> > >> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose >> [snip] >> >> It has taken me some time, but I have read through the entire thread in >> addition to the change proposal. The idea sounds really interesting to me and >> a lot of points have come up on the thread. I decided to group my responses >> together as this single email after reading through the entire thread to make >> it a bit easier to read (and to write). >> >> TL;DR -- I think this proposal should be broken up in to 2 proposals >> >> The turning point for me in the change proposal was the discussion of the RPM >> spec file macros and getting in to the mechanics of how ELN will work. It >> looks like a lot of other people had the same reaction because many of the >> responses get in to the technical details and for some questions, there are no >> answers yet. After thinking about it for a while, it would make sense to me >> to have ELN come up in multiple phases/proposals. >> >> Suggested Proposals: >> >> 1) ELN buildroot and install media >> >> In this proposal, I'd like to see the ELN buildroot defined, the Koji >> changes implemented, the automated builds implemented, and install media >> composes happening. >> >> The expectation here should be that it is rough around the edges. But >> doing this gives the community something to see, use, and discuss further >> when reviewing the next change proposals. >> >> We should have some community goals with this proposal to capture a list of >> EL vs. Fedora differences and how to address those per package and in the >> context of ELN. >> >> 2) ELN lifecycle >> >> This gets in to more of the mechanics of how ELN builds can be handled by >> the community. I do not think there is a one size fits all and we should >> give developers control over how best to handle this for the packages they >> maintain. >> >> The spec file macros, git branch ideas, inheritance, pull request workflow, >> what builds block what composes, who is responsible for ELN failures, and >> other expectations of package maintainers (both Fedora and RHEL) should be >> discussed here. This proposal is definitely the policy side of things, but >> I think it would be easier to talk about after #1 is done. >> >> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called >> rhel-rawhide at one point), the ELN idea is one where the work is being >> targeted in the right place. As a Fedora contributor, I see RHEL as a >> customer and if we can make their work easier, I want to do that. As a RHEL >> package maintainer, I see Fedora as a place where I can make my job easier as >> a RHEL package maintainer. The more things we get right on the community side >> of things, the easier it is to produce RHEL. >> >> Various comments from reading the thread: >> >> * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el' >>instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro >>that covers all three of those. >> > >The %{?rhel} macro name currently exists and is in use in some >packages as I recall. Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work. I would prefer a new macro for the ELN work to distinguish it from the existing macros. >> * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL >>major release. This should be ok in the community since Red Hat ultimately >>makes the decision to version RHEL. This is an engineering decision and I >>think it would help imply that ELN is _not_ meant for current RHEL. This >>also lets us entertain the idea of multiple ELN major versions concurrently >>should we ever want to do that. >> > >I rather equate this to RHELhide, it should be evolving. Once N is >branched (CentOS?) and moving on, this is N+1. This is the rolling >development location. I agree. The 'N' value seen in this dist tag should always be greater than the latest major version we see for RHEL and CentOS. Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of this seems it should carry no number, similar to the rawhide it is inheriting from. Let them deal with numbers in CentOS and RHEL. I find it useful to have that information in the dist tag so that you can see a built package and have an idea of when it was built. -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email
Re: Coq build issues in F32
On Fri, Mar 27, 2020 at 2:41 PM Richard W.M. Jones wrote: > Yup, and the stack trace shows the failure happening when creating an > ephemeron. On the other hand, a scratch build with coq upstream's final patch for ocaml 4.10.0 succeeded on the first try: https://koji.fedoraproject.org/koji/taskinfo?taskID=42808115 Where this is an intermittent problem, I'll have to try more builds to be sure, but this looks promising. -- 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 04:20:16PM -0600, Jerry James wrote: > On Fri, Mar 27, 2020 at 2:41 PM Richard W.M. Jones wrote: > > Yup, and the stack trace shows the failure happening when creating an > > ephemeron. > > On the other hand, a scratch build with coq upstream's final patch for > ocaml 4.10.0 succeeded on the first try: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42808115 > > Where this is an intermittent problem, I'll have to try more builds to > be sure, but this looks promising. I'll run it in a loop overnight and see if I can make it crash. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 4:41 PM Richard W.M. Jones wrote: > I'll run it in a loop overnight and see if I can make it crash. Good idea. Thank you! -- 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
So, in general I think this is a pretty cool idea and I am in favor of it. I do think we are going to have to learn and adjust as we go here somewhat, we can't be 100% sure of how this will pan out. Of course we should plan as best we can now too. :) Some random things in no particular order: * This is the sort of thing that doesn't really fit the change process too well, since it's not really tied to a release or adding some deliverable to a release or whatever. I guess it's the best we have though currently. * So, while you say "we will not be shipping any content produced from ELN directly to the general public", it sounds like ODCS composes and of course packages from koji will be available for those that know where to look for them, which brings up: ** Can you add that you will document how these packages interact somewhere? I guess the ELN wiki page if nothing else. ie, say eln packages are built with different compiler flags, we should have some way to tell people who get a hold of them what hardware will work on them or fail completely. ** If we get a lot of demand we may need to redo stuff around ODCS, as it's currently just a pair of vm's with a nfs mount to serve those composes. If there's a lot of load we may need to put some caching in front of it or put it on a dedicated download server or something. * Might note that this will require a new "release" in bodhi. I don't think thats much work (might just be config), but could be good to check. * Might add in the benifit to fedora that ODCS will get worked on and perhaps someday we can move all our other composes into it. (This would allow us to not have a bodhi-backend machine, it could be all in openshift, and let us let koji do the heavy lifting instead of a rawhide-composer instance) * Suggestion: How about making a ELN tracker bug and require anything that uses %eln or has some failure to build being filed against the package and tracked in the tracker. This would allow people who care to follow along and see how many issues there are, etc. * Depending on when we get this going, timing might be not that great. We have the datacenter move coming up. In late may/early june we will likely have a lot less capacity of builders until we can re-add machines as they arrive from shipping. I think as long as you don't mind things being slow, we could tune it so ELN builds are not as high priority as normal builds (so they will wait until there's capacity for them). They would still finish, just might take longer and not impact other builds. In fact, perhaps we should set this from the start and see if it causes you any issues? * Additionally there will likely be some more disk usage from this (on ODCS and in koji). However, if we only need to keep around the last working eln build and don't keep a bunch of composes I don't think this should be too big an issue. Definitely something to watch tho. Anyhow, those are probibly also a lot of things we can just sort out with releng, but figured I'd throw them out there while I was thinking about them. Overall I think this could be a very nice effort and won't even hopefully cost us much in time and energy. 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 03:19:01PM -0500, Justin Forbes wrote: > On Fri, Mar 27, 2020 at 2:42 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > > > Stephen Gallagher writes: > > > > It is under discussion whether this snapshot will have its own > > > > installation media. For now the preferred way to test ELN composes > > > > would be to use standard Fedora Rawhide images and then include ELN as > > > > an additional repository. > > > > > > Is there a dnf change that goes with this to prefer ELN content, then? > > > > Yeah, that's something I was trying to figure out too. As discussed > > before, for rpm '.eln < .fc33', so if the same package is available > > from both sources, the rawhide one will win. > > > > Can this be handled with the existing 'priority' directive in > repository config files? I think this is a nice behavior and we should consider not messing with it any. (ie, rawhide is always newer). Since we are not advertising this / marketing / expecting that normal users would use it, why not make it easy for them to go back if they install some eln packages? If you are one of the developers/testers you can use distro-sync, or a composed eln media to test and then just 'dnf update' (or distro-sync) back to rawhide. This also means if someone installs a .eln package on a stable fedora, it will be 'upgraded' away to next time the package updates. Or if they go from say f31 to f32. 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 4:42 PM Jerry James wrote: > Good idea. Thank you! I got a segfault on s390x on the second build attempt. I'd like to investigate the ephemeron angle a bit, I think. -- 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: Fedora 33 System-Wide Change proposal: Sqlite RpmDB
So, my concern here is timeline vs the upcoming datacenter move. ;( Do you have any ideas when rpm 4.16 will be released? I don't see any dates on the change. Or perhaps I guess the question is when it will land in rawhide? As soon as it lands in rawhide we need to upgrade the builders to the rawhide rpm and set macros so it uses bdb for everything but rawhide. It's very likely however that builders will still be Fedora 31 at that point. (If that matters for rpm any). Or I suppose we could try and get mock's bootstrapping working before then. In either case, it may be hard to have cycles for this while datacenter move is happening. It would help if we had a ballpark at least for when it will land / some folks willing to get bootstrapping working in koji. Or what would you think of the idea of landing it in rawhide, but keeping default bdb until after we have the move done and can upgrade builders to f32? 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: Unsubscribe
Hi, I would like to unsubscribe. Best Regards, Wen Rei ___ 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: Sqlite RpmDB
On Fri, Mar 27, 2020 at 8:01 PM Kevin Fenzi wrote: > > So, my concern here is timeline vs the upcoming datacenter move. ;( > > Do you have any ideas when rpm 4.16 will be released? I don't see any > dates on the change. Or perhaps I guess the question is when it will > land in rawhide? > Panu tagged the rpm 4.16 alpha earlier this week, so I would hope it'd land in Rawhide next week. > As soon as it lands in rawhide we need to upgrade the builders to the > rawhide rpm and set macros so it uses bdb for everything but rawhide. > It's very likely however that builders will still be Fedora 31 at that > point. (If that matters for rpm any). > You can set the macro now for all targets that this would be a problem with, it'll be a no-op with current rpm. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unsubscribe
On 2020-03-28 08:24, wen rei do wrote: > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- The key to getting good answers is to ask good questions. ___ 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: Coq build issues in F32
Jerry James writes: > I think Richard addressed most of the points you raised. Yes, and no new questions, either. So I think I'm done here (well, I'll spectate, but the internals of the OCaml compiler are well beyond my skillset :-). Good luck! Steve -- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN ___ 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
Self Introduction: Weiping
Hi, I'm working on packaging cputil, and I'm interested in working on useful tools about benchmark or performance. Thanks Zbyszek's kindly help. Thanks Weiping ___ 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