Re: RFE: automatically enable rpmlint gating test for packages with a foo.rpmlintrc
Excellent suggestion! In fact, as part of the CI Objective we want to enable more such distribution-wide tests, such as rpminspect [0], installability and reverse dependency testing. The tests that have been run by Fedora QA are also being evaluated and those will be used directly or migrated. At flock yesterday we had some good discussions on how to make opt-in more accessible, and I'm sure the Fedora CI SIG will take your suggestions into consideration. We all agree the current way of doing it isn't quite optimal. :) Stay tuned in the coming weeks to hear more about how to opt into gating! Thanks, -Dominik [0] https://github.com/dcantrell/rpminspect On Sat, Aug 10, 2019 at 9:59 PM Hans de Goede wrote: > Hi All, > > So what I've been reading from the rawhide gating mailthread, > creating the gating rules unfortunately is somewhat convoluted / > involved. > > As such I was wondering if maybe it is an idea to automatically > enabled the rpmlint gating test for packages which have a > .rpmlint rc. ? > > Alternatively a wiki page with gating confif snippets, mirroring > how have a wiki page for specfile scriptlet snippets, might be a > good idea. I would like to opt in to test-gating where possible, > esp. with the rpmlint tests, but I do not have a lot of time to > spend on this. More in general I believe that the easier this > is made to use, the better chances are that people will actually > use this. > > Regards, > > Hans > ___ > 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: Orphaned some (mostly Python) packages
Hi Miro, On Wed, 7 Aug 2019 at 07:21, Miro Hrončok wrote: > > # python-behave > Leaf. > Doesn't build yet with Python 3.8, but a patch exists: > https://bugzilla.redhat.com/show_bug.cgi?id=1706085 > > > # python-cligj > python-rasterio and python-fiona depend on that. > I can take this one, since my packages depend on it. > > # python-coverage_pth > python-pytest-testmon depends on that. > > > # python-jeepney > python-SecretStorage -> python-keyring depends on that. > > > # python-pathtools > Needed by: >python-sphinx-autobuild >python-watchdog >python-Lektor >python-pytest-watch > > > # python-pep8 > BuildRequired by many, but they have been warned: > https://bugzilla.redhat.com/show_bug.cgi?id=1667200 > Switch to python-pycodestyle or better stop linting in %check. > > > # rpmlint-scl-config > Leaf. Packaged long time ago and never touched since. > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok -- Elliott ___ 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: Please sweep bodhi updates to testing in a timely manner
> But there's not anything actually wrong anymore?\ >I'm not sure what else you would like me to do here...>kevin Yeah it's all good now -- f30 and f29 are all in testing now. Thanks for checking.Phil___ 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: Please sweep bodhi updates to testing in a timely manner
On 8/10/19 5:34 PM, Philip Kovacs via devel wrote: > UTC 00:00:00 has come and gone and nothing was pushed to testing, yet again. Updates pushes are not instant. You shouldn't expect them all to finish at 00:00:01. They did indeed fire off as expected at 00:00 and finished some hours later, as they always do. > My reference to "7 days" was the time I have to wait until I can request >stable.That timer cannot start until the packages hit testing. ok > There really should be more than one guy who happens to be at a > conferencetaking care of this. But there's not anything actually wrong anymore? I'm not sure what else you would like me to do here... kevin 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: Why retire Python 2 packages and games that still work to end user ?
Nico Kadel-Garcia wrote: > Maintaining python 2 requires maintaining a *lot* of infrastructure. What kind of infrastructure do you need to maintain a package that is (will be) no longer updated upstream? This takes almost no work. The only thing to do is to backport some security fixes from Python 3, and occasionally to fix FTBFS bugs. Now if your concern is maintaining all the python2-* packages, then there ought to be some middle ground between maintaining all of them including ones that are not used by anything in Fedora anymore, and just dropping all of them (with or without the planned exception process, whose usefulness depends entirely on how willing FESCo will be to approve the requests). Maybe the set of python2-* modules in EL7 or EL8, with or without EPEL, minus the ones already retired from Fedora by now, would be a reasonable starting point? I also think that there ought to be more cooperation from the maintainers of individual python2-* modules. The approved Fedora 31 Change makes it way too easy for maintainers to just drop Python 2 support for no reason. If upstream dropped Python 2 support from the current version and so an old version has to be packaged specifically for Python 2, that is one good reason to require somebody else to pick up maintenance, but as it stands, no such reason is required and Fedora maintainers can arbitrarily drop Python 2 support from their Python modules even if upstream still supports it. This is just pointless and unhelpful. We can try to find people to pick up python2 and a bunch of python2-* modules, but expecting the python2 maintainer(s) to sign up for maintaining each and every python2-* module is unreasonable and unrealistic. Even if several of them will also be dead upstream (at least the version that works with Python 2) and thus require very little maintenance effort. > To support multiple pythons, python26, python28 if it ever happens, > python36 python38 when it comes out. The whole reason for this discussion is that Python 2.8 will likely never happen. It definitely will not happen from Python upstream. Otherwise, there would not be all this talk about dropping Python 2 due to being unsupported upstream. I don't see much point in supporting Python 2.6, which is even more ancient than Python 2.7, and 2.7 is backwards-compatible with 2.6. And supporting multiple versions is not an argument for not having at least a python2 symlink and Provides: python2 in python27. > Simply replacing the "python2" line iwth "python27" is not a difficent > edit in most source code. But it is still a completely unnecessary edit. 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: Orphaning cloud-init, python-boto
I'll take python-goto. FAS: limb. Sent from ProtonMail mobile Original Message On Aug 10, 2019, 8:06 PM, Garrett Holmstrom wrote: > Hi, > > My time to work on Fedora cloud-related things has diminished in > recent months, so I have not been able to give the cloud-init and > python-boto packages the care they deserve. They are free to a good > home. > > Thanks, > -- > Garrett Holmstrom > ___ > 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
Orphaning cloud-init, python-boto
Hi, My time to work on Fedora cloud-related things has diminished in recent months, so I have not been able to give the cloud-init and python-boto packages the care they deserve. They are free to a good home. Thanks, -- Garrett Holmstrom ___ 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: Please sweep bodhi updates to testing in a timely manner
UTC 00:00:00 has come and gone and nothing was pushed to testing, yet again. My reference to "7 days" was the time I have to wait until I can request stable.That timer cannot start until the packages hit testing. There really should be more than one guy who happens to be at a conferencetaking care of this. On Saturday, August 10, 2019, 04:40:31 PM EDT, Kevin Fenzi wrote: On 8/10/19 11:33 AM, Philip Kovacs via devel wrote: > Just look at the updates pending pages. Here are f30 and f29, resp: > https://bodhi.fedoraproject.org/updates/?releases=F30&status=pending > https://bodhi.fedoraproject.org/updates/?releases=F29&status=pending Updates are pushed every single day at 00:00UTC. However, todays failed because there were some unsigned packages. (This is caused by updates that stay in updates testing for a long time and their signed copies get grabage collected). I fixed that and finished the broken push, but I am at flock and didn't have time to start a full push. One should fire off in about 3 hours... There should never be an update that waits 7 days to push to testing... kevin -- > On Saturday, August 10, 2019, 02:29:24 PM EDT, Stephen John Smoogen > wrote: > > > > On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel > wrote: > > Why does it take days sometimes just to start the 7 day timer? > > Can we have some examples to track this down? Because without that.. no idea > and no way to fix. > > ___ > 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
Re: Package removal for FTBFS: Add automatic orphaning?
On Sat, Aug 10, 2019 at 7:33 PM Miro Hrončok wrote: > > On 11. 08. 19 0:34, Kevin Kofler wrote: > > Miro Hrončok wrote: > >> Obviously, we can prevent this by only orphaning packages with NEW bugz, > >> but that doesn't really solve anything, because lot of the retired > >> packages were actually ASSIGNED/POST/MODIFIED (for months). > > Of course they were, to prevent you from retiring them even sooner. > > If the only reason to set the status to ASSIGNED/POST/MODIFIED is to prevent > **me** from retiring the package, something is fundamentally broken. > > If somebody has a legitimate reason to have a FTBFS package not retired, they > can ask for some kind of exception from Releng, not provide inaccurate > information. > I was actually trying to work on some of mine... one of the FTBFS (thrift) I had was actually because of an optional python2-only component from upstream I was intending to disable once F31 was released, if I couldn't recruit a python person to help me fix it (because I don't know python). But, the entire package was retired anyway it was *very* much unexpected for me, because I thought I'd have some more time to patch it once F31 came out (the package in F30 is fine... and I don't care about rawhide... I care about the latest version of Fedora that people are actually using). Several other packages I had were Java packages that I was still trying to figure out the state of their BuildRequires which were in modules. The last I read on this list was "there may be some news about that"... and then *bam* RETIRED... at least one I know for sure was marked ASSIGNED. At least one of these I had fixed the FTBFS once, but then it broke again, so I left the same issue open until I could fix that one also... but it also was retired. This FTBFS policy is *TOO* aggressive, and very unfriendly to casual packagers, and at a time of significant disruption in Fedora due to modularity. There should be some extra leniency for a few versions while the dust from modularity settles, and it *definitely* should be orphaned first if the maintainer isn't responding to FTBFS bugs. There's so much disruption going on in Fedora right now... things are moving too quickly for casual packagers, and it seems like a lot of it is behind the scenes, motivated by internal interests of RedHat, and *not* what is in the best interests of the community. It was *not* the right time to forcibly retire hundreds of packages while these changes are occurring. Many of these broken packages are probably because casual maintainers like me are struggling to keep up with the changes. Instead, now is the time to apply more mentoring, and leadership to assist those packagers get things in order, to figure out how to get those packages into appropriate modules, as needed, to assist in patching for python3, to help them take orphaned BRs, etc. This sends a very bad message, something along the lines of "only hard-core, full-time, dedicated packagers allowed; you're on your own and if you can't get things working in Fedora, you're out". Also, I have a question about retirement as it pertains to modularity: let's say a package was retired because its BRs moved into modules but now the only way to get the BRs (short of packaging all the java stuff myself) is to put it in a module. Can I do this for a retired package? Does ursine packages have to be un-retired in order to create a module? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Why retire Python 2 packages and games that still work to end user ?
On Sat, Aug 10, 2019 at 7:47 PM Kevin Kofler wrote: > > Sérgio Basto wrote: > > Why we would retire childsplay or gcompris or gdesklets ? IMHO we still > > haven't a replacement . > > > > From [1] I strongly disagree with the text, why all python 2 packages > > will be removed automatically and why I would have a lot of work if I > > want keep one package alive . why not the opposite ? . > > Python 3 it isn't even the default why such hurry to drop python 2 at > > all , when we still have epel 7 with python 2 ... > > > > My opinion at least postpone this decision one or two releases to > > Fedors 33/34 , many things still just work with python 2 . > > I second that wholeheartedly. > > This change is just not implementable as it stands. Way too much upstream > software still depends on Python 2. (In fact, I am not even convinced that > it can be implemented as stated, ever, without dropping huge parts of Fedora > and making it useless for a wide number of users. But what is sure is that > it definitely cannot implemented without huge fallout in time for Fedora > 32.) Maintaining python 2 requires maintaining a *lot* of infrastructure. > I also completely fail to see what value the rename from python2 to python27 > (yet another one, after the already pointless rename from python to python2) > will bring to our users. But the worst part is the required FESCo exception > approval for every single remaining Python 2 package, along with loads of > bureaucracy that many packages will be unable to comply with (starting from > the plan to move to Python 3, which depends on upstream, if there is even a > live upstream to begin with). To support multiple pythons, python26, python28 if it ever happens, python36 python38 when it comes out. Simply replacing the "python2" line iwth "python27" is not a difficent edit in most source code. > > This is absolutely not a reasonable and social way to deal with > compatibility packages in Fedora. > > 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 ___ 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: Package removal for FTBFS: Add automatic orphaning?
Miro Hrončok wrote: > If the only reason to set the status to ASSIGNED/POST/MODIFIED is to > prevent **me** from retiring the package, something is fundamentally > broken. This is not about you personally, but about the FTBFS process. :-) > If somebody has a legitimate reason to have a FTBFS package not retired, > they can ask for some kind of exception from Releng, not provide > inaccurate information. Packagers' time is limited, and there are usually much more important issues to solve than an FTBFS in Rawhide. (In fact, anything in Rawhide is lowest- priority for me. If it is an FTBFS without an associated broken dependency, even more so.) So if setting the bug from NEW to ASSIGNED buys the maintainer a few months extra time to fix the low-priority issue (which is the case in the current bizarre rules), why would they NOT do this? The best way to prevent bugs being falsely set to ASSIGNED is to just drop the perverse incentive to do so by dropping point 5 from the FTBFS policy. 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: Why retire Python 2 packages and games that still work to end user ?
On Sun, 2019-08-11 at 01:35 +0200, Miro Hrončok wrote: > On 11. 08. 19 1:05, Sérgio Basto wrote: > > Hi, > > > > Why we would retire childsplay or gcompris or gdesklets ? IMHO we > > still > > haven't a replacement . > > If the maintainer wants to, they can request an exception for the > package to be > kept. yes, but just gives more work to package maintainers . > > From [1] I strongly disagree with the text, why all python 2 > > packages > > will be removed automatically and why I would have a lot of work if > > I > > want keep one package alive . why not the opposite ? . > > Opposite? Retire Python 3? The opposite, is just removed the authorized packages . If maintainer not respond or aren't against to . > > Python 3 it isn't even the default why such hurry to drop python 2 > > at > > all , when we still have epel 7 with python 2 ... > > Python 3 is the default. On Fedora 30 still be Python 2 (Python 2.7.16) and Fedora 31 is not yet released . Thanks, > > My opinion at least postpone this decision one or two releases to > > Fedors 33/34 , many things still just work with python 2 . > > As I ask repeatedly: Who will maintain the Python 2 ecosystem? > > > [1] > > https://fedoraproject.org/wiki/Changes/RetirePython2 > > -- > 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 -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Why retire Python 2 packages and games that still work to end user ?
Sérgio Basto wrote: > Why we would retire childsplay or gcompris or gdesklets ? IMHO we still > haven't a replacement . > > From [1] I strongly disagree with the text, why all python 2 packages > will be removed automatically and why I would have a lot of work if I > want keep one package alive . why not the opposite ? . > Python 3 it isn't even the default why such hurry to drop python 2 at > all , when we still have epel 7 with python 2 ... > > My opinion at least postpone this decision one or two releases to > Fedors 33/34 , many things still just work with python 2 . I second that wholeheartedly. This change is just not implementable as it stands. Way too much upstream software still depends on Python 2. (In fact, I am not even convinced that it can be implemented as stated, ever, without dropping huge parts of Fedora and making it useless for a wide number of users. But what is sure is that it definitely cannot implemented without huge fallout in time for Fedora 32.) I also completely fail to see what value the rename from python2 to python27 (yet another one, after the already pointless rename from python to python2) will bring to our users. But the worst part is the required FESCo exception approval for every single remaining Python 2 package, along with loads of bureaucracy that many packages will be unable to comply with (starting from the plan to move to Python 3, which depends on upstream, if there is even a live upstream to begin with). This is absolutely not a reasonable and social way to deal with compatibility packages in Fedora. 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: Why retire Python 2 packages and games that still work to end user ?
On 11. 08. 19 1:05, Sérgio Basto wrote: Hi, Why we would retire childsplay or gcompris or gdesklets ? IMHO we still haven't a replacement . If the maintainer wants to, they can request an exception for the package to be kept. From [1] I strongly disagree with the text, why all python 2 packages will be removed automatically and why I would have a lot of work if I want keep one package alive . why not the opposite ? . Opposite? Retire Python 3? Python 3 it isn't even the default why such hurry to drop python 2 at all , when we still have epel 7 with python 2 ... Python 3 is the default. My opinion at least postpone this decision one or two releases to Fedors 33/34 , many things still just work with python 2 . As I ask repeatedly: Who will maintain the Python 2 ecosystem? [1] https://fedoraproject.org/wiki/Changes/RetirePython2 -- 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: Package removal for FTBFS: Add automatic orphaning?
On 11. 08. 19 0:34, Kevin Kofler wrote: Miro Hrončok wrote: Obviously, we can prevent this by only orphaning packages with NEW bugz, but that doesn't really solve anything, because lot of the retired packages were actually ASSIGNED/POST/MODIFIED (for months). Of course they were, to prevent you from retiring them even sooner. If the only reason to set the status to ASSIGNED/POST/MODIFIED is to prevent **me** from retiring the package, something is fundamentally broken. If somebody has a legitimate reason to have a FTBFS package not retired, they can ask for some kind of exception from Releng, not provide inaccurate information. -- 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: Does anybody care about gettext?
On Sat, Aug 10, 2019 at 10:28 PM Kevin Kofler wrote: > > Miro Hrončok wrote: > > Because if we don't, people just gonna ignore FTBFS forever. > > And this would be a problem why exactly? > > Packages built for older Fedora releases tend to run on newer Fedora > releases just fine. If the package: > * has no broken dependencies, and > * is not reported as completely broken in Bugzilla, > it should be assumed to be working by default. > > If you encounter a package that does not actually work, it is your job as a > user to report it. This can happen independently of whether the package > still compiles or not. It can even still be broken after a successful > rebuild. > > So why are we wasting packagers' time on fixing FTBFS issues (which are > typically NOT caused by their package, but by changes in dependencies such > as your python-unversioned-command change, or such as yet another > incompatible change in GCC for the sake of compliance with some obscure > subparagraph of a language standard, etc.) when not actually needed? I > actually NEED to fix the FTBFS if the package has broken dependencies or if > I need to make some other change to it. Otherwise, the FTBFS fix is just > churn that Fedora forces me to waste my time on. Hi, I understand where you are coming from, but I still disagree. I think there has been an unfair hostility towards Miro on this topic. Your package suddenly FTBFS because of dependencies or system-wide changes but the latest package build is still functional? I agree that there is no urgency to fix this, but I disagree that status quo is fine X releases later. For starters may miss out on system wide changes (and whether someone agrees with proposed changes is not the question) and in the case you made about bug reports that mandate action from the maintainer, not taking care of FTBFS timely means that once shit hits the fan you have to both solve the FTBFS situation and the user-facing bug report. So yes, it sucks when someone's package fails because someone else screwed up by not coordinating an soname bump or whatever, but it doesn't mean that we can keep the latest successful build around and let the source repository bit-rot forever because there are no bug reports. Now there's certainly room for improvement, but I don't have a solution to offer and hammering Miro because he's been (very) active lately retiring FTBFS or orphan packages (as per the normal process) is helping. Here we had an acknowledgement from a couple maintainers and someone who stepped in to help, a very positive outcome. Dridi ___ 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: [Bug 1675390] mingw-wine-gecko: FTBFS in Fedora rawhide/f30
Miro Hrončok wrote: > What would you want to do instead? Keep shipping th Fedora 26 package > forever? Since this is actually an MSI blob that is a drop-in replacement for the MSI blob from WINE upstream (where the version number expected by WINE is hardcoded and has not changed for years) and that contains PE binaries that are loaded by WINE, there is no reason why the F26 package would not just work. The PE binaries are covered by the W32/W64 binary compatibility guarantees, and the upstream blob being replaced has not changed for years. 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
Why retire Python 2 packages and games that still work to end user ?
Hi, Why we would retire childsplay or gcompris or gdesklets ? IMHO we still haven't a replacement . From [1] I strongly disagree with the text, why all python 2 packages will be removed automatically and why I would have a lot of work if I want keep one package alive . why not the opposite ? . Python 3 it isn't even the default why such hurry to drop python 2 at all , when we still have epel 7 with python 2 ... My opinion at least postpone this decision one or two releases to Fedors 33/34 , many things still just work with python 2 . Best regards, [1] https://fedoraproject.org/wiki/Changes/RetirePython2 -- Sérgio M. B. ___ 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: Package removal for FTBFS: Add automatic orphaning?
Miro Hrončok wrote: > Obviously, we can prevent this by only orphaning packages with NEW bugz, > but that doesn't really solve anything, because lot of the retired > packages were actually ASSIGNED/POST/MODIFIED (for months). Of course they were, to prevent you from retiring them even sooner. 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: Does anybody care about gettext?
Miro Hrončok wrote: > Because if we don't, people just gonna ignore FTBFS forever. And this would be a problem why exactly? Packages built for older Fedora releases tend to run on newer Fedora releases just fine. If the package: * has no broken dependencies, and * is not reported as completely broken in Bugzilla, it should be assumed to be working by default. If you encounter a package that does not actually work, it is your job as a user to report it. This can happen independently of whether the package still compiles or not. It can even still be broken after a successful rebuild. So why are we wasting packagers' time on fixing FTBFS issues (which are typically NOT caused by their package, but by changes in dependencies such as your python-unversioned-command change, or such as yet another incompatible change in GCC for the sake of compliance with some obscure subparagraph of a language standard, etc.) when not actually needed? I actually NEED to fix the FTBFS if the package has broken dependencies or if I need to make some other change to it. Otherwise, the FTBFS fix is just churn that Fedora forces me to waste my time on. 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
Need help to review these packages
Hello, I need your help to review these Go packages: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=Package%20Review&email1=zebob.m%40gmail.com&emailreporter1=1&emailtype1=substring&list_id=10401033&product=Fedora&query_format=advanced They are needed to update others or fix FTBFS. I'd love to be able to get to them before branching. I can review anything else in exchange. Best regards, Robert-André ___ 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: Does anybody care about gettext?
On 8/10/19 12:48 PM, Björn Persson wrote:
> Kevin Fenzi wrote:
>> On 8/10/19 4:12 AM, Björn Persson wrote:
>>> Rafal Luzynski wrote:
9.08.2019 22:10 Jerry James wrote:
> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz
Do we need to change ftp to https?
>>>
>>> That's the wrong question to ask. The right question is: What reason is
>>> there to choose an insecure protocol when HTTPS is available?
>>
>> I'm confused by this... https is already being used, it is just the
>> hostname that is 'ftp'.
>
> When I posted, gettext.spec in the master branch still said:
>
> Source: ftp://ftp.gnu.org/gnu/gettext/%{name}-%{tarversion}.tar.xz
Alright, I was going from the quoted text.
> The spec that Jerry James posted changed the URI scheme to https, which
> is the right thing to do. That change is now also in Git.
Sure, 100% agree.
kevin
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: Please sweep bodhi updates to testing in a timely manner
On 8/10/19 11:33 AM, Philip Kovacs via devel wrote: > Just look at the updates pending pages. Here are f30 and f29, resp: > https://bodhi.fedoraproject.org/updates/?releases=F30&status=pending > https://bodhi.fedoraproject.org/updates/?releases=F29&status=pending Updates are pushed every single day at 00:00UTC. However, todays failed because there were some unsigned packages. (This is caused by updates that stay in updates testing for a long time and their signed copies get grabage collected). I fixed that and finished the broken push, but I am at flock and didn't have time to start a full push. One should fire off in about 3 hours... There should never be an update that waits 7 days to push to testing... kevin -- >On Saturday, August 10, 2019, 02:29:24 PM EDT, Stephen John Smoogen > wrote: > > > > On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel > wrote: > > Why does it take days sometimes just to start the 7 day timer? > > Can we have some examples to track this down? Because without that.. no idea > and no way to fix. > > ___ > 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 > 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
Self Introduction: Ege Gunes
Hi, I'm a software developer from Istanbul, Turkey. I want to include some of my open source projects to Fedora and I submitted my first package review[1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1739816 -- Ege Gunes https://ege.dev/publickey.txt ___ 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
RFE: automatically enable rpmlint gating test for packages with a foo.rpmlintrc
Hi All, So what I've been reading from the rawhide gating mailthread, creating the gating rules unfortunately is somewhat convoluted / involved. As such I was wondering if maybe it is an idea to automatically enabled the rpmlint gating test for packages which have a .rpmlint rc. ? Alternatively a wiki page with gating confif snippets, mirroring how have a wiki page for specfile scriptlet snippets, might be a good idea. I would like to opt in to test-gating where possible, esp. with the rpmlint tests, but I do not have a lot of time to spend on this. More in general I believe that the easier this is made to use, the better chances are that people will actually use this. Regards, Hans ___ 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: Does anybody care about gettext?
Kevin Fenzi wrote:
> On 8/10/19 4:12 AM, Björn Persson wrote:
> > Rafal Luzynski wrote:
> >> 9.08.2019 22:10 Jerry James wrote:
> >>> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz
> >>
> >> Do we need to change ftp to https?
> >
> > That's the wrong question to ask. The right question is: What reason is
> > there to choose an insecure protocol when HTTPS is available?
>
> I'm confused by this... https is already being used, it is just the
> hostname that is 'ftp'.
When I posted, gettext.spec in the master branch still said:
Source: ftp://ftp.gnu.org/gnu/gettext/%{name}-%{tarversion}.tar.xz
The spec that Jerry James posted changed the URI scheme to https, which
is the right thing to do. That change is now also in Git.
The URL field should also be changed by the way. www.gnu.org redirects
HTTP requests to HTTPS, but there is no reason to give an attacker the
chance to intercept the HTTP request and redirect you to a malicious
server instead.
Björn Persson
pgp0irXcPb2Xm.pgp
Description: OpenPGP digital signatur
___
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: Please sweep bodhi updates to testing in a timely manner
Just look at the updates pending pages. Here are f30 and f29, resp: https://bodhi.fedoraproject.org/updates/?releases=F30&status=pending https://bodhi.fedoraproject.org/updates/?releases=F29&status=pending On Saturday, August 10, 2019, 02:29:24 PM EDT, Stephen John Smoogen wrote: On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel wrote: Why does it take days sometimes just to start the 7 day timer? Can we have some examples to track this down? Because without that.. no idea and no way to fix. ___ 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 -- Stephen J Smoogen. ___ 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: Please sweep bodhi updates to testing in a timely manner
On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel < devel@lists.fedoraproject.org> wrote: > Why does it take days sometimes just to start the 7 day timer? > Can we have some examples to track this down? Because without that.. no idea and no way to fix. > ___ > 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 > -- Stephen J Smoogen. ___ 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: [Xen-devel] Xen / EC2 release criteria proposal
Sorry for the top posting, "smart" phone... What about Qubes OS? Isn't their dom0 using xen, based on Fedora? Do they use Xen as packaged by Fedora? If not, couldn't they contribute whatever they do that Fedora doesn't here? It might be worth getting in touch with them. They look like a significant Xen user, on Fedora. Dridi On Sat, Aug 10, 2019, 17:33 Adam Williamson wrote: > On Sat, 2019-08-10 at 17:01 +0300, Matt Wilson wrote: > > On Fri, Aug 09, 2019 at 05:56:11PM -0700, Adam Williamson wrote: > > [...] > > > So it seems like this would also be a good opportunity to revisit and > > > nail down more specifically exactly what our cloud requirements are. > > > bcotton suggested that we require two sample instance types to be > > > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas > > > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed > > > like it might be worthwhile - he's promised to get back to me). > > > > > > So, for now, let me propose this as a trial balloon: we rewrite the > > > above criterion to say: > > > > > > "Release-blocking cloud disk images must be published to Amazon EC2 as > > > AMIs, and these must boot successfully and meet other relevant release > > > criteria on c5.large and t3.large instance types." > > > > Hi Adam, > > > > Thanks for bringing this up. It's good to revisit things from time to > > time as the world changes. > > Thanks for the feedback, Matt! > > > Of the two instances that you propose, neither runs on Xen. The T2 > > instances run on Xen, but T3 uses the KVM-based Nitro hypervisor. > > That'll teach me to trust Ben...;) > > > To ensure that a Linux based AMI functions across all of the devices > > and operating modes of EC2, you need to cover: > > > > x86 platforms > > - > > * Xen domU with only PV interfaces (e.g., M3 instances) > > * Xen domU with Intel 82599 virtual functions for Enhanced Networking > > (e.g., C3 instances running in a VPC) > > * Xen domU with Enhanced Networking Adapter (e.g., R4 instances) > > * Xen domU with NVMe local instance storage (e.g., virtualized I3 > > instances) > > * Xen domU with more than 32 vCPUs (e.g., c4.8xlarge) > > * Xen domU with four NUMA nodes (e.g., x1.32xlarge) > > * Xen domU with maximum RAM available in EC2 (x1e.32xlarge) > > * KVM guest with consistent performance (e.g., c5.large) > > * KVM guest with burstable performance (e.g., t3.large) > > * KVM guest with local NVMe storage (e.g., c5d.large) > > * KVM guest with 100 Gbps networking and Elastic Fabric Adapter > > (c5n.18xlarge) > > * KVM guest on AMD processors (e.g., m5a.large) > > * KVM guest on AMD processors with maximum NUMA nodes (e.g., > > m5a.24xlarge) > > * Bare metal Broadwell (i3.metal) > > * Bare metal Skylake (m5.metal) > > * Bare metal Cascade Lake (c5.metal) > > > > Arm platforms > > - > > * KVM guest on Arm with 1 CPU cluster (a1.xlarge) > > * KVM guest on Arm with 2 CPU clusters (a1.2xlarge) > > * KVM guest on Arm with 4 CPU clusters (a1.4xlarge) > > > > Not all of these are going to cause an image to fail to boot up to the > > point where a customer can SSH in. But a good number of these have > > caused early boot problems in the past (e.g., >32 vCPUs on PVHVM Xen). > > Thanks a lot for the list, it's very helpful. It's also very long, > though. :P Still, we can certainly use it as a base. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://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
Please sweep bodhi updates to testing in a timely manner
Why does it take days sometimes just to start the 7 day timer? ___ 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: Better interactivity in low-memory situations
On Fri, Aug 09, 2019 at 03:50:43PM -0600, Chris Murphy wrote: [..] > Problem and thesis statement: > Certain workloads, such as building webkitGTK from source, results in > heavy swap usage eventually leading to the system becoming totally > unresponsive. Look into switching from disk based swap, to swap on a > ZRAM device. > > Summary of findings (restated, but basically the same as found at [2]): > Test system, Macbook Pro, Intel Core i7-2820QM (4/8 cores), 8GiB RAM, > Samsung SSD 840 EVO, Fedora Rawhide Workstation. > Test case, build WebKitGTK from source. [..] To avoid such issues I disable swap on my machines. I really don't see the point of having a swap partition if you have 16 or 32 GiB RAM. Even with 8 GiB I disable swap. With - say - 8 GiB the build of a large project might fail (e.g. llvm, e.g. during linking) but it then fails fast and I can just restart it with `ninja -j2` or something like that. Another source of IO related unresponsiveness is buffer bloat - I thus apply this configuration on my machines: $ cat /etc/sysctl.d/01-disk-bufferbloat.conf vm.dirty_background_bytes=107374182 vm.dirty_bytes=214748364 Best regards Georg -- 'Time your programs before making claims about efficiency' (Bjarne Stroustrup, The C++ Programming Language, 4th ed., p. 132, 2013) ___ 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: Does anybody care about gettext?
On Sat, Aug 10, 2019 at 12:48 PM Kevin Fenzi wrote:
>
> On 8/10/19 4:12 AM, Björn Persson wrote:
> > Rafal Luzynski wrote:
> >> 9.08.2019 22:10 Jerry James wrote:
> >>> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz
> >>
> >> Do we need to change ftp to https?
> >
> > That's the wrong question to ask. The right question is: What reason is
> > there to choose an insecure protocol when HTTPS is available?
>
> I'm confused by this... https is already being used, it is just the
> hostname that is 'ftp'. So, I would see no reason to change this, but I
> suppose you could ask upstream to rename the host to avoid confusion...
>
> kevin
The site still supports FTP, which I suspect is why they use the same
name for both services. Check out ftp://ftp.gnu.org/pub/gnu/
___
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: Does anybody care about gettext?
On 8/10/19 4:12 AM, Björn Persson wrote:
> Rafal Luzynski wrote:
>> 9.08.2019 22:10 Jerry James wrote:
>>> Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz
>>
>> Do we need to change ftp to https?
>
> That's the wrong question to ask. The right question is: What reason is
> there to choose an insecure protocol when HTTPS is available?
I'm confused by this... https is already being used, it is just the
hostname that is 'ftp'. So, I would see no reason to change this, but I
suppose you could ask upstream to rename the host to avoid confusion...
kevin
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: Signing problem again in Rawhide?
On 8/10/19 2:20 AM, Richard W.M. Jones wrote: > On Sat, Aug 10, 2019 at 10:09:50AM +0100, Richard W.M. Jones wrote: >> >> This package was built over 24 hours ago: >> >> https://koji.fedoraproject.org/koji/buildinfo?buildID=1349103 >> >> but it hasn't appeared in Rawhide yet. > > It seems the problem may only apply to this package, as I've just > built another package in Rawhide and that one was signed and available > to build against in only a few minutes. > Not sure what happened, but I have re-tagged it and it processed correctly now. kevin 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: [Xen-devel] Xen / EC2 release criteria proposal
On Sat, 2019-08-10 at 17:01 +0300, Matt Wilson wrote: > On Fri, Aug 09, 2019 at 05:56:11PM -0700, Adam Williamson wrote: > [...] > > So it seems like this would also be a good opportunity to revisit and > > nail down more specifically exactly what our cloud requirements are. > > bcotton suggested that we require two sample instance types to be > > tested, c5.large (KVM) and t3.large (Xen). (I've also mailed Thomas > > Cameron, ex-of Red Hat, now of Amazon, for his opinion, as it seemed > > like it might be worthwhile - he's promised to get back to me). > > > > So, for now, let me propose this as a trial balloon: we rewrite the > > above criterion to say: > > > > "Release-blocking cloud disk images must be published to Amazon EC2 as > > AMIs, and these must boot successfully and meet other relevant release > > criteria on c5.large and t3.large instance types." > > Hi Adam, > > Thanks for bringing this up. It's good to revisit things from time to > time as the world changes. Thanks for the feedback, Matt! > Of the two instances that you propose, neither runs on Xen. The T2 > instances run on Xen, but T3 uses the KVM-based Nitro hypervisor. That'll teach me to trust Ben...;) > To ensure that a Linux based AMI functions across all of the devices > and operating modes of EC2, you need to cover: > > x86 platforms > - > * Xen domU with only PV interfaces (e.g., M3 instances) > * Xen domU with Intel 82599 virtual functions for Enhanced Networking > (e.g., C3 instances running in a VPC) > * Xen domU with Enhanced Networking Adapter (e.g., R4 instances) > * Xen domU with NVMe local instance storage (e.g., virtualized I3 > instances) > * Xen domU with more than 32 vCPUs (e.g., c4.8xlarge) > * Xen domU with four NUMA nodes (e.g., x1.32xlarge) > * Xen domU with maximum RAM available in EC2 (x1e.32xlarge) > * KVM guest with consistent performance (e.g., c5.large) > * KVM guest with burstable performance (e.g., t3.large) > * KVM guest with local NVMe storage (e.g., c5d.large) > * KVM guest with 100 Gbps networking and Elastic Fabric Adapter > (c5n.18xlarge) > * KVM guest on AMD processors (e.g., m5a.large) > * KVM guest on AMD processors with maximum NUMA nodes (e.g., > m5a.24xlarge) > * Bare metal Broadwell (i3.metal) > * Bare metal Skylake (m5.metal) > * Bare metal Cascade Lake (c5.metal) > > Arm platforms > - > * KVM guest on Arm with 1 CPU cluster (a1.xlarge) > * KVM guest on Arm with 2 CPU clusters (a1.2xlarge) > * KVM guest on Arm with 4 CPU clusters (a1.4xlarge) > > Not all of these are going to cause an image to fail to boot up to the > point where a customer can SSH in. But a good number of these have > caused early boot problems in the past (e.g., >32 vCPUs on PVHVM Xen). Thanks a lot for the list, it's very helpful. It's also very long, though. :P Still, we can certainly use it as a base. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Xen / EC2 release criteria proposal
> "The release must boot successfully as Xen DomU with releases providing > a functional, supported Xen Dom0 and widely used cloud providers > utilizing Xen." I am a long time Xen/Fedora user. In fact, I rely on Fedora as my Dom0. I acknowledge that there are not too many of us, and I further acknowledge that mandatory testing often goes unperformed. The Fedora Xen mailing list is exceedingly low-volume. Michael Young has in the past done a lot of the heavy lifting surrounding Xen support, and I am very grateful for his work. Xen Dom0 is particularly tenuous. Dropping (for a good reason) GRUB's multiboot2 module left Xen unable to boot under EFI [e.g., 1]. All of that said, there are good reasons to choose Xen over KVM. Xen's architecture and full support for libvmi come to mind. (Of course, there are good reasons to choose KVM too.) Perhaps we could go one more release with the status quo to give the Xen/Fedora community a last chance to rally and demonstrate a willingness to perform the necessary testing and maintenance. I suspect we are all quite busy, so we might find ourselves admitting that broader Xen support will be relegated to the standard means of maintenance rather than rising to the status of blockers. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1703872 -- Mike :wq ___ 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: Modules in rawhide (that shouldn't be there)
You meant more like "rebuilding" modules rather than branching, right? On Sat, Aug 10, 2019 at 3:09 PM Mohan Boddu wrote: > > Hi all, > > There is a Mass Branching scheduled for next Tuesday, that is on Aug 13th > 2019. There were some modules that are stuck in rawhide that shouldn't be > there, please create a ticket in https://pagure.io/releng with the list of > module builds that shouldn't be there and we will remove them from rawhide > and will not be branched. > > Thanks, > Mohan Boddu. > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS-UP] dav1d and aom SONAME bump
On Friday, 09 August 2019 at 17:40, Robert-André Mauchin wrote: > Hello, > > Next week I will update dav1d to version 0.4.0 which includes a SONAME bump, > and will do a GIT snapshot of aom, whose library is unstable. > > I will push these updates both on F31 and F30, so consumers of these > libraries > (ffmpeg, xine-lib, vlc) will need to rebuild their packages on both release. Why F30? Please don't push unstable stuff to released branches. 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
Modules in rawhide (that shouldn't be there)
Hi all, There is a Mass Branching scheduled for next Tuesday, that is on Aug 13th 2019. There were some modules that are stuck in rawhide that shouldn't be there, please create a ticket in https://pagure.io/releng with the list of module builds that shouldn't be there and we will remove them from rawhide and will not be branched. Thanks, Mohan Boddu. ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: bootctl: no entry could be determined as default (Was: Upgrade to F30 gone wrong)
Hi, > That only works properly on distros that implement the boot loader > spec and the boot loader interface properly: > > https://systemd.io/BOOT_LOADER_SPECIFICATION > https://systemd.io/BOOT_LOADER_INTERFACE Thanks for the links, I looked briefly when you replied but figured I'd need a quiet setup since this is unfamiliar territory. I have finally read both documents, and they are very accessible even to someone without prior knowledge. > Unfortunately, Fedora/grub do not support either. > > (Which is a pity of course, since it also means there's no working > "systemctl --boot-loader-entry=" support in Fedora, nor "sytemctl > kexec" support). I see. Do I understand from reading the specification that it was put together during the Fedora 18 days? Do I understand from reading the boot loader interface documented that systemd supported all this in the f18 days too? Thanks, Dridi ___ 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: Does anybody care about gettext?
10.08.2019 13:12 Björn Persson wrote: > [...] > Anyway, the answer is yes: > > 220 GNU FTP server ready. > USER anonymous > 230-NOTICE (Updated October 13 2017): > 230- > 230-Because of security concerns with plaintext protocols, we still > 230-intend to disable the FTP protocol for downloads on this server > [...] This answers the question, thanks. Rafal ___ 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: Does anybody care about gettext?
Rafal Luzynski wrote:
> 9.08.2019 22:10 Jerry James wrote:
> > Source: https://ftp.gnu.org/pub/gnu/gettext/%{name}-%{version}.tar.xz
>
> Do we need to change ftp to https?
That's the wrong question to ask. The right question is: What reason is
there to choose an insecure protocol when HTTPS is available?
Anyway, the answer is yes:
220 GNU FTP server ready.
USER anonymous
230-NOTICE (Updated October 13 2017):
230-
230-Because of security concerns with plaintext protocols, we still
230-intend to disable the FTP protocol for downloads on this server
230-(downloads would still be available over HTTP and HTTPS), but we
230-will not be doing it on November 1, 2017, as previously announced
230-here. We will be sharing our reasons and offering a chance to
230-comment on this issue soon; watch this space for details.
230-
230-If you maintain scripts used to access ftp.gnu.org over FTP,
230-we strongly encourage you to change them to use HTTPS instead.
Björn Persson
pgpwAji6ITSLs.pgp
Description: OpenPGP digital signatur
___
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: Signing problem again in Rawhide?
On Sat, Aug 10, 2019 at 10:09:50AM +0100, Richard W.M. Jones wrote: > > This package was built over 24 hours ago: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1349103 > > but it hasn't appeared in Rawhide yet. It seems the problem may only apply to this package, as I've just built another package in Rawhide and that one was signed and available to build against in only a few minutes. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Discussion around app retirements and categorizations by the CPE team
On Wed, Jul 31, 2019 at 7:17 AM Pierre-Yves Chibon wrote: > > On Tue, Jul 30, 2019 at 01:13:50PM -0400, Tim Zabel wrote: > >Hello, > >I'm a little late to this conversation, but is fpaste in Category 4 due > > to > >the high legal costs, or because of a lack of a maintainer? > >It would be sad to see fpaste go away because of legal reasons. Is there > > a > >better way to handle this? > > Basically both, it has a very high legal cost and the software we use is not > maintained and hasn't been for a while. Finding a new pastebin that works, > means > investigating the ecosystem, figuring out which one fits best our needs, > getting > it deployed, monitoring the project for security issues and alike. > All this considered, CPE feels that spending time on fpaste isn't the best use > of its time, especially considering the number of nicer pastebins out there. Hi, For a pastebin replacement I can point you to my colleague's filebin [1] project that is our $DAYJOB dogfood. It's written in Go and might need work to be included in Fedora. I can only promise to help as an ambassador to make sure any request or contribution from Fedora gets attention. Dridi [1] https://github.com/espebra/filebin/ ___ 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
Signing problem again in Rawhide?
This package was built over 24 hours ago: https://koji.fedoraproject.org/koji/buildinfo?buildID=1349103 but it hasn't appeared in Rawhide yet. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: Better interactivity in low-memory situations
On Fri, 09 Aug 2019 23:50:43 +0200, Chris Murphy wrote:
> $ cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
RelWithDebInfo is -O2 -g build. That is not suitable for debugging, for
debugging you should use -DCMAKE_BUILD_TYPE=Debug (that is -g).
RelWithDebInfo is useful for final rpm packages but those are build in Koji.
Debug build will have smaller debug info so the problem may go away.
If it does not go away then tune the parallelism. Low -j makes the build
needlessly slow during compilation phase while high -j (up to about #cpus
+ 2 or so) will make the final linking phase with debug info to run out of
memory. This is why LLVM has separate "-j" for the linking phase but that is
implemented only in LLVM CMakeLists.txt files:
https://llvm.org/docs/CMake.html
LLVM_PARALLEL_LINK_JOBS
So that you leave the default -j high but set LLVM_PARALLEL_LINK_JOBS to 1 or 2.
Other options for faster build times are also LLVM specific:
-DLLVM_USE_LINKER=gold (maybe also lld now?)
- as ld.gold or ld.lld are faster than ld.bfd
-DLLVM_USE_SPLIT_DWARF=ON
- Linking phase no longer deals with the huge debug info
Which should be applicable for other projects by something like (untested!):
-DCMAKE_C_FLAGS="-gsplit-dwarf"
-DCMAKE_CXX_FLAGS="-gsplit-dwarf"
-DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold -Wl,--gdb-index"
-DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold -Wl,--gdb-index"
(That gdb-index is useful if you are really going to debug it using GDB as
I expect you are going to do when you want RelWithDebInfo and not Release; but
then I would recommend Debug in such case anyway as debugging optimized code
is very difficult.)
> is there a practical way right now of enforcing CPU
> and memory limits on unprivileged applications?
$ help ulimit
-mthe maximum resident set size
-uthe maximum number of user processes
-vthe size of virtual memory
One can also run it with 'nice -n19', 'ionice -c3'
and/or "cgclassify -g '*':hammock" (config attached).
But after all I recommend just more memory, it is cheap nowadays and I find
64GB just about the right size.
Jan
mount {
cpu = /cgroup/cpu;
memory = /cgroup/memory;
blkio = /cgroup/blkio;
}
group hammock {
perm {
task {
uid = jkratoch;
gid = jkratoch;
}
admin {
uid = jkratoch;
gid = jkratoch;
}
}
cpu {
cpu.shares = 2;
}
memory {
memory.limit_in_bytes = 2G;
}
blkio {
blkio.weight = 100;
}
}
___
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: Orphaning some packages
Hi Pierre, On Sat, 3 Aug 2019 at 14:35, Pierre-Yves Chibon wrote: > > Good Morning Everyone, > > I think it's time I make amends and recognize that I've been a terrible > maintainer for a number of my packages. > So I'd like to orphan the following packages hoping they can find a better > home. > > I no longer use R, so all of my R libraries: > rpms/R-affy > rpms/R-affydata > rpms/R-affyio > rpms/R-ALL > rpms/R-AnnotationDbi > rpms/R-Biobase > rpms/R-BiocGenerics > rpms/R-Biostrings > rpms/R-BSgenome > rpms/R-BSgenome.Celegans.UCSC.ce2 > rpms/R-BufferedMatrix > rpms/R-BufferedMatrixMethods > rpms/R-caTools > rpms/R-DynDoc > rpms/R-fibroEset > rpms/R-GenomicFeatures > rpms/R-GenomicRanges > rpms/R-hgu133acdf > rpms/R-hgu95av2cdf > rpms/R-hgu95av2probe > rpms/R-IRanges > rpms/rkward > rpms/R-maanova > rpms/R-multtest > rpms/R-pls > rpms/R-preprocessCore > rpms/R-qvalue > rpms/R-rlecuyer > rpms/R-ROC > rpms/R-RUnit > rpms/R-sandwich > rpms/R-statmod > rpms/R-timeDate > rpms/R-tkWidgets > rpms/R-widgetTools > rpms/R-XML > rpms/R-xtable > I can take R-caTools, R-RUnit, R-timeDate, R-XML, and R-xtable. And while I have your attention, I'd like to ask about maintaining R2spec, which has several open PRs but has not been touched for ages. > rpms/trac-mastertickets-plugin >No longer used in infra > > rpms/libdivecomputer > rpms/subsurface > Upstream (of the later) does a lot of bundling and I've had a hard time > keeping up with it. I think this one may be more suitable for a flatpack > tbh. > libdivecomputer is a dependency of subsurface. > > rpms/igraph > rpms/python-igraph > I picked these two when I was looking at graph libraries but I've never done > anything with them > > rpms/python-rdfextras > I took over this one but I'm not using it anywhere and not keeping up with > upstream > > > Let me know if you are interested in any of them and I'll give them to you. > Otherwise I'll likely orphan them when I can back from flock. > > > > Best, > Pierre -- Elliott ___ 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
