Re: Build into < Rawhide side tag fails with "Package ... has already been built"
On Thu, Feb 27, 2020 at 11:43:16AM -0800, Kevin Fenzi wrote: > On Thu, Feb 27, 2020 at 07:50:05PM +0100, Clement Verna wrote: > > On Thu, 27 Feb 2020 at 14:14, Richard W.M. Jones wrote: > > > > > Despite earlier concerns, this does in fact appear to all be working fine. > > > > > > > Yes requesting and building in the side tag should work just fine. > > > > > > > > > > There are now F32 builds going through for all OCaml packages in a > > > side tag, and when that's done I'll try to create a Bodhi update. > > > > > > > This is where you are going to have some problems, the deployed version of > > Bodhi is not yet ready to support side tags for other release than rawhide. > > A new release of Bodhi with that support should arrive soon tho. > > In the mean time, you can file a releng ticket when you are ready and we > can retag all your builds from the side-tag into candidate so you can > make a update from them. :( Sorry for the hassle. I guess I should read my email more frequently :-( Because I created the update already before I read this email ... https://bodhi.fedoraproject.org/updates/FEDORA-2020-7bddd7253f However it looks as if the update is fine - it was created without problems, contains the right builds and has the right Fedora version. So maybe we're fine after all? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ 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: Non-responsive maintainer: pocock
On Thu, Feb 27, 2020 17:07:21 -0500, Dakota Williams via devel wrote: > On 2/26/20 6:59 PM, Daniel Pocock wrote: > > > > > > > Would you like help? I'd be willing to be a co-maintainer to make the > > > branch. > > > > Yes, I would welcome help with these packages > > > > But there is also an increasing problem of making decisions about trust > > > > In the case of developers who I haven't met or worked with, I don't > > really know how to proceed > > > > I've seen several extraordinary examples of developers doing things that > > undermine my confidence in them over the last couple of years. The > > fighting within GNU and FSF right now is the latest iteration of that. > > > > Now, whenever I receive a request from somebody I don't know, there is > > an extra effort for me to decide how to proceed. > > > > Maybe I can simply resign from maintaining the asio package and then opt > > out of the process of choosing a new maintainer. > > > > Please don't take this personally: it is a reflection of the overall > > state of free software communities today. > > > I don't know about the situation with the GNU project and the FSF, but if > there's something you'd like me to do to prove trust, I could do it. I'd like to add that by default we trust each other, in the spirit of being excellent to each other. In this particular case, co-maintainership shares responsibility but does not hand it over completely (the handing-over bit can be done at a later stage, if necessary). Every change/commit/message is public, so there are plenty of opportunities to catch any errors. Given that we do not often meet our Fedora colleagues in person, it is not viable to expect members of the community to prove trustworthiness through personal relationships. We assume the best in each other, and if things do get hairy, we have open community channels, processes, and overseeing bodies through which changes can be emended. -- 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: Build into < Rawhide side tag fails with "Package ... has already been built"
Kevin Fenzi wrote: > In the mean time, you can file a releng ticket when you are ready and we > can retag all your builds from the side-tag into candidate so you can > make a update from them. :( Sorry for the hassle. Unless this changed recently, you can actually tag your packages into f*-updates-candidate yourself, we have been doing that for stuff built in the f*-kde side tags (which were created manually by rel-eng) all the time. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Non-responsive maintainer: pocock
Please excuse me going completely offtopic here - for some reason I'm getting this thread addressed directly to me. If someone's adding me as bcc please don't, I have nothing to do with this. Thanks, Radka -- *Radka Janeková (she/her)* .NET Core QE Lead, Red Hat *radka.ja...@redhat.com * IRC: radka | Freenode: Rhea On Fri, Feb 28, 2020 at 10:02 AM Ankur Sinha wrote: > On Thu, Feb 27, 2020 17:07:21 -0500, Dakota Williams via devel wrote: > > On 2/26/20 6:59 PM, Daniel Pocock wrote: > > > > > > > > > > Would you like help? I'd be willing to be a co-maintainer to make the > > > > branch. > > > > > > Yes, I would welcome help with these packages > > > > > > But there is also an increasing problem of making decisions about trust > > > > > > In the case of developers who I haven't met or worked with, I don't > > > really know how to proceed > > > > > > I've seen several extraordinary examples of developers doing things > that > > > undermine my confidence in them over the last couple of years. The > > > fighting within GNU and FSF right now is the latest iteration of that. > > > > > > Now, whenever I receive a request from somebody I don't know, there is > > > an extra effort for me to decide how to proceed. > > > > > > Maybe I can simply resign from maintaining the asio package and then > opt > > > out of the process of choosing a new maintainer. > > > > > > Please don't take this personally: it is a reflection of the overall > > > state of free software communities today. > > > > > I don't know about the situation with the GNU project and the FSF, but if > > there's something you'd like me to do to prove trust, I could do it. > > I'd like to add that by default we trust each other, in the spirit of > being excellent to each other. In this particular case, > co-maintainership shares responsibility but does not hand it over > completely (the handing-over bit can be done at a later stage, if > necessary). Every change/commit/message is public, so there are plenty > of opportunities to catch any errors. > > Given that we do not often meet our Fedora colleagues in person, it is > not viable to expect members of the community to prove trustworthiness > through personal relationships. We assume the best in each other, and if > things do get hairy, we have open community channels, processes, and > overseeing bodies through which changes can be emended. > > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > ___ > 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: Ideas and proposal for removing changelog and release fields from spec file
Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a): > Hi, > > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote: >> For the changelog, we believe we have a potential good solution: >> - The changelog will be automatically generated using an external `changelog` >> file as well as the commit history > ... >> If you wanted to edit the changelog, you would: >> - Generate the changelog locally via a command like: >> `fedpkg generate-changelog > changelog` >> - Edit `changelog` as desired >> - Commit and push the changes > This means that a separate commit needs to be done *after* on top > of the commits doing the actual changes. It would not need any extra commit, if you modified manually the changelog with the last entry. Which should be not problem, considering that `fedpkg generate-changelog > changelog` would be executed locally and you can amend the last commit with the changelog. Vít > It's a bit disappointing, but > on its own would not be too bad, since we can have fedpkg provide a > higher level command that combines generate-changelog and build... > > One important feature will work: > being able to cherry-pick commit between branches w/o spurious > conflicts. As long as the "real" change to the spec file are done in > separate commits, and the changelog commit is another commit on top, > then when cherry-picking to another branch, the "real" commits would > be cherry-pickable, and then the changelog commit would be recreated > using the automation, OK. > > But it doesn't work quite as nicely with something similar: merging > branches. A simple 'git merge' would result in conflicts. > > Also, if an amendment to the changelog is done, and the same change > needs to be done in the changelog in a different branch, trying to > cherry-pick the fix commit would most likely result in a merge > conflict. > > Considering these three drawbacks (separate commit step and resulting > log noise, merge conflicts), I'd very much hope for a solution where > the changelog is never stored in the version control, and is always > autogenerated at srpm creation time. We should never try to chery-pick > commits that have changelog entries with actual date or e-v-r texts, > since this will inevitably lead to merge conflicts. > > > A different approach: > - we have 'fedpkg generate-changelog' (which does all the git log > extraction that was described, I think that part is OK), > - the output from this command included in the srpm at srpm generation > time and never committed to version control, > - the output is annotated with the source commits hashes, so we can > see where each line came from. > > At any time, the packager can run 'fedpkg generate-changelog' to see > how the output looks like. If they see something they don't like, if > the commits haven't been pushed out yet, they can immediately run > 'git commit --amend' and recheck. If they have been pushed out, an override > to the changelog could be committed as part of a commit message text. > > Git-changelog-suppress: adb42e > or > Git-changelog-suppress: adb42e..efefedeadb > or > Git-changelog-replace: adb42e > Some other text with typos fixed that completely overrides whatever > was generated from adb42e. > or > Git-changelog-append: adb42e > (additional clarification for commit adb42e, e.g. bug #12345) > > This would have the following advantages: > - git log is the sole source of truth > - there are no cherry-pick or merge conflicts > - there is no separate "now I'm done and I need to do another commit > before building" thing. > > The assumption is that those Git-changelog-* macros would only be > used occasionally, if the bad changelog entry was not noticed before > pushing the changes out. > > (One nitpick: when cherry-picking between branches, hashes of the > cherry-picked commits change, so "adb42e" in the example above > would stop working. This is handled by using 'git cherry-pick -x'. > 'fedpkg generate-changelog' would look at any hash in a > "(cherry picked from commit ...)" line.) > > > As how to hook this up with rpm, > looking at > https://pagure.io/packaging-committee/pull-request/942#comment-108542, > a macro like %generate_changelog could be provided that would > simply shell out to 'fedpkg generate-changelog'. > > > I'll comment separate on the -release part. > > 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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.
Re: Ideas and proposal for removing changelog and release fields from spec file
On Fri, Feb 28, 2020 at 12:31:23PM +0100, Vít Ondruch wrote: > > Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a): > > Hi, > > > > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote: > >> For the changelog, we believe we have a potential good solution: > >> - The changelog will be automatically generated using an external > >> `changelog` > >> file as well as the commit history > > ... > >> If you wanted to edit the changelog, you would: > >> - Generate the changelog locally via a command like: > >> `fedpkg generate-changelog > changelog` > >> - Edit `changelog` as desired > >> - Commit and push the changes > > This means that a separate commit needs to be done *after* on top > > of the commits doing the actual changes. > > > It would not need any extra commit, if you modified manually the > changelog with the last entry. Which should be not problem, considering > that `fedpkg generate-changelog > changelog` would be executed locally > and you can amend the last commit with the changelog. Yes, but... Normally I'd do a cycle of "hack + build&test + commit". Now if I do changelog generation, I'd either have to repeat it after every step, or do it once at the end and then the last commit would suddenly contain a changelog update for multiple previous commits. Either way, this is not elegant and rather brittle. Zbyszek > > It's a bit disappointing, but > > on its own would not be too bad, since we can have fedpkg provide a > > higher level command that combines generate-changelog and build... > > > > One important feature will work: > > being able to cherry-pick commit between branches w/o spurious > > conflicts. As long as the "real" change to the spec file are done in > > separate commits, and the changelog commit is another commit on top, > > then when cherry-picking to another branch, the "real" commits would > > be cherry-pickable, and then the changelog commit would be recreated > > using the automation, OK. > > > > But it doesn't work quite as nicely with something similar: merging > > branches. A simple 'git merge' would result in conflicts. > > > > Also, if an amendment to the changelog is done, and the same change > > needs to be done in the changelog in a different branch, trying to > > cherry-pick the fix commit would most likely result in a merge > > conflict. > > > > Considering these three drawbacks (separate commit step and resulting > > log noise, merge conflicts), I'd very much hope for a solution where > > the changelog is never stored in the version control, and is always > > autogenerated at srpm creation time. We should never try to chery-pick > > commits that have changelog entries with actual date or e-v-r texts, > > since this will inevitably lead to merge conflicts. > > > > > > A different approach: > > - we have 'fedpkg generate-changelog' (which does all the git log > > extraction that was described, I think that part is OK), > > - the output from this command included in the srpm at srpm generation > > time and never committed to version control, > > - the output is annotated with the source commits hashes, so we can > > see where each line came from. > > > > At any time, the packager can run 'fedpkg generate-changelog' to see > > how the output looks like. If they see something they don't like, if > > the commits haven't been pushed out yet, they can immediately run > > 'git commit --amend' and recheck. If they have been pushed out, an override > > to the changelog could be committed as part of a commit message text. > > > > Git-changelog-suppress: adb42e > > or > > Git-changelog-suppress: adb42e..efefedeadb > > or > > Git-changelog-replace: adb42e > > Some other text with typos fixed that completely overrides whatever > > was generated from adb42e. > > or > > Git-changelog-append: adb42e > > (additional clarification for commit adb42e, e.g. bug #12345) > > > > This would have the following advantages: > > - git log is the sole source of truth > > - there are no cherry-pick or merge conflicts > > - there is no separate "now I'm done and I need to do another commit > > before building" thing. > > > > The assumption is that those Git-changelog-* macros would only be > > used occasionally, if the bad changelog entry was not noticed before > > pushing the changes out. > > > > (One nitpick: when cherry-picking between branches, hashes of the > > cherry-picked commits change, so "adb42e" in the example above > > would stop working. This is handled by using 'git cherry-pick -x'. > > 'fedpkg generate-changelog' would look at any hash in a > > "(cherry picked from commit ...)" line.) > > > > > > As how to hook this up with rpm, > > looking at > > https://pagure.io/packaging-committee/pull-request/942#comment-108542, > > a macro like %generate_changelog could be provided that would > > simply shell out to 'fedpkg generate-changelog'. > > > > > > I'll comment separate on the -release part. > > > > Zbyszek
Re: Ideas and proposal for removing changelog and release fields from spec file
Dne 28. 02. 20 v 15:06 Zbigniew Jędrzejewski-Szmek napsal(a): > On Fri, Feb 28, 2020 at 12:31:23PM +0100, Vít Ondruch wrote: >> Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a): >>> Hi, >>> >>> On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote: For the changelog, we believe we have a potential good solution: - The changelog will be automatically generated using an external `changelog` file as well as the commit history >>> ... If you wanted to edit the changelog, you would: - Generate the changelog locally via a command like: `fedpkg generate-changelog > changelog` - Edit `changelog` as desired - Commit and push the changes >>> This means that a separate commit needs to be done *after* on top >>> of the commits doing the actual changes. >> >> It would not need any extra commit, if you modified manually the >> changelog with the last entry. Which should be not problem, considering >> that `fedpkg generate-changelog > changelog` would be executed locally >> and you can amend the last commit with the changelog. > Yes, but... Normally I'd do a cycle of "hack + build&test + commit". > Now if I do changelog generation, I'd either have to repeat it after > every step, or do it once at the end and then the last commit would > suddenly contain a changelog update for multiple previous commits. Either > way, this is not elegant and rather brittle. But the point of automation is to not edit changelog at all, isn't it? If you are going to edit it, then the automation probably did not work good enough or you have pushed something you should not have. Changelog is brittle even now. Everybody is free to edit changelog from release to release and there are no restrictions what can be done there. The situation with automation won't be worse then it is now. Vít > > Zbyszek > >>> It's a bit disappointing, but >>> on its own would not be too bad, since we can have fedpkg provide a >>> higher level command that combines generate-changelog and build... >>> >>> One important feature will work: >>> being able to cherry-pick commit between branches w/o spurious >>> conflicts. As long as the "real" change to the spec file are done in >>> separate commits, and the changelog commit is another commit on top, >>> then when cherry-picking to another branch, the "real" commits would >>> be cherry-pickable, and then the changelog commit would be recreated >>> using the automation, OK. >>> >>> But it doesn't work quite as nicely with something similar: merging >>> branches. A simple 'git merge' would result in conflicts. >>> >>> Also, if an amendment to the changelog is done, and the same change >>> needs to be done in the changelog in a different branch, trying to >>> cherry-pick the fix commit would most likely result in a merge >>> conflict. >>> >>> Considering these three drawbacks (separate commit step and resulting >>> log noise, merge conflicts), I'd very much hope for a solution where >>> the changelog is never stored in the version control, and is always >>> autogenerated at srpm creation time. We should never try to chery-pick >>> commits that have changelog entries with actual date or e-v-r texts, >>> since this will inevitably lead to merge conflicts. >>> >>> >>> A different approach: >>> - we have 'fedpkg generate-changelog' (which does all the git log >>> extraction that was described, I think that part is OK), >>> - the output from this command included in the srpm at srpm generation >>> time and never committed to version control, >>> - the output is annotated with the source commits hashes, so we can >>> see where each line came from. >>> >>> At any time, the packager can run 'fedpkg generate-changelog' to see >>> how the output looks like. If they see something they don't like, if >>> the commits haven't been pushed out yet, they can immediately run >>> 'git commit --amend' and recheck. If they have been pushed out, an override >>> to the changelog could be committed as part of a commit message text. >>> >>> Git-changelog-suppress: adb42e >>> or >>> Git-changelog-suppress: adb42e..efefedeadb >>> or >>> Git-changelog-replace: adb42e >>> Some other text with typos fixed that completely overrides whatever >>> was generated from adb42e. >>> or >>> Git-changelog-append: adb42e >>> (additional clarification for commit adb42e, e.g. bug #12345) >>> >>> This would have the following advantages: >>> - git log is the sole source of truth >>> - there are no cherry-pick or merge conflicts >>> - there is no separate "now I'm done and I need to do another commit >>> before building" thing. >>> >>> The assumption is that those Git-changelog-* macros would only be >>> used occasionally, if the bad changelog entry was not noticed before >>> pushing the changes out. >>> >>> (One nitpick: when cherry-picking between branches, hashes of the >>> cherry-picked commits change, so "adb42e" in the example above >>> wo
Re: Ideas and proposal for removing changelog and release fields from spec file
On Fri, 28 Feb 2020 at 15:07, Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Feb 28, 2020 at 12:31:23PM +0100, Vít Ondruch wrote: > > > > Dne 27. 02. 20 v 16:11 Zbigniew Jędrzejewski-Szmek napsal(a): > > > Hi, > > > > > > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote: > > >> For the changelog, we believe we have a potential good solution: > > >> - The changelog will be automatically generated using an external > > >> `changelog` > > >> file as well as the commit history > > > ... > > >> If you wanted to edit the changelog, you would: > > >> - Generate the changelog locally via a command like: > > >> `fedpkg generate-changelog > changelog` > > >> - Edit `changelog` as desired > > >> - Commit and push the changes > > > This means that a separate commit needs to be done *after* on top > > > of the commits doing the actual changes. > > > > > > It would not need any extra commit, if you modified manually the > > changelog with the last entry. Which should be not problem, considering > > that `fedpkg generate-changelog > changelog` would be executed locally > > and you can amend the last commit with the changelog. > > Yes, but... Normally I'd do a cycle of "hack + build&test + commit". > Now if I do changelog generation, I'd either have to repeat it after > every step, or do it once at the end and then the last commit would > suddenly contain a changelog update for multiple previous commits. Either > way, this is not elegant and rather brittle. I thought the main reason not to combine update in the changelog file with code commits is to avoid conflicts when cherry picking as you described. I.e. i do minor update specifically in f32 and generate changelog file in the same commit. Then I want to do normal release update for all fedora branches. I start with master (as usual) and add e.g. add a new patch and generate the changelog file because i would like to add more info, then commit. Now I cannot cherry-pick that commit into f32 without conflict. In this case we wouldn't achieve one the targets of this proposal (afaik) => getting rid of merge conflicts in changelog and release - this is cherry-picking but still it would be nice not to have conflicts there. This target isn't in the document i think but i thought this is one of the goals. clime > > Zbyszek > > > > It's a bit disappointing, but > > > on its own would not be too bad, since we can have fedpkg provide a > > > higher level command that combines generate-changelog and build... > > > > > > One important feature will work: > > > being able to cherry-pick commit between branches w/o spurious > > > conflicts. As long as the "real" change to the spec file are done in > > > separate commits, and the changelog commit is another commit on top, > > > then when cherry-picking to another branch, the "real" commits would > > > be cherry-pickable, and then the changelog commit would be recreated > > > using the automation, OK. > > > > > > But it doesn't work quite as nicely with something similar: merging > > > branches. A simple 'git merge' would result in conflicts. > > > > > > Also, if an amendment to the changelog is done, and the same change > > > needs to be done in the changelog in a different branch, trying to > > > cherry-pick the fix commit would most likely result in a merge > > > conflict. > > > > > > Considering these three drawbacks (separate commit step and resulting > > > log noise, merge conflicts), I'd very much hope for a solution where > > > the changelog is never stored in the version control, and is always > > > autogenerated at srpm creation time. We should never try to chery-pick > > > commits that have changelog entries with actual date or e-v-r texts, > > > since this will inevitably lead to merge conflicts. > > > > > > > > > A different approach: > > > - we have 'fedpkg generate-changelog' (which does all the git log > > > extraction that was described, I think that part is OK), > > > - the output from this command included in the srpm at srpm generation > > > time and never committed to version control, > > > - the output is annotated with the source commits hashes, so we can > > > see where each line came from. > > > > > > At any time, the packager can run 'fedpkg generate-changelog' to see > > > how the output looks like. If they see something they don't like, if > > > the commits haven't been pushed out yet, they can immediately run > > > 'git commit --amend' and recheck. If they have been pushed out, an > > > override > > > to the changelog could be committed as part of a commit message text. > > > > > > Git-changelog-suppress: adb42e > > > or > > > Git-changelog-suppress: adb42e..efefedeadb > > > or > > > Git-changelog-replace: adb42e > > > Some other text with typos fixed that completely overrides whatever > > > was generated from adb42e. > > > or > > > Git-changelog-append: adb42e > > > (additional clarification for commit adb42e, e.g. bug #12345) > > > > > > Thi
Memory exhaustion on armv7hl builders
I'm unable to build ParaView on armv7hl: [ 14%] Building CXX object VTK/Accelerators/Vtkm/CMakeFiles/AcceleratorsVTKm.dir/vtkmClip.cxx.o cd /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Accelerators/Vtkm && /usr/bin/c++ -DAcceleratorsVTKm_EXPORTS -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Accelerators/Vtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Accelerators/Vtkm -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/DataModel -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/DataModel -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Math -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Math -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Transforms -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Transforms -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/ExecutionModel -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/ExecutionModel -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/General -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/General -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Misc -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Misc -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/Geometry -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/Geometry -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Imaging/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Imaging/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm/vtkvtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/include -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/taotuple -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/optionparser -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/diy -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/lcl/vtkmlcl -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Utilities/KWIML -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/Utilities/KWIML -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Utilities/KWSys -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/Utilities/KWSys -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fcommon -march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -O2 -g -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -ffunction-sections -std=c++11 -o CMakeFiles/AcceleratorsVTKm.dir/vtkmClip.cxx.o -c /builddir/build/BUILD/ParaView-v5.8.0/VTK/Accelerators/Vtkm/vtkmClip.cxx virtual memory exhausted: Operation not permitted I have already reduced the make parallelism to 1, so not sure what else I can do to avoid this other than to exclude it (which I'm probably happy to do). Suggestions welcome. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: Build into < Rawhide side tag fails with "Package ... has already been built"
On Fri, Feb 28, 2020 at 08:50:08AM +, Richard W.M. Jones wrote: > On Thu, Feb 27, 2020 at 11:43:16AM -0800, Kevin Fenzi wrote: > > On Thu, Feb 27, 2020 at 07:50:05PM +0100, Clement Verna wrote: > > > On Thu, 27 Feb 2020 at 14:14, Richard W.M. Jones > > > wrote: > > > > > > > Despite earlier concerns, this does in fact appear to all be working > > > > fine. > > > > > > > > > > Yes requesting and building in the side tag should work just fine. > > > > > > > > > > > > > > There are now F32 builds going through for all OCaml packages in a > > > > side tag, and when that's done I'll try to create a Bodhi update. > > > > > > > > > > This is where you are going to have some problems, the deployed version of > > > Bodhi is not yet ready to support side tags for other release than > > > rawhide. > > > A new release of Bodhi with that support should arrive soon tho. > > > > In the mean time, you can file a releng ticket when you are ready and we > > can retag all your builds from the side-tag into candidate so you can > > make a update from them. :( Sorry for the hassle. > > I guess I should read my email more frequently :-( Because I > created the update already before I read this email ... > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-7bddd7253f > > However it looks as if the update is fine - it was created without > problems, contains the right builds and has the right Fedora version. > So maybe we're fine after all? Yeah, seems ok from here... :) 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: Memory exhaustion on armv7hl builders
On 28/2/20 12:04, Orion Poplawski wrote: I'm unable to build ParaView on armv7hl: [ 14%] Building CXX object VTK/Accelerators/Vtkm/CMakeFiles/AcceleratorsVTKm.dir/vtkmClip.cxx.o cd /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Accelerators/Vtkm && /usr/bin/c++ -DAcceleratorsVTKm_EXPORTS -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Accelerators/Vtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Accelerators/Vtkm -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/DataModel -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/DataModel -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Math -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Math -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Transforms -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Transforms -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/ExecutionModel -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/ExecutionModel -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/General -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/General -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Common/Misc -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Common/Misc -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Filters/Geometry -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Filters/Geometry -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Imaging/Core -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/Imaging/Core -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm/vtkvtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m -I/builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/include -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/taotuple -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/optionparser -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/diy -I/builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm/vtkvtkm/vtk-m/vtkm/thirdparty/lcl/vtkmlcl -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Utilities/KWIML -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/Utilities/KWIML -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/Utilities/KWSys -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/Utilities/KWSys -isystem /builddir/build/BUILD/ParaView-v5.8.0/armv7hl-redhat-linux-gnueabi/VTK/ThirdParty/vtkm -isystem /builddir/build/BUILD/ParaView-v5.8.0/VTK/ThirdParty/vtkm -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fcommon -march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux -mfloat-abi=hard -O2 -g -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -ffunction-sections -std=c++11 -o CMakeFiles/AcceleratorsVTKm.dir/vtkmClip.cxx.o -c /builddir/build/BUILD/ParaView-v5.8.0/VTK/Accelerators/Vtkm/vtkmClip.cxx virtual memory exhausted: Operation not permitted I have already reduced the make parallelism to 1, so not sure what else I can do to avoid this other than to exclude it (which I'm probably happy to do). Suggestions welcome. Something like this https://src.fedoraproject.org/rpms/nodejs/c/0217ef1931929f05d069c7281b713c60408f87c4 ___ 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: Build into < Rawhide side tag fails with "Package ... has already been built"
On Fri, Feb 28, 2020 at 10:21:22AM +0100, Kevin Kofler wrote: > Kevin Fenzi wrote: > > In the mean time, you can file a releng ticket when you are ready and we > > can retag all your builds from the side-tag into candidate so you can > > make a update from them. :( Sorry for the hassle. > > Unless this changed recently, you can actually tag your packages into > f*-updates-candidate yourself, we have been doing that for stuff built in > the f*-kde side tags (which were created manually by rel-eng) all the time. Sure, that would work too. 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: Memory exhaustion on armv7hl builders
On 28.02.2020 16:04, Orion Poplawski wrote:
> I have already reduced the make parallelism to 1, so not sure what else
> I can do to avoid this other than to exclude it (which I'm probably
> happy to do). Suggestions welcome.
You can try this:
%global optflags %(echo %{optflags} | sed 's/-g /-g1 /')
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.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: Memory exhaustion on armv7hl builders
On 2/28/20 8:20 AM, Vitaly Zaitsev via devel wrote:
On 28.02.2020 16:04, Orion Poplawski wrote:
I have already reduced the make parallelism to 1, so not sure what else
I can do to avoid this other than to exclude it (which I'm probably
happy to do). Suggestions welcome.
You can try this:
%global optflags %(echo %{optflags} | sed 's/-g /-g1 /')
thanks (to you an Pablo who pointed to the same) - I'll give that a try.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
smime.p7s
Description: S/MIME Cryptographic 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: Memory exhaustion on armv7hl builders
On Fri, Feb 28, 2020 at 08:27:02AM -0700, Orion Poplawski wrote:
> On 2/28/20 8:20 AM, Vitaly Zaitsev via devel wrote:
> > On 28.02.2020 16:04, Orion Poplawski wrote:
> > > I have already reduced the make parallelism to 1, so not sure what else
> > > I can do to avoid this other than to exclude it (which I'm probably
> > > happy to do). Suggestions welcome.
> >
> > You can try this:
> >
> > %global optflags %(echo %{optflags} | sed 's/-g /-g1 /')
> >
>
> thanks (to you an Pablo who pointed to the same) - I'll give that a try.
But if the problem is only on armv7hl (or say only on 32-bit architectures),
please limit the workaround to those.
Jakub
___
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-20200228.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
Fedora-Cloud-31-20200228.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: Tox automation in packaging macros
On Tue, 2020-01-14 at 01:29 +0100, Miro Hrončok wrote:
> On 13. 01. 20 22:54, Adam Williamson wrote:
> > On Sun, 2020-01-12 at 23:24 +0100, Miro Hrončok wrote:
> > > > Please don't mention it as required or even necessarily recommended, as
> > > > it may not be. I intentionally set up my projects such that tox is
> > > > appropriate for upstream CI, not distribution package checking, and
> > > > intend distribution packages to run setup.py test.
> > >
> > > The %tox macro runs the tests in current environment.
> > >
> > > See https://github.com/fedora-python/tox-current-env/ for details.
> >
> > It's not about the environment. It's about what they actually *do*. In
> > my projects, tox runs linters, coverage checks and unit tests; setup.py
> > test only runs unit tests. This is a convenient separation because I
> > find it appropriate to run linters and coverage checks on commits/PRs
> > for upstream, but there is no point in running them on package builds.
>
> I agree with everything you said. Taking what we have, ideally we should
> convince upstreams to only run tests with default toxenv, not linters.
>
> We also don't have a tox-standard to only run offline testes etc. Maybe one
> day...
>
> > > At the same time, `setup.py test` is deprecated.
> >
> > Sigh. Always nice when people deprecate perfectly well-working
> > workflows out from underneath you. :/
>
> Right. Two things to consider:
>
> - the deprecation period will most likely last forever
> - setup.py files will eventually disappear anyway
So I looked into all of this stuff a bit last night. My conclusions so
far:
* It would be really nice if there were a short Idiot's Guide with a
sample project and RPM spec that puts everything together, as opposed
to me winding up with a browser full of tabs open to
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/tree/master and
https://www.python.org/dev/peps/pep-0517/ and
https://hynek.me/articles/sharing-your-labor-of-love-pypi-quick-and-dirty/
etc. Especially since...
* ...the Shiny New Stuff does not appear to be available on EPEL *at
all* yet - not even EPEL 8. This makes it a bit of a non-starter if you
want to use the same spec file bits across Fedora and EPEL. I realize
it may be impractical/impossible to backport everything to EPEL 7, and
am getting close to the point where I throw in the towel and drop
Python 2 support from my projects' master branches and hang the EPEL 7
package repos out on a branch, but EPEL 8 would be nice and ought to be
possible?
* Unless I'm missing something, what you suggested for tox - "ideally
we should convince upstreams to only run tests with default toxenv" -
actually seems weirdly difficult to implement. AFAIK none of the
official or unofficial tox docs I can find really cover the idea of
having an environment that's *defined* but is not *default*. It seems
to be virtually universal practice with tox that you put every
environment in `envlist`...and if you just run `tox` without any `-e`
argument or special env var, it runs every environment in `envlist`.
People seem to assume all environments will be default, and if you want
to run fewer than 'all of them' you filter with `-e` or whatever.
I *did* figure out a way to do this, but it's something I never really
saw documented anywhere, and I eventually hit a roadblock with using it
in the CI setup I made. You have to make a `tox.ini` like this:
[tox]
envlist = py{27,36,37,38,39}
[testenv]
deps =
-r{toxinidir}/install.requires
-r{toxinidir}/tests.requires
ci: -r{toxinidir}/ci.requires
commands =
py.test
ci: py.test --cov-report term-missing --cov-report xml --cov openqa_client
ci: diff-cover coverage.xml --fail-under=90
ci: diff-quality --violations=pylint --fail-under=90
setenv =
PYTHONPATH = {toxinidir}
by having `ci` directives in `deps` and `commands` like that, you sort
of imply the existence of environments like `py27-ci` without ever
explicitly declaring them, and tox itself is OK with this. You can run
`tox -epy{27,36,37,38,39}-ci` and it'll do what you (maybe) expect -
it'll read ci.requires and run the additional commands. But if you just
run `tox` it'll run the py{27,36,37,38,39} environments without the
additional `ci` bits.
This definitely seems to be a bit 'off the beaten track', though, like
I said - it's not explicitly documented anywhere I could find (most
documentation of the whole generative environments thing assumes all
the environments will be declared up in `envlist`) and commands like
`tox -l` and `tox -a` may not do what you expect.
The showstopper I ultimately hit was in an extension on top of tox,
`tox-gh-actions`, which is a convenience thing for using tox with
GitHub Actions:
https://github.com/ymyzk/tox-gh-actions/issues/11
(the project I'm using as a testbed for this stuff is hosted in github,
and Actions seemed like the easiest way to set up CI). It seems like
this 'implicit non-default environment' thing completely t
Fedora 32 Beta blocker status
Action summary Accepted blockers - 1. dnf-plugins-extras — Cannot upgrade to Fedora 32: Modules blocking the upgrade path — NEW ACTION: QA to test dnf-plugins-extras-4.0.9-3.fc32 2. PackageKit — Cannot upgrade to Fedora 32: Modules blocking the upgrade path — NEW ACTION: PackageKit maintainers to work with dnf team to implement module reset workaround NEEDINFO: rhughes 3. python-blivet — blivet.errors.DeviceTreeError: failed to add slave root00p2 of device root00 — ASSIGNED ACTION: Maintainers to diagnose and fix crash 4. anaconda — pyanaconda.modules.common.errors.storage.UnknownDeviceError: home — VERIFIED ACTION: releng to include anaconda-32.24.2-1 in next compose 5. gnome-shell — [abrt] gnome-shell: js::gc::TenuredCell::writeBarrierPre(js::gc::TenuredCell*)(): gnome-shell killed by SIGSEGV — ASSIGNED ACTION: QA to test upstream fix in COPR. 6. python-blivet — anaconda unable to finish installation with software raid partition — NEW ACTION: Maintainers to diagnose and fix crash 7. distribution — Fedora 32 backgrounds not included — NEW ACTION: Design team to package backgrounds Proposed blockers - 1. virt-manager — NAT (Inactive) by default, cannot create a VM — NEW ACTION: Maintainers to diagnose and fix issue Bug-by-bug detail = Accepted blockers - 1. dnf-plugins-extras — https://bugzilla.redhat.com/show_bug.cgi?id=1767351 — ON_QA Cannot upgrade to Fedora 32: Modules blocking the upgrade path dnf-plugins-extras-4.0.9-3.fc32 has been submitted to fix this. 2. PackageKit — https://bugzilla.redhat.com/show_bug.cgi?id=1804564 — NEW Cannot upgrade to Fedora 32: Modules blocking the upgrade path See also BZ 1767351 from which it was cloned. This may require an additional API in libdnf 3. python-blivet — https://bugzilla.redhat.com/show_bug.cgi?id=1798792 — ASSIGNED blivet.errors.DeviceTreeError: failed to add slave root00p2 of device root00 Using SCSI, IDE, or SATA software RAID created by the installer in a virtualized environment crashes on the post-install boot. Behavior is not seen with virtio disk bus. May be related to open upstream PR https://github.com/storaged-project/blivet/pull/796 4. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=1806233 — VERIFIED pyanaconda.modules.common.errors.storage.UnknownDeviceError: home Deleting mount points from a previous custom-partitioned failed installation causes a crash in the installer. 5. 1. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=1801820 — ASSIGNED [abrt] gnome-shell: js::gc::TenuredCell::writeBarrierPre(js::gc::TenuredCell*)(): gnome-shell killed by SIGSEGV Original fix did not fix it. Another upstream fix (https://gitlab.gnome.org/GNOME/gjs/merge_requests/396) is available in COPR (https://copr.fedorainfracloud.org/coprs/frantisekz/gjs-mr396/). 6. python-blivet — https://bugzilla.redhat.com/show_bug.cgi?id=1804080 — NEW anaconda unable to finish installation with software raid partition We create the md array such that mdadm should auto-activate it after creation. Something a little weird happens with that, then blivet thinks the array is inactive right afterward, so it tries to activate it and mdadm complains that the devices are busy. 7. distribution — https://bugzilla.redhat.com/show_bug.cgi?id=1807342 — NEW Fedora 32 backgrounds not included It seems we don't have backgrounds for Fedora 32 yet. Fedora 32 KDE installs are currently using a generic upstream background, but Fedora 32 GNOME/Workstation installs are using the Fedora 31 background. Proposed blockers - 1. virt-manager — https://bugzilla.redhat.com/show_bug.cgi?id=1807768 — NEW NAT (Inactive) by default, cannot create a VM Default configuration of virtualization group on a clean install results in "dnsmasq: unknown user or group: dnsmasq" error when attempting to starting the network. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Build into < Rawhide side tag fails with "Package ... has already been built"
On Fri, 28 Feb 2020 at 16:17, Kevin Fenzi wrote: > On Fri, Feb 28, 2020 at 08:50:08AM +, Richard W.M. Jones wrote: > > On Thu, Feb 27, 2020 at 11:43:16AM -0800, Kevin Fenzi wrote: > > > On Thu, Feb 27, 2020 at 07:50:05PM +0100, Clement Verna wrote: > > > > On Thu, 27 Feb 2020 at 14:14, Richard W.M. Jones > wrote: > > > > > > > > > Despite earlier concerns, this does in fact appear to all be > working fine. > > > > > > > > > > > > > Yes requesting and building in the side tag should work just fine. > > > > > > > > > > > > > > > > > > There are now F32 builds going through for all OCaml packages in a > > > > > side tag, and when that's done I'll try to create a Bodhi update. > > > > > > > > > > > > > This is where you are going to have some problems, the deployed > version of > > > > Bodhi is not yet ready to support side tags for other release than > rawhide. > > > > A new release of Bodhi with that support should arrive soon tho. > > > > > > In the mean time, you can file a releng ticket when you are ready and > we > > > can retag all your builds from the side-tag into candidate so you can > > > make a update from them. :( Sorry for the hassle. > > > > I guess I should read my email more frequently :-( Because I > > created the update already before I read this email ... > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-7bddd7253f > > > > However it looks as if the update is fine - it was created without > > problems, contains the right builds and has the right Fedora version. > > So maybe we're fine after all? > > Yeah, seems ok from here... :) > Except it is not :-), all the builds are tagged in "f32-build-side-19863-testing-pending" instead of "f32-updates-testing-pending". So there are still in a side tag per say and they will not be merged into the normal "f32-updates-testing". Actually I am even surprised they got signed we must have some robosignatory configuration left over from when f32 was rawhide. > > kevin > ___ > 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: Non-responsive maintainer: pocock
Hi Daniel, I would like to add to Ankur's point: while I understand that many of us are doing Fedora work voluntarily and the expectations should be set accordingly, I believe we should be open to accept help when we realise that we cannot realistically commit enough time to the project. In case of asio, I have contacted you back in 2018 [1][2]. The pull request I have filed [3] has been opened since. The situation with asio right now is that Fedora with its asio-1.10.8 is not only behind arch and gentoo (both at 1.14.0), but also behind debian buster (at 1.12.2). Resiprocate, which is what was holding back asio update, has been retired due to FTBFS, then unorphaned at your request, and then retired again after being orphaned for 6+ weeks [4]. There has not been a successful build of resiprocate since 2016 [5]. Again, I perfectly understand that you have a backlog and that updating asio is not on top on your priority list. Being sceptical about co-maintainership offers seems counter-productive though, as there are things which need fixing and other people willing to step in. Best regards, Julian [1] https://bugzilla.redhat.com/show_bug.cgi?id=1551800#c2 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1638081#c2 [3] https://src.fedoraproject.org/rpms/asio/pull-request/1 [4] https://src.fedoraproject.org/rpms/resiprocate/commits/master [5] https://koji.fedoraproject.org/koji/packageinfo?packageID=15875 ___ 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
CPE Weekly: 2020-02-28
--- title: CPE Weekly status email tags: CPE Weekly, email --- # CPE Weekly: 2020-02-28 Background: The Community Platform Engineering group is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give. For better communication, we will be giving weekly reports to the CentOS and Fedora communities about the general tasks and work being done. Also for better communication between our groups we have created #redhat-cpe on Freenode IRC! Please feel free to catch us there, a mail has landed on both the CentOS and Fedora devel lists with context here. ## Fedora Updates * F32 Beta Freeze now on ### Data Centre Move * Old OpenStack instance has now been switched off. * The team are planning the shipping logistics of the equipment across country with Red Hat - measurements, weights, insurance amounts - fun stuff! :) * No changes to our expected dates as per our last posting, but if there are we will make sure to let you know asap. ### AAA Replacement Current functionalities developed to date: * User functionality to join groups * Uhange email address and password * Disable account function * Database access function * We are also currently mapping solution on how best to have users move from the current FAS to the new FAS (potential name incoming!). * The team also came to the end of developing our wireframes and mapping our user experience flow. * Unit tests were carried out regarding password controller and the current codebase. Patrick Uiterijk and Christian Heimes still continue to be a huge help to the team in this project so thank you both sincerely! For our full blog post, check out Ben Cottons weekly For more information regarding outstanding issues, please see here. To view our current scrum board, please see here. ### CI/CD * The team have made good progress on getting monitor-gating to run in staging * This is running completely now and while it fails in some steps but not because of itself, means it is already providing us valuable information :) * The team have sent an email to the devel list presenting our ideas and potential proposal for the changelog and release fields proof of concept - check it out here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FDARFS2KRWG7VAAPJYKJGUV6MEOH5P74/ ### Sustaining Team * Releng and Infra Freeze for Fedora 32 Beta is now, so if you need changes have them reviewed. * FMN is the main blocking point for the retirement of fedmsg, it is also running on an eol Fedora (28) and the team are working on replacing it. Check out their public thread here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LFQRNOBCD7OFD44GGXKLPR36EG55UK2Z/ ## Docs ### Misc Updates * Some packaging work to get pagure's dependencies added and built in EPEL8 (remaining: pygit2 and celery) were done this week * boot.fedoraproject.org and keys.fpo to wiki page has been retired * koji is being set up to have rhscl and rhdevtools for EPEL-7 * infra 8664 - newer kernel on aarch64-test machines. * infra 8369 - people css and html broken so a patch has been applied from new contributor and pushed out * Investigations into why fedora 32 branched compose was stuck & it was ostree signing. https://pagure.io/robosignatory/issue/44 https://pagure.io/pungi/issue/1350 * Broken epel8-testing update push was fixed and is now resumed * Rawhide compose failure was investigated https://pagure.io/releng/failed-composes/issue/1023 Was ceph. Filed https://bugzilla.redhat.com/show_bug.cgi?id=1805422 untagged it and refired compose. * Vagrant environment for mbbox was worked on https://github.com/fedora-infra/mbbox/pull/1 * Mbbox was moved to fedora-infra https://github.com/fedora-infra/mbbox * Jms-messaging-plugin PRs merged https://github.com/jenkinsci/jms-messaging-plugin/pull/169 https://github.com/jenkinsci/jms-messaging-plugin/pull/168 * Alternative “holistic heuristic” algorithm for computing releases was implemented https://pagure.io/Fedora-Infra/generate_changelog/pull-request/3 Common Python package, modules and misc cleanup https://pagure.io/Fedora-Infra/generate_changelog/pull-request/4 * Update and complete README was worked on https://pagure.io/Fedora-Infra/generate_changelog/pull-request/5 ## CentOS Updates ### CentOS * 5 updates for el8 * 3 updates for el7 * EPEL7 container image on quay.io for python-tox * Exploring fedora-infra jobs that can be containerized ### CentOS Stream * Composes are now automated * CentOS QA are now consuming compose in the test suite and running against CentOS Linux and Stream! * Building the contributor workflow is still ongoing and we will keep you updated when we make some progress on this As always, feedback is welcome, and we will continue to look at ways to improve th
Re: Tox automation in packaging macros
On 28. 02. 20 17:58, Adam Williamson wrote:
On Tue, 2020-01-14 at 01:29 +0100, Miro Hrončok wrote:
On 13. 01. 20 22:54, Adam Williamson wrote:
On Sun, 2020-01-12 at 23:24 +0100, Miro Hrončok wrote:
Please don't mention it as required or even necessarily recommended, as
it may not be. I intentionally set up my projects such that tox is
appropriate for upstream CI, not distribution package checking, and
intend distribution packages to run setup.py test.
The %tox macro runs the tests in current environment.
See https://github.com/fedora-python/tox-current-env/ for details.
It's not about the environment. It's about what they actually *do*. In
my projects, tox runs linters, coverage checks and unit tests; setup.py
test only runs unit tests. This is a convenient separation because I
find it appropriate to run linters and coverage checks on commits/PRs
for upstream, but there is no point in running them on package builds.
I agree with everything you said. Taking what we have, ideally we should
convince upstreams to only run tests with default toxenv, not linters.
We also don't have a tox-standard to only run offline testes etc. Maybe one
day...
At the same time, `setup.py test` is deprecated.
Sigh. Always nice when people deprecate perfectly well-working
workflows out from underneath you. :/
Right. Two things to consider:
- the deprecation period will most likely last forever
- setup.py files will eventually disappear anyway
So I looked into all of this stuff a bit last night. My conclusions so
far:
* It would be really nice if there were a short Idiot's Guide with a
sample project and RPM spec that puts everything together, as opposed
to me winding up with a browser full of tabs open to
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/tree/master and
https://www.python.org/dev/peps/pep-0517/ and
https://hynek.me/articles/sharing-your-labor-of-love-pypi-quick-and-dirty/
etc. Especially since...
This is all "beta" and provisional, but we'll write a guide once we finish the
%files section macros. In the meantime, see specs in
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/tests for
examples.
Yes, we could use some docs about this. No, we don't have them yet. There is
also:
[RFE] Documentation about pyproject.toml file
https://bugzilla.redhat.com/show_bug.cgi?id=1739847
* ...the Shiny New Stuff does not appear to be available on EPEL *at
all* yet - not even EPEL 8. This makes it a bit of a non-starter if you
want to use the same spec file bits across Fedora and EPEL. I realize
it may be impractical/impossible to backport everything to EPEL 7, and
am getting close to the point where I throw in the towel and drop
Python 2 support from my projects' master branches and hang the EPEL 7
package repos out on a branch, but EPEL 8 would be nice and ought to be
possible?
This stands in a way of having this in EPEL 8, AFAIK:
- no automatic RPM buildrequires
- ancient pip (PEP 517 support was added in 19.0, we have 9.0.3)
- ancient setuptools (40.8 is needed, we have 39.2.0)
- no tox (but it's being packaged for EPEL8 as we speak)
How are we supposed to do progress in Fedora when people dislike it when it is
not included in EPEL?
* Unless I'm missing something, what you suggested for tox - "ideally
we should convince upstreams to only run tests with default toxenv" -
actually seems weirdly difficult to implement. AFAIK none of the
official or unofficial tox docs I can find really cover the idea of
having an environment that's *defined* but is not *default*. It seems
to be virtually universal practice with tox that you put every
environment in `envlist`...and if you just run `tox` without any `-e`
argument or special env var, it runs every environment in `envlist`.
People seem to assume all environments will be default, and if you want
to run fewer than 'all of them' you filter with `-e` or whatever.
What I meant with "ideally we should convince upstreams to only run tests with
default toxenv, not linters" was this:
`tox -e py37` should only run tests
`tox -e py38` should only run tests
`tox -e py39` should only run tests
Linters should run in `tox -e lint`, or `tox -e py38-lint`.
%tox runs `tox -e py3X` by default.
I *did* figure out a way to do this, but it's something I never really
saw documented anywhere, and I eventually hit a roadblock with using it
in the CI setup I made. You have to make a `tox.ini` like this:
[tox]
envlist = py{27,36,37,38,39}
[testenv]
deps =
-r{toxinidir}/install.requires
-r{toxinidir}/tests.requires
ci: -r{toxinidir}/ci.requires
commands =
py.test
ci: py.test --cov-report term-missing --cov-report xml --cov openqa_client
ci: diff-cover coverage.xml --fail-under=90
ci: diff-quality --violations=pylint --fail-under=90
setenv =
PYTHONPATH = {toxinidir}
by having `ci` directives in `deps` and `commands` like that, you sort
of imply the existence of environments lik
Generate list of my packages
Can someone point me to a way to generate a list of non-retired packages that I am a maintainer on? Thanks. Hunting around for a "pagure cli" doesn't bring up much that seems active. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: Generate list of my packages
On Fri, 28 Feb 2020, Orion Poplawski wrote: Can someone point me to a way to generate a list of non-retired packages that I am a maintainer on? Thanks. Hunting around for a "pagure cli" doesn't bring up much that seems active. You could probably scrape it from here? https://src.fedoraproject.org/dashboard/projects 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: Generate list of my packages
Something like this should work: $ curl -o result.json 'https://src.fedoraproject.org/api/0/projects?owner=orion&per_page=100' $ jq : > > On Fri, 28 Feb 2020, Orion Poplawski wrote: > > > Can someone point me to a way to generate a list of non-retired packages > > that > > I am a maintainer on? Thanks. > > > > Hunting around for a "pagure cli" doesn't bring up much that seems active. > > You could probably scrape it from here? > > https://src.fedoraproject.org/dashboard/projects > - Thomas ___ 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: 20200228.n.0 changes
OLD: Fedora-32-20200227.n.0 NEW: Fedora-32-20200228.n.0 = SUMMARY = Added images:3 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 1 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 618.73 KiB Size of downgraded packages: 0 B Size change of upgraded packages: 31.32 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-32-20200228.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-32-20200228.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-32-20200228.n.0.iso = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: efivar-37-6.fc32 Old package: efivar-37-5.fc32 Summary: Tools to manage UEFI variables RPMs: efivar efivar-devel efivar-libs Size: 618.73 KiB Size change: 31.32 KiB Changelog: * Mon Feb 24 2020 Peter Jones - 37-6 - Pull in a bunch of patches from upstream. = 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: Tox automation in packaging macros
On Fri, 2020-02-28 at 20:42 +0100, Miro Hrončok wrote: > > > * ...the Shiny New Stuff does not appear to be available on EPEL *at > > all* yet - not even EPEL 8. This makes it a bit of a non-starter if you > > want to use the same spec file bits across Fedora and EPEL. I realize > > it may be impractical/impossible to backport everything to EPEL 7, and > > am getting close to the point where I throw in the towel and drop > > Python 2 support from my projects' master branches and hang the EPEL 7 > > package repos out on a branch, but EPEL 8 would be nice and ought to be > > possible? > > This stands in a way of having this in EPEL 8, AFAIK: > > - no automatic RPM buildrequires > - ancient pip (PEP 517 support was added in 19.0, we have 9.0.3) > - ancient setuptools (40.8 is needed, we have 39.2.0) > - no tox (but it's being packaged for EPEL8 as we speak) Yeep! I didn't realize we had such ancient bits in 8... > How are we supposed to do progress in Fedora when people dislike it when it > is > not included in EPEL? I assume there's an extra "not" here. On that assumption - I understand the problem, but if you check the history of my builds in EPEL, I'm definitely not in that group of people :P > > * Unless I'm missing something, what you suggested for tox - "ideally > > we should convince upstreams to only run tests with default toxenv" - > > actually seems weirdly difficult to implement. AFAIK none of the > > official or unofficial tox docs I can find really cover the idea of > > having an environment that's *defined* but is not *default*. It seems > > to be virtually universal practice with tox that you put every > > environment in `envlist`...and if you just run `tox` without any `-e` > > argument or special env var, it runs every environment in `envlist`. > > People seem to assume all environments will be default, and if you want > > to run fewer than 'all of them' you filter with `-e` or whatever. > > What I meant with "ideally we should convince upstreams to only run tests > with > default toxenv, not linters" was this: > > `tox -e py37` should only run tests > `tox -e py38` should only run tests > `tox -e py39` should only run tests > > Linters should run in `tox -e lint`, or `tox -e py38-lint`. > > %tox runs `tox -e py3X` by default. Ah, so essentially the scheme I suggested, but by 'default toxenv' you meant the default env *of %tox*, not the default for just calling `tox`? > > So in the end I gave up and wound up just making the `-ci` environments > > the defaults, explicitly declared in envlist, and figuring I'd have the > > spec file use `-e` to explicitly run the non-ci environments. > > That's what %tox does. yeah, I figured that one out later :) > Sorry but I cannot help you have nice new things if you decide to have old > things. You need to choose - backwards compatibility or new features. See above, I know which one I choose :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Generate list of my packages
On 2/28/20 1:04 PM, Scott Talbert wrote: On Fri, 28 Feb 2020, Orion Poplawski wrote: Can someone point me to a way to generate a list of non-retired packages that I am a maintainer on? Thanks. Hunting around for a "pagure cli" doesn't bring up much that seems active. You could probably scrape it from here? https://src.fedoraproject.org/dashboard/projects Thanks, but that's a pain and includes retired packages. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: Tox automation in packaging macros
On Fri, Feb 28, 2020 at 4:13 PM Adam Williamson wrote: > > On Fri, 2020-02-28 at 20:42 +0100, Miro Hrončok wrote: > > > > > * ...the Shiny New Stuff does not appear to be available on EPEL *at > > > all* yet - not even EPEL 8. This makes it a bit of a non-starter if you > > > want to use the same spec file bits across Fedora and EPEL. I realize > > > it may be impractical/impossible to backport everything to EPEL 7, and > > > am getting close to the point where I throw in the towel and drop > > > Python 2 support from my projects' master branches and hang the EPEL 7 > > > package repos out on a branch, but EPEL 8 would be nice and ought to be > > > possible? > > > > This stands in a way of having this in EPEL 8, AFAIK: > > > > - no automatic RPM buildrequires > > - ancient pip (PEP 517 support was added in 19.0, we have 9.0.3) > > - ancient setuptools (40.8 is needed, we have 39.2.0) > > - no tox (but it's being packaged for EPEL8 as we speak) > > Yeep! I didn't realize we had such ancient bits in 8... > Dynamic BuildRequires is unlikely to make it to RHEL 8, but all the others are achievable if the requests are made, right? -- 真実はいつも一つ！/ 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-20200228.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 22/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200227.n.0): ID: 529439 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/529439 ID: 529443 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/529443 ID: 529445 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/529445 Old failures (same test failed in Fedora-Rawhide-20200227.n.0): ID: 529403 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/529403 ID: 529405 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/529405 ID: 529429 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/529429 ID: 529460 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/529460 ID: 529483 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/529483 ID: 529484 Test: x86_64 universal install_blivet_lvmthin URL: https://openqa.fedoraproject.org/tests/529484 ID: 529486 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/529486 ID: 529488 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/529488 ID: 529489 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/529489 ID: 529498 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/529498 ID: 529499 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/529499 ID: 529506 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/529506 ID: 529511 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/529511 ID: 529514 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/529514 ID: 529527 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/529527 ID: 529539 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/529539 ID: 529546 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/529546 ID: 529547 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/529547 ID: 529552 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/529552 ID: 529553 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/529553 Soft failed openQA tests: 15/171 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20200227.n.0): ID: 529407 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/529407 ID: 529441 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/529441 Old soft failures (same test soft failed in Fedora-Rawhide-20200227.n.0): ID: 529381 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/529381 ID: 529382 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/529382 ID: 529384 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/529384 ID: 529386 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/529386 ID: 529389 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/529389 ID: 529390 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/529390 ID: 529410 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/529410 ID: 529473 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/529473 ID: 529482 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/529482 ID: 529500 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/529500 ID: 529535 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/529535 ID: 529538 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/529538 ID: 529545 Test: x
Re: Tox automation in packaging macros
On 28. 02. 20 22:12, Adam Williamson wrote: On Fri, 2020-02-28 at 20:42 +0100, Miro Hrončok wrote: * ...the Shiny New Stuff does not appear to be available on EPEL *at all* yet - not even EPEL 8. This makes it a bit of a non-starter if you want to use the same spec file bits across Fedora and EPEL. I realize it may be impractical/impossible to backport everything to EPEL 7, and am getting close to the point where I throw in the towel and drop Python 2 support from my projects' master branches and hang the EPEL 7 package repos out on a branch, but EPEL 8 would be nice and ought to be possible? This stands in a way of having this in EPEL 8, AFAIK: - no automatic RPM buildrequires - ancient pip (PEP 517 support was added in 19.0, we have 9.0.3) - ancient setuptools (40.8 is needed, we have 39.2.0) - no tox (but it's being packaged for EPEL8 as we speak) Yeep! I didn't realize we had such ancient bits in 8... Fedora 28 if I recall correctly :( How are we supposed to do progress in Fedora when people dislike it when it is not included in EPEL? I assume there's an extra "not" here. On that assumption - I understand the problem, but if you check the history of my builds in EPEL, I'm definitely not in that group of people :P Cool, sorry for that assumption, it sounded like not being available on EPEL is a show stopper. * Unless I'm missing something, what you suggested for tox - "ideally we should convince upstreams to only run tests with default toxenv" - actually seems weirdly difficult to implement. AFAIK none of the official or unofficial tox docs I can find really cover the idea of having an environment that's *defined* but is not *default*. It seems to be virtually universal practice with tox that you put every environment in `envlist`...and if you just run `tox` without any `-e` argument or special env var, it runs every environment in `envlist`. People seem to assume all environments will be default, and if you want to run fewer than 'all of them' you filter with `-e` or whatever. What I meant with "ideally we should convince upstreams to only run tests with default toxenv, not linters" was this: `tox -e py37` should only run tests `tox -e py38` should only run tests `tox -e py39` should only run tests Linters should run in `tox -e lint`, or `tox -e py38-lint`. %tox runs `tox -e py3X` by default. Ah, so essentially the scheme I suggested, but by 'default toxenv' you meant the default env *of %tox*, not the default for just calling `tox`? Sorry for confusing terms. I basically meant "default" being anything in the "native", "classic", "traditional", "ordinary" scheme of pyXY and non-default anything in the scheme of pyXY- or just . Sorry but I cannot help you have nice new things if you decide to have old things. You need to choose - backwards compatibility or new features. See above, I know which one I choose :P ack. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-32-20200228.n.0 compose check report
No missing expected images. Failed openQA tests: 25/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-32-20200227.n.0): ID: 529555 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/529555 ID: 529610 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/529610 ID: 529619 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/529619 ID: 529642 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background URL: https://openqa.fedoraproject.org/tests/529642 ID: 529713 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/529713 Old failures (same test failed in Fedora-32-20200227.n.0): ID: 529576 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/529576 ID: 529578 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/529578 ID: 529609 Test: x86_64 Workstation-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/529609 ID: 529612 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/529612 ID: 529626 Test: x86_64 KDE-live-iso desktop_background URL: https://openqa.fedoraproject.org/tests/529626 ID: 529633 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/529633 ID: 529656 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/529656 ID: 529659 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/529659 ID: 529661 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/529661 ID: 529662 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/529662 ID: 529671 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/529671 ID: 529672 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/529672 ID: 529679 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/529679 ID: 529684 Test: x86_64 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/529684 ID: 529687 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/529687 ID: 529700 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/529700 ID: 529712 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/529712 ID: 529719 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/529719 ID: 529720 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/529720 ID: 529725 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/529725 ID: 529726 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/529726 Soft failed openQA tests: 13/171 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-32-20200227.n.0): ID: 529554 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/529554 ID: 529557 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/529557 ID: 529559 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/529559 ID: 529562 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/529562 ID: 529563 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/529563 ID: 529583 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/529583 ID: 529614 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/529614 ID: 529646 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/529646 ID: 529655 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/529655 ID: 529673 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/529673 ID: 529708 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/529708 ID: 529711 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/529711 ID: 529718 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/529718 Passed openQA tests: 130/171 (x86_64) New passes (same test not passed in Fed
Re: Tox automation in packaging macros
On 28. 02. 20 22:21, Neal Gompa wrote: On Fri, Feb 28, 2020 at 4:13 PM Adam Williamson wrote: On Fri, 2020-02-28 at 20:42 +0100, Miro Hrončok wrote: * ...the Shiny New Stuff does not appear to be available on EPEL *at all* yet - not even EPEL 8. This makes it a bit of a non-starter if you want to use the same spec file bits across Fedora and EPEL. I realize it may be impractical/impossible to backport everything to EPEL 7, and am getting close to the point where I throw in the towel and drop Python 2 support from my projects' master branches and hang the EPEL 7 package repos out on a branch, but EPEL 8 would be nice and ought to be possible? This stands in a way of having this in EPEL 8, AFAIK: - no automatic RPM buildrequires - ancient pip (PEP 517 support was added in 19.0, we have 9.0.3) - ancient setuptools (40.8 is needed, we have 39.2.0) - no tox (but it's being packaged for EPEL8 as we speak) Yeep! I didn't realize we had such ancient bits in 8... Dynamic BuildRequires is unlikely to make it to RHEL 8, but all the others are achievable if the requests are made, right? How? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-32-20200228.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 1/8 (x86_64) New failures (same test not failed in Fedora-IoT-32-20200226.0): ID: 529729 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/529729 Soft failed openQA tests: 2/8 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-32-20200226.0): ID: 529727 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/529727 ID: 529728 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/529728 Passed openQA tests: 5/8 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: 1 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-94b32a0b\x2d41ce\x2d4b32\x2da60d\x2d31caa5376ca7.service 1 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-2316e2dd\x2d0eb3\x2d433c\x2dad01\x2df9e8f4417715.service Previous test data: https://openqa.fedoraproject.org/tests/528414#downloads Current test data: https://openqa.fedoraproject.org/tests/529727#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: 2 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-D1B6\x2d42AC.service, systemd-fsck@dev-disk-by\x2duuid-c5e8976c\x2dcaa0\x2d4d7e\x2dbf39\x2d50d51ac9272a.service 2 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-88A9\x2dA129.service, systemd-fsck@dev-disk-by\x2duuid-e4ec3be2\x2ddedf\x2d468b\x2d8f99\x2d185e4baca385.service Previous test data: https://openqa.fedoraproject.org/tests/528415#downloads Current test data: https://openqa.fedoraproject.org/tests/529728#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Tox automation in packaging macros
On Fri, 2020-02-28 at 23:06 +0100, Miro Hrončok wrote: > > > I assume there's an extra "not" here. On that assumption - I understand > > the problem, but if you check the history of my builds in EPEL, I'm > > definitely not in that group of people :P > > Cool, sorry for that assumption, it sounded like not being available on EPEL > is > a show stopper. It just makes things more complicated, as usual... A follow-up observation, btw: can we exclude things from pyproject_buildrequires ? (whether that's done at the level of the dynamic build generation process itself, or within the pyproject macro/tool I don't care - but I couldn't find any docs indicating it's possible at either level so far). I use setuptools-git for most of my projects. So in pyproject.toml I'm putting this: requires = ["setuptools>=40.6.0", "setuptools-git", "wheel"] because setuptools-git is needed *to produce the source distribution*, thus it is a 'requires' so far as PEP-517/518 are concerned. However, it's not a BuildRequires for a Fedora package, because a Fedora package build *starts* from the source distribution. It doesn't need to produce one. I think I ran into an earlier version of this problem when I tried to use setup_requires briefly, or something. It'd be nice to use pyproject_buildrequires, but it'd also be nice for it not to pull in something that isn't actually needed... another thing I just ran into while trying this stuff out: https://bugzilla.redhat.com/show_bug.cgi?id=1808601 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Tox automation in packaging macros
On 28. 02. 20 23:36, Adam Williamson wrote: On Fri, 2020-02-28 at 23:06 +0100, Miro Hrončok wrote: I assume there's an extra "not" here. On that assumption - I understand the problem, but if you check the history of my builds in EPEL, I'm definitely not in that group of people :P Cool, sorry for that assumption, it sounded like not being available on EPEL is a show stopper. It just makes things more complicated, as usual... A follow-up observation, btw: can we exclude things from pyproject_buildrequires ? (whether that's done at the level of the dynamic build generation process itself, or within the pyproject macro/tool I don't care - but I couldn't find any docs indicating it's possible at either level so far). You can patch/sed/etc. upstream metadata in %prep. The original idea is that if upstream metadata is wrong, it should be fixed in upstream, not in spec. I use setuptools-git for most of my projects. So in pyproject.toml I'm putting this: requires = ["setuptools>=40.6.0", "setuptools-git", "wheel"] because setuptools-git is needed *to produce the source distribution*, thus it is a 'requires' so far as PEP-517/518 are concerned. However, it's not a BuildRequires for a Fedora package, because a Fedora package build *starts* from the source distribution. It doesn't need to produce one. I see the problem, but I don't see a nice solution. I think I ran into an earlier version of this problem when I tried to use setup_requires briefly, or something. It'd be nice to use pyproject_buildrequires, but it'd also be nice for it not to pull in something that isn't actually needed... another thing I just ran into while trying this stuff out: https://bugzilla.redhat.com/show_bug.cgi?id=1808601 Keep them coming \o/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20200228.n.0 changes
OLD: Fedora-Rawhide-20200227.n.0 NEW: Fedora-Rawhide-20200228.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 5 Dropped packages:1 Upgraded packages: 192 Downgraded packages: 0 Size of added packages: 15.80 MiB Size of dropped packages:54.82 KiB Size of upgraded packages: 6.94 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -182.30 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: ghc-prettyprinter-ansi-terminal-1.1.1.2-2.fc33 Summary: ANSI terminal backend for the prettyprinter package RPMs:ghc-prettyprinter-ansi-terminal ghc-prettyprinter-ansi-terminal-devel ghc-prettyprinter-ansi-terminal-doc ghc-prettyprinter-ansi-terminal-prof Size:1020.96 KiB Package: perl-App-Packager-1.430.1-3.fc33 Summary: Abstract interface to a number of common packagers RPMs:perl-App-Packager Size:13.23 KiB Package: perl-Text-Layout-0.018.1-3.fc33 Summary: Pango style text formatting RPMs:perl-Text-Layout Size:35.70 KiB Package: sourcextractor++-0.8-1.fc33 Summary: A program that extracts a catalog of sources from astronomical images RPMs:sourcextractor++ sourcextractor++-devel sourcextractor++-doc Size:14.73 MiB Package: wsdd-0.5-2.fc33 Summary: Web Services Dynamic Discovery host daemon RPMs:wsdd Size:25.97 KiB = DROPPED PACKAGES = Package: python2-typing-3.7.4.1-2.fc32 Summary: Typing defines a standard notation for type annotations RPMs:python2-typing Size:54.82 KiB = UPGRADED PACKAGES = Package: GraphicsMagick-1.3.35-1.fc33 Old package: GraphicsMagick-1.3.34-2.fc32 Summary: An ImageMagick fork, offering faster image generation and better quality RPMs: GraphicsMagick GraphicsMagick-c++ GraphicsMagick-c++-devel GraphicsMagick-devel GraphicsMagick-doc GraphicsMagick-perl Size: 12.33 MiB Size change: -27.46 KiB Changelog: * Thu Feb 27 2020 Rex Dieter - 1.3.35-1 - 1.3.35 Package: alt-ergo-2.0.0-9.fc33 Old package: alt-ergo-2.0.0-8.fc32 Summary: Automated theorem prover including linear arithmetic RPMs: alt-ergo alt-ergo-gui Size: 34.09 MiB Size change: -35.12 KiB Changelog: * Wed Feb 26 2020 Richard W.M. Jones - 2.0.0-9 - OCaml 4.10.0 final. Package: annobin-9.10-1.fc33 Old package: annobin-9.09-1.fc33 Summary: Annotate and examine compiled binary files RPMs: annobin annobin-annocheck Size: 1.09 MiB Size change: 989 B Changelog: * Thu Feb 27 2020 Nick Clifton - 9.10-1 - Fix clang plugin to use hidden symbols. Package: apron-0.9.12-3.fc33 Old package: apron-0.9.12-2.fc32 Summary: Numerical abstract domain library RPMs: apron apron-devel japron ocaml-apron ocaml-apron-devel Size: 21.22 MiB Size change: -11.25 KiB Changelog: * Wed Feb 26 2020 Richard W.M. Jones - 0.9.12-3 - OCaml 4.10.0 final. Package: arm-trusted-firmware-2.2-5.fc33 Old package: arm-trusted-firmware-2.2-3.fc32 Summary: ARM Trusted Firmware RPMs: arm-trusted-firmware-armv8 Size: 136.01 KiB Size change: -7.57 KiB Changelog: * Tue Jan 28 2020 Fedora Release Engineering - 2.2-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Thu Feb 27 2020 Peter Robinson - 2.2-5 - Temporarily drop imx8q ATF Package: awscli-1.18.8-1.fc33 Old package: awscli-1.17.12-1.fc32 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.69 MiB Size change: 25.90 KiB Changelog: * Thu Feb 27 2020 Igor Raits - 1.18.8-1 - Update to 1.18.8 Package: beaker-27.2-1.fc33 Old package: beaker-27.1-1.fc32 Summary: Full-stack software and hardware integration testing system RPMs: beaker-client beaker-common Size: 240.72 KiB Size change: -224 B Changelog: * Thu Feb 27 2020 Martin Styk - 27.2-1 - Update to 27.2 (#1808021) Package: bitstream-vera-fonts-1.10-38.fc33 Old package: bitstream-vera-fonts-1.10-37.fc33 Summary: The Bitstream Vera font families RPMs: bitstream-vera-fonts-all bitstream-vera-sans-fonts bitstream-vera-sans-mono-fonts bitstream-vera-serif-fonts Size: 304.84 KiB Size change: 71 B Changelog: * Thu Feb 27 2020 Nicolas Mailhot - 1.10-38 ??? Switch fontconfig priority to 55 Package: brltty-6.0-13.fc33 Old package: brltty-6.0-12.fc32 Summary: Braille display driver for Linux/Unix RPMs: brlapi brlapi-devel brlapi-java brltty brltty-at-spi2 brltty-docs brltty-dracut brltty-espeak brltty-espeak-ng brltty-speech-dispatcher brltty-xw ocaml-brlapi python3-brlapi tcl-brlapi Size: 13.53 MiB Size change: 3.94 KiB Changelog: * Wed Feb 26 2020 Richard W.M. Jones - 6.0-13 - OCaml 4.10.0 final. Package: camorama-0.20.7-5.fc33 Old package: camorama-0.20.7-3.fc31 Summary: Gnome webcam viewer
dnsmasq: unknown user or group: dnsmasq
I'm trying to figure out more about what's causing this bug NAT (Inactive) by default, cannot create a VM https://bugzilla.redhat.com/show_bug.cgi?id=1807768 /etc/passwd on Rawhide installed some time before branch contains a dnsmasq user. But on a Fedora 32 system installed this week (after branch) there is no dnsmasq user in /etc/passwd. When trying to start the network in virt-manager, this is recorded [ 8116.089262] fmac.local dnsmasq[3678]: unknown user or group: dnsmasq [ 8116.089383] fmac.local dnsmasq[3678]: FAILED to start up [ 8116.090149] fmac.local libvirtd[3526]: internal error: Child process (VIR_BRIDGE_NAME=virbr0 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=/usr/libexec/libvirt_leaseshelper) unexpected exit status 1: dnsmasq: unknown user or group: dnsmasq So it seems like the dnsmasq user and group should exist, but I don't know what should be creating it. This package is installed dnsmasq-2.80-11.fc32.x86_64 -- 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: dnsmasq: unknown user or group: dnsmasq
On 2/28/20 3:52 PM, Chris Murphy wrote: dnsmasq: unknown user or group: dnsmasq So it seems like the dnsmasq user and group should exist, but I don't know what should be creating it. What does "id dnsmasq" give 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: dnsmasq: unknown user or group: dnsmasq
On Fri, Feb 28, 2020 at 7:31 PM Samuel Sieb wrote: > > On 2/28/20 3:52 PM, Chris Murphy wrote: > >dnsmasq: unknown user or > > group: dnsmasq > > > > > > So it seems like the dnsmasq user and group should exist, but I don't > > know what should be creating it. > > What does "id dnsmasq" give you? F32 $ id dnsmasq id: ‘dnsmasq’: no such user F31 $ id dnsmasq uid=987(dnsmasq) gid=987(dnsmasq) groups=987(dnsmasq) Maybe related to this? https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format -- 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: dnsmasq: unknown user or group: dnsmasq
On 2/28/20 9:37 PM, Chris Murphy wrote: F32 $ id dnsmasq id: ‘dnsmasq’: no such user F31 $ id dnsmasq uid=987(dnsmasq) gid=987(dnsmasq) groups=987(dnsmasq) Maybe related to this? https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format Possibly, but there's definitely a bug. You should probably also take this to the test list. ___ 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
Unretire python-dockerpty
I intend to unretire python-dockerpty, which was retired four weeks ago due to being orphaned. It is a dependency of docker-compose, which cannot build in f32 without it, and for which I'm the maintainer. I've submitted releng issue https://pagure.io/releng/issue/9288 ___ 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-20200229.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
