Re: f32-backgrounds
On Mon, Apr 20, 2020, at 5:56 AM, Paul Dufresne via devel wrote: > Le 20-04-17 à 09 h 09, Benson Muite a écrit : > > On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote: > > Elections for alternative wallpapers are currently open: > > https://apps.fedoraproject.org/nuancier/elections/ > > Please vote for ones that you like. > Is the default wallpaper the result of a vote, or only alternatives to > the default? These are alternatives to the default which can be easily enabled. Information on enabling a different wallpaper is at: https://fedoramagazine.org/install-supplemental-wallpapers/ Schedule for Fedora 33 is at: https://fedorapeople.org/groups/schedule/f-33/f-33-design-tasks.html Information on how the official wallpaper is produced can be found here: https://fedoraproject.org/wiki/Design#Fedora_Release_Wallpaper ___ 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: f32-backgrounds look like crap
Le 20-04-17 à 09 h 09, Benson Muite a écrit : On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote: Elections for alternative wallpapers are currently open: https://apps.fedoraproject.org/nuancier/elections/ Please vote for ones that you like. Is the default wallpaper the result of a vote, or only alternatives to the default? ___ 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: Fedpkg: (scratch)-build forked repo directly in Koji
On Mon, 20 Apr 2020 at 01:54, clime wrote: > > On Mon, 20 Apr 2020 at 01:33, Ondrej Nosek wrote: > > > > Thanks for answers, comment in the text follows. > > > > On Tue, Apr 14, 2020 at 12:16 PM clime wrote: > >> > >> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch wrote: > >> > > >> > > >> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a): > >> > > >> > TLDR: Is $SUBJ function reasonable to implement in fedpkg? > >> > > >> > Hi, > >> > > >> > some time ago, fedpkg issue tracker got a request [1] for method, that > >> > allows direct builds. That means without sending srpms via "--srpm" > >> > argument. Currently, user's changes can be built: > >> > > >> > fedpkg scratch-build --srpm > >> > > >> > This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends > >> > just (git) hash id to koji. But fedpkg needs modification to send a > >> > right hash id for user changes. Additionally, koji doesn't allow > >> > building hash ids from forked repos. > >> > > >> > > >> > Even if this was possible, that would also mean that the sources have to > >> > be uploaded into look-a-side cache. Then it very much depend what is the > >> > content of the PR. If I am building Ruby nightly snapshots, I don't > >> > think it is fair to pollute look-a-side cache with them and I am afraid > >> > this is not the only case. I wish we had a way to override the > >> > look-a-side cache somehow > >> > >> If I understand correctly, this would have to be done, if sources > >> changed only, right? I.e. if there is a change just in patch or a spec > >> file, the sources could be fetched from the main project. > > > > > > Yes, just sources (and eventually other binary files) are uploaded to > > lookaside cache. In the case of specfile and patches, there is no lookaside > > modification. Fork shares the same lookaside cache with the main project. > > Cool! > > > > >> > >> > >> Should there be a possibility to upload sources for a fork that would > >> then be moved to the main project when the pull request is merged? > > > > > > That sounds complicated to me and maybe it is not worth the intended > > result. Or I didn't find the right (easier) approach. ... New sources (and > > binaries) in fork need to be saved somewhere. > > - In a parallel lookaside (for forks) > > Yes, this is what I was thinking about. > > > - In git repo (omitting lookaside) > > During the merge, some trigger would move the sources to the main > > lookaside. This creates a new file hash(es). > > I don't think it creates new file hashes. I mean checksums of the > files should stay the same as the content stays the same, no? Maybe I > am omitting something. > > > And it would result in another commit done by a trigger. I think it is an > > unwanted situation. > > I think an additional commit should not be needed due to above. > > > Some pollution of lookaside seems inevitable. But it happens even now > > without possibility to take uploaded file back. > > Yes, that's true. > > --- > > I think the solution with fork-specific sources is mainly problematic. (somehow I managed to send the previous email prematurely) ...problematic (or might be problematic) because the forks can be created for other purposes than to create pull requests and then they can be also abandoned. So any sources that were uploaded for them would be there stuck probably forever. Maybe this is not that huge issue but something that should be considered. > > > > >> > >> > > >> > > >> > Vít > >> > > >> > > >> > The question to the community. Is reasonable to implement this way of > >> > building scratches? --srpm argument would still work as previously. > >> > > >> > There is a suggested PR for this here: [2]. It is not completed yet. > >> > > >> > Risks: > >> > * approach could confuse users. Users are used to work with fedpkg > >> > differently. > >> > * koji would have to allow these builds > >> > * more code complexity; currently there is a way how to reach your > >> > result even without this function > >> > > >> > Thanks > >> > Ondrej > >> > > >> > [1] https://pagure.io/fedpkg/issue/282 > >> > [2] https://pagure.io/fedpkg/pull-request/390 > >> > > >> > ___ > >> > 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/
Re: Fedpkg: (scratch)-build forked repo directly in Koji
On Mon, 20 Apr 2020 at 01:33, Ondrej Nosek wrote: > > Thanks for answers, comment in the text follows. > > On Tue, Apr 14, 2020 at 12:16 PM clime wrote: >> >> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch wrote: >> > >> > >> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a): >> > >> > TLDR: Is $SUBJ function reasonable to implement in fedpkg? >> > >> > Hi, >> > >> > some time ago, fedpkg issue tracker got a request [1] for method, that >> > allows direct builds. That means without sending srpms via "--srpm" >> > argument. Currently, user's changes can be built: >> > >> > fedpkg scratch-build --srpm >> > >> > This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends >> > just (git) hash id to koji. But fedpkg needs modification to send a right >> > hash id for user changes. Additionally, koji doesn't allow building hash >> > ids from forked repos. >> > >> > >> > Even if this was possible, that would also mean that the sources have to >> > be uploaded into look-a-side cache. Then it very much depend what is the >> > content of the PR. If I am building Ruby nightly snapshots, I don't think >> > it is fair to pollute look-a-side cache with them and I am afraid this is >> > not the only case. I wish we had a way to override the look-a-side cache >> > somehow >> >> If I understand correctly, this would have to be done, if sources >> changed only, right? I.e. if there is a change just in patch or a spec >> file, the sources could be fetched from the main project. > > > Yes, just sources (and eventually other binary files) are uploaded to > lookaside cache. In the case of specfile and patches, there is no lookaside > modification. Fork shares the same lookaside cache with the main project. Cool! > >> >> >> Should there be a possibility to upload sources for a fork that would >> then be moved to the main project when the pull request is merged? > > > That sounds complicated to me and maybe it is not worth the intended result. > Or I didn't find the right (easier) approach. ... New sources (and binaries) > in fork need to be saved somewhere. > - In a parallel lookaside (for forks) Yes, this is what I was thinking about. > - In git repo (omitting lookaside) > During the merge, some trigger would move the sources to the main lookaside. > This creates a new file hash(es). I don't think it creates new file hashes. I mean checksums of the files should stay the same as the content stays the same, no? Maybe I am omitting something. > And it would result in another commit done by a trigger. I think it is an > unwanted situation. I think an additional commit should not be needed due to above. > Some pollution of lookaside seems inevitable. But it happens even now without > possibility to take uploaded file back. Yes, that's true. --- I think the solution with fork-specific sources is mainly problematic. > >> >> > >> > >> > Vít >> > >> > >> > The question to the community. Is reasonable to implement this way of >> > building scratches? --srpm argument would still work as previously. >> > >> > There is a suggested PR for this here: [2]. It is not completed yet. >> > >> > Risks: >> > * approach could confuse users. Users are used to work with fedpkg >> > differently. >> > * koji would have to allow these builds >> > * more code complexity; currently there is a way how to reach your result >> > even without this function >> > >> > Thanks >> > Ondrej >> > >> > [1] https://pagure.io/fedpkg/issue/282 >> > [2] https://pagure.io/fedpkg/pull-request/390 >> > >> > ___ >> > 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 >> ___ >> 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@lis
Re: Fedpkg: (scratch)-build forked repo directly in Koji
Thanks for answers, comment in the text follows. On Tue, Apr 14, 2020 at 12:16 PM clime wrote: > On Tue, 14 Apr 2020 at 12:05, Vít Ondruch wrote: > > > > > > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a): > > > > TLDR: Is $SUBJ function reasonable to implement in fedpkg? > > > > Hi, > > > > some time ago, fedpkg issue tracker got a request [1] for method, that > allows direct builds. That means without sending srpms via "--srpm" > argument. Currently, user's changes can be built: > > > > fedpkg scratch-build --srpm > > > > This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends > just (git) hash id to koji. But fedpkg needs modification to send a right > hash id for user changes. Additionally, koji doesn't allow building hash > ids from forked repos. > > > > > > Even if this was possible, that would also mean that the sources have to > be uploaded into look-a-side cache. Then it very much depend what is the > content of the PR. If I am building Ruby nightly snapshots, I don't think > it is fair to pollute look-a-side cache with them and I am afraid this is > not the only case. I wish we had a way to override the look-a-side cache > somehow > > If I understand correctly, this would have to be done, if sources > changed only, right? I.e. if there is a change just in patch or a spec > file, the sources could be fetched from the main project. > Yes, just sources (and eventually other binary files) are uploaded to lookaside cache. In the case of specfile and patches, there is no lookaside modification. Fork shares the same lookaside cache with the main project. > > Should there be a possibility to upload sources for a fork that would > then be moved to the main project when the pull request is merged? > That sounds complicated to me and maybe it is not worth the intended result. Or I didn't find the right (easier) approach. ... New sources (and binaries) in fork need to be saved somewhere. - In a parallel lookaside (for forks) - In git repo (omitting lookaside) During the merge, some trigger would move the sources to the main lookaside. This creates a new file hash(es). And it would result in another commit done by a trigger. I think it is an unwanted situation. Some pollution of lookaside seems inevitable. But it happens even now without possibility to take uploaded file back. > > > > > > Vít > > > > > > The question to the community. Is reasonable to implement this way of > building scratches? --srpm argument would still work as previously. > > > > There is a suggested PR for this here: [2]. It is not completed yet. > > > > Risks: > > * approach could confuse users. Users are used to work with fedpkg > differently. > > * koji would have to allow these builds > > * more code complexity; currently there is a way how to reach your > result even without this function > > > > Thanks > > Ondrej > > > > [1] https://pagure.io/fedpkg/issue/282 > > [2] https://pagure.io/fedpkg/pull-request/390 > > > > ___ > > 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 > ___ > 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
git_release rpkg macro - help needed
Hello,
yesterday, I was updating documentation for rpkg macros
(https://docs.pagure.org/rpkg-util/macro_reference.html) and I noticed
that maybe, the behavior of git_release macro could be improved.
This is a bit long question because I need to describe some details...
intro
--
git_release macro is an rpkg macro that generates release in rpm spec
file from git history. More precisely, it reads the latest annotated
tag (which has N-V-R form) for a given package to know what is the
latest release number. That number is then rendered out when spec file
is being preprocessed. If RELEASE_BUMP environment variable is set,
this number is incremented by one and only then it is rendered out. In
spec file, usage of the macro looks like this:
Release: {{{ git_release }}}
Note that git_dir_release is actually the recommended form for use,
which functions the same in this context, however. So I am using
git_release to keep things simpler to explain.
Recently I have added prefix= parameter to the macro to be able to
specify git branch name as a release prefix. To give you the idea,
here are some examples of generated releases when prefix is used:
master.1, f32.3, epel8.2, ...
Currently, the macro header looks like this:
git_release name= prefix= pivot=
name - name of the package
prefix - static release prefix
pivot - dynamic release part which is being auto-incremented
problem
---
Now the thing is that there is also git_version macro, which is meant
to be used when you put spec file into upstream sources directly and
you want to dynamically derive Version from git history, not Release.
The header of the macro looks like this:
git_version name= lead= follow=
name - name of the package
lead - major version of the package (possibly multipart), assumed to
be manually incremented on API/ABI changes
follow - minor version number which is being auto-incremented
I am thinking I can make the interface of those macros (git_version
and git_release) the same. I.e. update git_release to also have lead=
and follow= input params instead of prefix= and pivot=. I was thinking
about it already several times but before there was no prefix= and I
didn't see the need to have more than one parameter for git_release
until
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MTH3YF2V3RRCQPJRU23GUZ2G3XYH2DKJ/,
that's why I kept them separate implementation-wise. But now it seems
they could be unified which would also simplify the code. The only
difference would be that git_version would work with V part of N-V-R
name of the latest tag and git_release would work with R part. Otherwise,
they would be the same.
It's not only that the names of parameters are different but also
behavior is currently slightly different. With lead= of git_version
macro, you can set it to empty string and it will cause that lead will
be parsed from the latest package tag as part of V until the last dot.
The thing after the last dot is then recognized as follow and it is
the dynamic part that can be auto-incremented.
If you, however, leave prefix empty for git_release, it will cause
that the whole R part will be recognized as pivot. But the problem is
that if release is multipart (i.e. it contains multiple dots), then
the pivot will not be a number and cannot be auto-incremented. If,
however, we inherit behavior from git_version for lead, then in case
of multipart release, only the last part (after the last dot) would be
recognized as pivot (or "follow" after renaming) and therefore
auto-incrementing would work.
In practice, it means that you can create several tags manually in the
beginning, e.g.:
git tag -a -m "alpha prerelease" pkg-1.0-f32.alpha
git tag -a -m "beta prerelease" pkg-1.0-f32.beta
(...this is only an artificial example, I know it does not conform to
guidelines for doing prereleases...)
and then create a final release tag:
git tag -a -m "first release" pkg-1.0-f32.1
and since this moment use the auto-incrementing functionality
(currently implemented by `rpkg tag`) because only "1" will be
identified as pivot/follow, not the whole "f32.1" string. This example
assumes you have the following in the spec file:
Release: {{{ git_release }}}
i.e. prefix is empty. If you used:
Release: {{{ git_release prefix=f32 }}}
or the new git_release_branched macro, it would work even now because
prefix "f32" would be stripped from the part being auto-incremented. I
would like to, however, optimize the git_release macro now so that I
don't need to change it later anymore. That's why I am asking you for help.
Could you, please, tell me:
1) if you see any problems with reusing the lead=, follow= scheme of
git_version for git_release too
2) if you see anything else that should be done so that git_release
can be used by packagers
3) anything else that is on your mind regarding this
Thank you
clime
P.S. in case, you would like to see the current code (it can be quite
hard to read if you don't do much bash)
Re: f32-backgrounds look like crap
> Well, I don't see how it makes sense to deliberately create a low-quality > image with no technical need (nor technical benefits such as size saving). I'd suggest it's for roughly the same reason that people still paint paintings when, nowadays, they could just take a photograph. I don't pretend to know much about art, but that seems to be pretty intrinsic to how it works. ___ 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: 20200419.n.0 changes
OLD: Fedora-Rawhide-20200418.n.0 NEW: Fedora-Rawhide-20200419.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 2 Dropped packages:2 Upgraded packages: 59 Downgraded packages: 0 Size of added packages: 17.95 MiB Size of dropped packages:2.64 MiB Size of upgraded packages: 5.12 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 27.67 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: golang-github-gohugoio-testmodbuilder-0-0.2.20200419git3e92b57.fc33 Summary: Some helper scripts used for Hugo testing RPMs:golang-github-gohugoio-testmodbuilder golang-github-gohugoio-testmodbuilder-devel Size:16.91 MiB Package: soapy-uhd-0.3.6-1.fc33 Summary: Soapy SDR plugins for UHD supported SDR devices RPMs:soapy-uhd Size:1.04 MiB = DROPPED PACKAGES = Package: nekobee-dssi-0.1.7-24.fc32 Summary: Acid sounds synthesizer RPMs:nekobee-dssi Size:1.21 MiB Package: phat-0.4.1-22.fc31 Summary: A collection of GTK+ widgets useful for audio applications RPMs:phat phat-devel phat-docs Size:1.43 MiB = UPGRADED PACKAGES = Package: SuperLU-5.2.1-9.fc33 Old package: SuperLU-5.2.1-8.fc32 Summary: Subroutines to solve sparse linear systems RPMs: SuperLU SuperLU-devel SuperLU-doc Size: 1.98 MiB Size change: -3.90 MiB Changelog: * Sat Apr 18 2020 Antonio Trande - 5.2.1-9 - Some minor fixes - Compile/execute Fortran tests and examples - Do not pack example's source code Package: bpython-0.19-1.fc33 Old package: bpython-0.18-5.fc32 Summary: Fancy curses interface to the Python interactive interpreter RPMs: python3-bpython python3-bpython-urwid Size: 343.31 KiB Size change: 3.95 KiB Changelog: * Sat Apr 18 2020 Terje Rosten - 0.19-1 - 0.19 Package: dotnet3.1-3.1.103-1.fc33 Old package: dotnet3.1-3.1.102-1.fc33 Summary: .NET Core Runtime and SDK RPMs: aspnetcore-runtime-3.1 aspnetcore-targeting-pack-3.1 dotnet dotnet-apphost-pack-3.1 dotnet-host dotnet-hostfxr-3.1 dotnet-runtime-3.1 dotnet-sdk-3.1 dotnet-sdk-3.1-source-built-artifacts dotnet-targeting-pack-3.1 dotnet-templates-3.1 netstandard-targeting-pack-2.1 Size: 597.98 MiB Size change: 382.35 KiB Changelog: * Thu Apr 09 2020 Chris Rummel - 3.1.103-1 - Update to .NET Core Runtime 3.1.3 and SDK 3.1.103 Package: dummy-test-package-crested-0-229.fc33 Old package: dummy-test-package-crested-0-217.fc33 Summary: Dummy Test Package called Crested RPMs: dummy-test-package-crested Size: 23.26 KiB Size change: 684 B Changelog: * Sat Apr 18 2020 packagerbot - 0-218 - rebuilt * Sat Apr 18 2020 packagerbot - 0-219 - rebuilt * Sat Apr 18 2020 packagerbot - 0-220 - rebuilt * Sat Apr 18 2020 packagerbot - 0-221 - rebuilt * Sat Apr 18 2020 packagerbot - 0-222 - rebuilt * Sat Apr 18 2020 packagerbot - 0-223 - rebuilt * Sat Apr 18 2020 packagerbot - 0-224 - rebuilt * Sat Apr 18 2020 packagerbot - 0-225 - rebuilt * Sat Apr 18 2020 packagerbot - 0-226 - rebuilt * Sat Apr 18 2020 packagerbot - 0-227 - rebuilt * Sun Apr 19 2020 packagerbot - 0-228 - rebuilt * Sun Apr 19 2020 packagerbot - 0-229 - rebuilt Package: dummy-test-package-gloster-0-248.fc33 Old package: dummy-test-package-gloster-0-236.fc33 Summary: Dummy Test Package called Gloster RPMs: dummy-test-package-gloster Size: 24.34 KiB Size change: 719 B Changelog: * Sat Apr 18 2020 packagerbot - 0-237 - rebuilt * Sat Apr 18 2020 packagerbot - 0-238 - rebuilt * Sat Apr 18 2020 packagerbot - 0-239 - rebuilt * Sat Apr 18 2020 packagerbot - 0-240 - rebuilt * Sat Apr 18 2020 packagerbot - 0-241 - rebuilt * Sat Apr 18 2020 packagerbot - 0-242 - rebuilt * Sat Apr 18 2020 packagerbot - 0-243 - rebuilt * Sat Apr 18 2020 packagerbot - 0-244 - rebuilt * Sat Apr 18 2020 packagerbot - 0-245 - rebuilt * Sun Apr 19 2020 packagerbot - 0-246 - rebuilt * Sun Apr 19 2020 packagerbot - 0-247 - rebuilt * Sun Apr 19 2020 packagerbot - 0-248 - rebuilt Package: dummy-test-package-rubino-0-229.fc33 Old package: dummy-test-package-rubino-0-217.fc33 Summary: Dummy Test Package called Rubino RPMs: dummy-test-package-rubino Size: 23.34 KiB Size change: 765 B Changelog: * Sat Apr 18 2020 packagerbot - 0-218 - rebuilt * Sat Apr 18 2020 packagerbot - 0-219 - rebuilt * Sat Apr 18 2020 packagerbot - 0-220 - rebuilt * Sat Apr 18 2020 packagerbot - 0-221 - rebuilt * Sat Apr 18 2020 packagerbot - 0-222 - rebuilt * Sat Apr 18 2020 packagerbot - 0-223 - rebuilt * Sat Apr 18 2020 packagerbot - 0-224 - rebuilt * Sat Apr 18 2020 packagerbot - 0-225 - rebuilt * Sat Apr 18 2020 packagerbot
Re: OCaml 4.11 prerelease in Rawhide (was: Re: ocaml-bisect-ppx and related updates)
I was asked by David how we do OCaml builds, and finally I've written it up: http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=blob;f=README TL;DR - it's hard! Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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
[SONAME bump] json-c-0.14 (libjson-c.so.4 -> 5)
Hello together, as json-c 0.14 has been released today, I'm going to push an updated package to Rawhide within the next days. Within that procedure I'll take care of all needed rebuilds. I don't expect any major FTBFS, since I've already added patches to the packages that needed. The patches have been submitted to upstream as well. The patches were about fixing FTBFS due to the removal of the defines for TRUE and FALSE, which have been (int)1 for TRUE and (int)0 for FALSE in the previous versions, in json-c. There is a COPR with builds against the bumped SONAME at [1]. gluster-block is currently FTBFS for some reason related to the glusterfs package [2]. The rebuilds need to be done in two stages, as the intercircular- dependency between systemd and cryptsetup needs to be broken first. This bootstrap cycle will happen in a side-tag and gets merged back to Rawhide in one shot to reduce churn as much as possible. Bootstrap cycle: 1. Build systemd in bootstrap mode, so it has no depency on cryptsetup 2. Chain-build: json-c : cryptsetup : systemd (bootstrap disabled) 3. Merge side-tag with Rawhide After the side-tag has been merged the following build-chains are rebuild in Rawhide directly: * gdal : postgis * libstorj : filezilla * libu2f-host libu2f-server : pam-u2f * riemann-c-client : syslog-ng * satyr : libdnf libreport : abrt google-compute-engine-oslogin subscription-manager xrootd : dmlite : lcgdm-dav The following packages are independent from each other and any other build-chain, and thus will be rebuild in individual builds on Rawhide after the side-tag has been merged: bind bluez bti clamav device-mapper-multipath fastd fcitx freeradius frr fwts gdcm gfal2 girara gluster-block igt-gpu-tools libmypaint libmypaint2 libstorj libverto-jsonrpc libvmi mpris-scrobbler mraa nbd- runner ndctl newsbeuter newsboat opae openhpi opensips rpminspect rpm- ostree strongswan sway systemtap tlog tpm2-tss trace-cmd zmap The whole rebuild will likely not take longer than a few hours, except for the gdal : postgis chain, as gdal . The following packages are affected: * abrt * bind * bluez * bti * clamav * cryptsetup * device-mapper-multipath * dmlite * fastd * fcitx * filezilla * freeradius * frr * fwts * gdal * gdcm * gfal2 * girara * gluster-block * google-compute-engine-oslogin * igt-gpu-tools * lcgdm-dav * libdnf * libmypaint * libmypaint2 * libreport * libstorj * libu2f-host * libu2f-server * libverto-jsonrpc * libvmi * mpris-scrobbler * mraa * nbd-runner * ndctl * newsbeuter * newsboat * opae * openhpi * opensips * pam-u2f * postgis * riemann-c-client * rpminspect * rpm-ostree * satyr * strongswan * subscription-manager * sway * syslog-ng * systemtap * tlog * tpm2-tss * trace-cmd * xrootd * zmap Cheers Björn [1] https://copr.fedorainfracloud.org/coprs/besser82/json-c-test [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=43532093 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3dist provides
On Sun, Apr 19, 2020 at 10:00 AM Miro Hrončok wrote: > On 19. 04. 20 17:49, Miro Hrončok wrote: > > On 19. 04. 20 17:09, Miro Hrončok wrote: > >> I'll send a PR shortly. > > Finishing the commit message... > > https://src.fedoraproject.org/rpms/python-nb2plots/pull-request/2 Thank you! -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3dist provides
On 19. 04. 20 17:49, Miro Hrončok wrote: On 19. 04. 20 17:09, Miro Hrončok wrote: Anyway, now that I know what the immediate problem is, I'll try to work around it. Regards, I'll send a PR shortly. Finishing the commit message... https://src.fedoraproject.org/rpms/python-nb2plots/pull-request/2 -- 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 compose report: 20200419.n.0 changes
OLD: Fedora-32-20200418.n.0 NEW: Fedora-32-20200419.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3dist provides
On 19. 04. 20 17:09, Miro Hrončok wrote:
Anyway, now that I know what the immediate problem is, I'll try to
work around it. Regards,
In this particular case the version is trying to be read from git, I recommend
using %autosetup -S git and creating a %{version} tag in %prep.
I'll send a PR shortly.
OK. I've tired the usual:
%prep
...
git commit -q -a -m "rpmbuild %prep" --author "%{__scm_author}"
git tag -a -m '%{version} from rpmbuild' %{version}
But it is not that simple. The "versioneer" thing used here tries to read and
parse (or execute?) the nb2plots/_version.py file. The file has gitattributes
variables in it and git(hub) substitutes those with real values when the git
archive tarball is created. Hence any git-like voodoo in prep doesn't really
change that :(
I am afraid that sedding/patching the file is the only sane way forward.
Replacing
git_refnames = " (HEAD -> master)"
with
git_refnames = " (tag: 0.6)"
gets the job done.
Finishing the commit message...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3dist provides
On 19. 04. 20 16:39, Jerry James wrote:
On Sun, Apr 19, 2020 at 2:11 AM Miro Hrončok wrote:
Correction, this is valid:
https://www.python.org/dev/peps/pep-0440/#local-version-identifiers
But in this package case, we don't want version 0, so valid, but wrong.
Followup on the generator problem:
https://github.com/rpm-software-management/rpm/issues/1183
- the traceback should say: Cannot process Python package version: 0+unknown
- the build should abort on errors
- the version is actually valid
Thanks for the detective work, Miro. I wish this upstream would just
release a new version.
Anyway, now that I know what the immediate problem is, I'll try to
work around it. Regards,
In this particular case the version is trying to be read from git, I recommend
using %autosetup -S git and creating a %{version} tag in %prep.
I'll send a PR shortly.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3dist provides
On Sun, Apr 19, 2020 at 2:11 AM Miro Hrončok wrote: > Correction, this is valid: > > https://www.python.org/dev/peps/pep-0440/#local-version-identifiers > > But in this package case, we don't want version 0, so valid, but wrong. > > > Followup on the generator problem: > > https://github.com/rpm-software-management/rpm/issues/1183 > > - the traceback should say: Cannot process Python package version: 0+unknown > - the build should abort on errors > - the version is actually valid Thanks for the detective work, Miro. I wish this upstream would just release a new version. Anyway, now that I know what the immediate problem is, I'll try to work around it. Regards, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: f32-backgrounds look like crap
On Sun, Apr 19, 2020 at 10:13 AM Kevin Kofler wrote: > > after a few particularly unflattering ones had been selected: inside > jokes (and one that also happened to offend all Hindus, vegetarians, and > vegans at once), I happen to be offended by that slight of offense! /s Seriously, as a member of one of those groups (not saying which one!), I thought Beefy Miracle was an awesome name. Heck, the whole theme was made by a vegetarian (Will Woods)! -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: f32-backgrounds look like crap
Adam Williamson wrote: > On Fri, 2020-04-17 at 15:13 -0400, Neal Gompa wrote: >> And to Michael's point about Ubuntu's branding, they have a set of >> design principles that they use to simultaneously present "Ubuntu" and >> the Ubuntu "release" by leveraging their codename scheme and imbuing >> it in the artwork in creative ways. That's not a thing we do in Fedora >> anymore... :( > > None of this is free, it needs people to show up and do the work. Just > as with coding or package management, there is very little value in > saying "boy, I sure wish someone else would do all this cool stuff I've > thought of". If you want it to happen, get together with like-minded > folks and do it... Well, this is not a manpower issue. It was a deliberate decision to remove the Fedora logo from the wallpaper, in order to make life easier for Remix distributions. It was also a deliberate decision to discontinue release names, after a few particularly unflattering ones had been selected: inside jokes (and one that also happened to offend all Hindus, vegetarians, and vegans at once), villains, even a reference to a certain kind of software bugs! These decisions (which were made for a reason, as you can see) are why the Fedora artists can no longer employ this pattern for their wallpapers, not any kind of lack of manpower. 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: f32-backgrounds look like crap
Adam Williamson wrote: > for instance, the halftoning is a choice Well, I don't see how it makes sense to deliberately create a low-quality image with no technical need (nor technical benefits such as size saving). 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
Fedora-Cloud-31-20200419.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: Unannounced SONAME bump: libxc.so.5 → libxc.so.9
On Saturday, 18 April 2020 at 15:23, Fabio Valentini wrote: > On Sat, Apr 18, 2020 at 3:22 PM Fabio Valentini wrote: > > > > Hi everybody, > > > > The latest rawhide update of libxc (5.0.0) bumped the SONAME as > > mentioned in $SUBJECT. > > > > None of the depending packages have been rebuilt against this version: > > > > - cp2k > > - elk > > - gpaw > > - psi4 > > - python-pyscf > > - votca-xtp > > > > Affected maintainers added to CC. > > > > Fabio > > Oh, sorry - it turns out, this *was* announced two weeks ago, but the > necessary rebuilds have just not happened at all. It was, but maintainers were not copied and affected package names were not mentioned in the e-mail. I didn't think much of it at the time because I don't keep the dependency trees of my packages in my head. I'll take care of cp2k. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.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: f32-backgrounds look like crap
Hello everyone! I specially love this one: https://fedoraproject.org/wiki/File:Sky-background3-c.png Shame it's so small. I don't feel like my screen is broken. While I'm not a big fan of squares and similar background, I did appreciate the retro style. I didn't assume there was something wrong but that it was intended. There's a different between crap/broken and artistic choice. Kind regards, Lailah On Fri, 17 Apr 2020 at 16:09, Kamil Paral wrote: > On Fri, Apr 17, 2020 at 2:51 PM Leigh Scott > wrote: > >> If there any plan to fix them? >> >> >> https://leigh123linux.fedorapeople.org/pub/screenshots/Screenshot%20from%202020-04-17%2013-32-22.png > > > When I updated, I honestly thought that my graphics drivers were broken. I > don't think that's a positive outcome. I think the previous version > (differently colored, without such heavy dithering) was better. This one > looks like a picture with jpeg quality 30. > > I'm disappointed with default wallpapers in the latest releases. I wonder > if we could go back to more artistic images from previous releases? Here > are some of my favorite ones: > https://fedoraproject.org/wiki/Wallpapers#Fedora_29 > https://fedoraproject.org/wiki/Wallpapers#Fedora_27 > https://fedoraproject.org/wiki/Wallpapers#Fedora_21 > https://fedoraproject.org/wiki/Wallpapers#Fedora_16 > https://fedoraproject.org/wiki/Wallpapers#Fedora_15 > https://fedoraproject.org/wiki/Wallpapers#Fedora_11 > https://fedoraproject.org/wiki/Wallpapers#Fedora_7 > > Especially the one in Fedora 15 (GNOME edition) and 16 was outstanding. > Can we do more of those, please? > > ___ > 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
Fedora-Cloud-30-20200419.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: python3dist provides
On 19. 04. 20 10:05, Miro Hrončok wrote: On 19. 04. 20 9:51, Miro Hrončok wrote: On 19. 04. 20 2:16, Jerry James wrote: What generates the python3dist(module) provides? I ask because I did a build of python-nb2plots today for which those provides were not generated: https://koji.fedoraproject.org/koji/buildinfo?buildID=1495361 even though they were for the previous build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1449952 although with questionable values: python3.8dist(nb2plots) = 0+unknown python3dist(nb2plots) = 0+unknown This: https://src.fedoraproject.org/rpms/python-rpm-generators/blob/master/f/pythondistdeps.py https://src.fedoraproject.org/rpms/python-rpm-generators/blob/master/f/pythondist.attr Let me try to debug it. My first rough idea is: The version in upstream metadata is not valid. Downstream (dep generator): ...snip... Upstream (invalid version): Correction, this is valid: https://www.python.org/dev/peps/pep-0440/#local-version-identifiers But in this package case, we don't want version 0, so valid, but wrong. Followup on the generator problem: https://github.com/rpm-software-management/rpm/issues/1183 - the traceback should say: Cannot process Python package version: 0+unknown - the build should abort on errors - the version is actually valid -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Assimp soname bump
Please, let me rebuild Pioneer before pushing. I need newer `assimp` src package. On 19/04/20 02:16, Rich Mattes wrote: > Hi, > > I plan to update assimp from 3.3.1 to the latest release (5.0.1) in > rawhide this week. The following packages will be affected: > > fawkes-0:1.3.0-11.fc33.src > mrpt-0:1.4.0-17.fc33.src > pioneer-0:20200203-1.fc33.src > vkmark-0:2017.08-0.8.20180123git68b6f23.fc32.src > > I will take care of the rebuilds and any fallout/updates that need to > happen. > > Rich -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python3dist provides
On 19. 04. 20 9:51, Miro Hrončok wrote:
On 19. 04. 20 2:16, Jerry James wrote:
What generates the python3dist(module) provides? I ask because I did
a build of python-nb2plots today for which those provides were not
generated:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1495361
even though they were for the previous build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1449952
although with questionable values:
python3.8dist(nb2plots) = 0+unknown
python3dist(nb2plots) = 0+unknown
This:
https://src.fedoraproject.org/rpms/python-rpm-generators/blob/master/f/pythondistdeps.py
https://src.fedoraproject.org/rpms/python-rpm-generators/blob/master/f/pythondist.attr
Let me try to debug it.
My first rough idea is:
The version in upstream metadata is not valid.
Downstream (dep generator):
Before the latest update, it generated something, now it fails.
The behavior with invalid versions is not well defined.
The log says:
Traceback (most recent call last):
File "/usr/lib/rpm/pythondistdeps.py", line 379, in
spec_list.append(convert(name, spec[0], spec[1]))
File "/usr/lib/rpm/pythondistdeps.py", line 125, in convert
return OPERATORS[operator](name, operator, version_id)
File "/usr/lib/rpm/pythondistdeps.py", line 79, in convert_equal
return '{} = {}'.format(name, version)
File "/usr/lib/rpm/pythondistdeps.py", line 47, in __str__
while self.version[-1] == 0:
IndexError: list index out of range
I wonder if RPMbuild should fail in that case :/
Upstream (invalid version):
The versioneer.py file in the project root seem to not handle this well with git
snapshots.
From /usr/lib/python3.8/site-packages/nb2plots-0+unknown-py3.8.egg-info/PKG-INFO
Version: 0+unknown
--
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
[Bug 1825443] perl-MooseX-Storage-0.53 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1825443 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-MooseX-Storage-0.53-1. ||fc33 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-04-19 08:06:31 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1495449 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
[Bug 1825054] perl-Struct-Dumb-0.11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1825054 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Struct-Dumb-0.11-1.fc3 ||3 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-04-19 08:05:51 --- Comment #2 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1495451 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org
Re: python3dist provides
On 19. 04. 20 2:16, Jerry James wrote: What generates the python3dist(module) provides? I ask because I did a build of python-nb2plots today for which those provides were not generated: https://koji.fedoraproject.org/koji/buildinfo?buildID=1495361 even though they were for the previous build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1449952 although with questionable values: python3.8dist(nb2plots) = 0+unknown python3dist(nb2plots) = 0+unknown This: https://src.fedoraproject.org/rpms/python-rpm-generators/blob/master/f/pythondistdeps.py https://src.fedoraproject.org/rpms/python-rpm-generators/blob/master/f/pythondist.attr Let me try to debug it. -- 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
