[EPEL-devel] EPEL 8 on RHEL 8.1 Beta
Hi, Trying to install EPEL 8 on RHEL 8.1 Beta. I did $ yum install https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64/Packages/e/epel-release-8-1.noarch.rpm and doing $ yum update gives the error failed to open: /var/cache/dnf/epel-7223eb0d0c06d046/repodata/78c05abe94a83354e9759eacd446d11a44df882d8c45fbf74b147b09a7fd6c83-updateinfo.xml.zck Tried changing baseurl in /etc/yum.repos.d/epel.repo to https://dl.fedoraproject.org/pub/epel/8/Everything/x86_64 and https://dl.fedoraproject.org/pub/epel/testing/8/Everything/x86_64 both give the same error Kindly check. thanks -- Lee ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[Bug 1731809] Upgrade perl-ExtUtils-F77 to 1.24
https://bugzilla.redhat.com/show_bug.cgi?id=1731809 Orion Poplawski changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2019-08-01 04:00:55 --- Comment #1 from Orion Poplawski --- Done. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 351 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 127 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 93 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 91 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 62 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fc63c75ab1 hostapd-2.8-1.el7 27 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12067fc897 dosbox-0.74.3-2.el7 20 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-487a6fb279 knot-2.8.2-1.el7 knot-resolver-4.1.0-1.el7 20 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aabd063c30 squirrelmail-1.4.23-1.el7.20190710 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ef655ec55e proftpd-1.3.5e-5.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing librsync-2.0.2-1.el7 perl-Schedule-Cron-Events-1.95-10.el7 perl-Unicode-LineBreak-2019.001-4.el7 Details about builds: librsync-2.0.2-1.el7 (FEDORA-EPEL-2019-b8b086bdfa) Rsync remote-delta algorithm library Update Information: ## librsync 2.0.2 * Improve CMake install paths configuration and platform supportchecking when cross-compiling. * Fix Unaligned memory access for `rs_block_sig_init()` * Fix `hashtable_test.c` name collision for `key_t` in `sys/types.h` on someplatforms * Format code with consistent style, adding `make tidy` and `maketidyc` targets for reformating code and comments. * Removed perl as a build dependency. Note it is still required for sometests. * Update RPM spec file for v2.0.2 and fix cmake man page install. ## librsync 2.0.1 * Extensively reworked Doxygen documentation, now available at http://librsync.sourcefrog.net/ * Removed some declarations from `librsync.h` that were unimplemented or nolonger ever useful: `rs_work_options`, `rs_accum_value`. Removedeclaration of unimplemented `rs_mdfour_file()`. * Remove shipped `snprintf` code: no longer acutally linked after changing to CMake, and since it's part of C99 it should be widely available. * Document that Ninja (http://ninja-build.org/) is supported under CMake.It's a bit faster and nicer than Make. * `make check` (or `ninja check` etc) will now build and run the tests.Previously due to a CMake limitation, `make test` would only run existingtests and could fail if they weren't built. * Added cmake options to exclude rdiff target and compression from build.See install documentation for details. * `popt` is only needed when `rdiff` is being built. * Improved large file support for platforms using different variants of `fseek` (`fseeko`, `fseeko64`, `_fseeki64`), `fstat` (`fstat64`, `_fstati64`), and `fileno` (`_fileno`). * `rdiff -s` option now shows bytes read/written and speed.For delta operations it also shows hashtable match statistics. * Running rdiff should not overwrite existing files (signatures, deltas andnew patched files) by default. If the destination file exists, rdiff willnow exit with an error. Add new option `-f` (`--force`) to overwrite existingfiles. * Improve signature memory allocation (doubling size instead of callingrealloc for every sig block) and added support for preallocation. See`streaming.md` `job->estimated_signature_count` for usage when using thelibrary. `rdiff` uses this by default if possible. * Significantly tidied signature handling code and testing, resulting in more consistent error handling behaviour, and making it easier to plug in alternative weak and strong sum implementations. Also fixed "slack delta" support for delta calculation with no signature. * `stdint.h` and `inttypes.h` from C99 is now required. Removed redundantlibrsync-config.h header file. * Lots of small fixes for windows platforms and building with MSVC. * New open addressing hashtable implementation that significantly speeds updelta operations, particularly for large files. Also fixed degeneratebehaviour with large number of duplicate blocks like runs of zerosin sparse files. * Optional support with cmake option for using libb2 blake2 implementation. Also updated included reference blake2 implementation with bug fixes, * Improved default values for input and output buffer sizes. The defaults are now `--input-size=0` and `--output-size=0`, which will choose recommended default sizes based on the `--block-size` and the operation being performed. * Fixed hanging for truncated input files. It will now correctly report an error indicating an unexpected EOF was encountered. * Fixed
Re: update hung in "pending" status
On 7/31/19 4:18 PM, Mátyás Selmeci wrote: > Hi, > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0f74bf64a and > https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb3b2a2164 have been > stuck in "pending" status for several hours now. Can someone kick them so > they get into testing? Updates pushes for stable releases happen once a day, starting at 00:00. Those are both in the current pushes that are going out now... they should be out in a few more hours. 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: update hung in "pending" status
Mátyás Selmeci wrote: > Hi, > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0f74bf64a and > https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb3b2a2164 have been > stuck in "pending" status for several hours now. Can someone kick them so > they get into testing? Updates generally get pushed to -testing at most once a day, nothing to kick... yet. -- Rex ___ 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: python2->python3 mass rebuild and auto tools
On Wednesday, July 31, 2019 7:08:57 PM EDT Miro Hrončok wrote: > On 01. 08. 19 0:03, Steve Grubb wrote: > > I have a package that fails to build because libraries aren't where they > > are suposed to be. I looked at the project page > > > > https://fedoraproject.org/wiki/Changes/Python_means_Python3 > > > > and there is no mention of the effect on autotools. > > Sorry a about not mentioning autotools specifically. > > > I have pyexec_PYTHON. What is supposed to be there? And since this is an > > upstream package consumed by all distributions and old versions of > > Fedora/ RHEL, what is the portable thing to do? > > > > There's other things out there like pybind_dir which are probably messed > > up, too. > > Unfortunately, I don't know much about autoools, but I suspect that the > same mechanics that were needed for Python 3 to work are now needed for > Python 2. What package exactly is failing? Is it audit? I'll have a look. Audit. But is seems that autotools shoul hard code the old sematics so that all packages do the right thing. It seems that python3 equivalents have been introduced. They do the right thing with the python migration. But there are things that are expectd to defaulto python 2. > > Should they be hardcoded to mean python2 in autotools and swig? > > > No. That was kinda the point of this change: "python" means Python 3. > > Python 2 is deprecated and will be retired. Of course. But there is a legacy pyexec_PYTHON and there is a py3exec_PYTHON. What this change means is that they are one in the same. I do not think that is the intention. Because...is there a py2exec_PYTHON? I do not find it grepping my system. And this would need to have been advanced years ago, not today. Thanks, -Steve ___ 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
[389-devel] 389 DS nightly 2019-08-01 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/08/01/report-389-ds-base-1.4.1.6-20190731gita593f3d.fc30.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
Re: python2->python3 mass rebuild and auto tools
On Wednesday, July 31, 2019 7:06:17 PM EDT Charalampos Stratakis wrote: > - Original Message - > > > From: "Charalampos Stratakis" > > To: "Development discussions related to Fedora" > > Sent: Thursday, August 1, 2019 1:03:51 > > AM > > Subject: Re: python2->python3 mass rebuild and auto tools > > > > > > > > - Original Message - > > > > > From: "Steve Grubb" > > > To: "Development discussions related to Fedora" > > > > > > Sent: Thursday, August 1, 2019 12:03:01 AM > > > Subject: python2->python3 mass rebuild and auto tools > > > > > > Hello, > > > > > > I have a package that fails to build because libraries aren't where > > > they > > > are > > > suposed to be. I looked at the project page > > > > > > https://fedoraproject.org/wiki/Changes/Python_means_Python3 > > > > > > and there is no mention of the effect on autotools. > > > > > > I have pyexec_PYTHON. What is supposed to be there? And since this is > > > an > > > upstream package consumed by all distributions and old versions of > > > Fedora/ RHEL, what is the portable thing to do? > > > > > > There's other things out there like pybind_dir which are probably > > > messed > > > up, > > > too. > > > > > > Should they be hardcoded to mean python2 in autotools and swig? > > > > > > -Steve > > > > > > ___ > > > 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 > > Could you point out in which package the problem manifests? > > > > I've dealt with numerous autotools issues before in respect to Python > > 3.8, and most of them boil down to autotools (or the project using > > autotools) invoking python-config --libs to embed python, which in order > > to achieve it in 3.8 the additional flag --embed needs to be used. > > > > -- > And I've just realized I'm talking about a different problem here, not > related to this change, heh. > Could you still point out the package you are dealing with? Audit -Steve ___ 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following builds have been pushed to Fedora EPEL 8 updates-testing screen-4.6.2-10.el8 Details about builds: screen-4.6.2-10.el8 (FEDORA-EPEL-2019-9c590bc54d) A screen manager that supports multiple logins on one terminal Update Information: Testing ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
> "NG" == Neal Gompa writes: NG> You just set localpkg_gpgcheck=1 in /etc/dnf/dnf.conf NG> That said, you probably don't want to do that, since most downloaded NG> packages aren't signed... I think that the ideal behavior would be to always check, but warn/prompt for unsigned packages or those with signature failures. Certainly it's better to verify as much as possible as often as possible. - J< ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 2:45 PM Kevin Fenzi wrote: > > On 7/31/19 11:09 AM, Florian Weimer wrote: > > * Jason L. Tibbitts, III: > > > > At one point, RPM wrote unchecked file contents to disk, leading to > > vulnerabilities such as CVE-2013-6435. At the time, it was not possible > > to teach RPM to verify the data before writing it. > > > >> If it is, then great, though signatures still have value because there > >> are other ways to get RPMs than letting dnf hit the mirror network. > > > > I think dnf only performs signature checking if the RPMs are downloaded > > from repositories. > > Yep. I am pretty sure that is the case. > By default this is the case, but you can configure DNF to validate signatures for all cases if you want. You just set localpkg_gpgcheck=1 in /etc/dnf/dnf.conf That said, you probably don't want to do that, since most downloaded packages aren't signed... -- 真実はいつも一つ！/ 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: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
> > I disagree with ANY raised vector instruction requirement, considering that: > > * it would make Fedora incompatible with some hardware out there, > > That's already so for hardware which is at least of similar age to > SSE2-only x86_64, i.e. POWER7; my build logs show -mcpu=power8. For ppc64le, which is the only Power64 architecture Fedora now supports, the first HW that was supported running Linux on little endian was Power8 HW so that is exactly as expected. As opposed to ppc64 which is big endian which until it was retired still supported what ever generation was the Power Mac G5. > > * the performance increase to be had is marginal, given that we are mostly > > talking about code written in C or C++ without even compiler vectorization > > (-ftree-vectorize) turned on, > > I forget the details, but libxsmm is something that depends on an > instruction introduced with SSE3, and is a good example of portable > performance engineering over a wide range of (x86_64) processors. > > > * there are already mechanisms for runtime feature detection, which are > > already widely used in those few packages that can actually benefit from > > the vector instructions (because they are performance-sensitive and > > because they have handwritten assembly or vector intrinsics code), > > I disagree that dynamic dispatch is sufficiently widely used in > scientific code (probably can't be with Fortran). Also recent GCC can > provide decent performance for specific targets without target-specific > programming. BLIS' portable C version DGEMM got around 60%(?) the speed > of the hand-tuned implementation built for haswell, as reported > somewhere in the BLIS issues. For people who don't know, DEGMM > (generalized matrix-matrix multiplication) is as SIMD-intensive as it > gets, with high enough floating point intensity relative to memory > access for large enough dimensions; non-matrix-matrix linear algebra > typically doesn't if it doesn't fit in cache. > ___ > 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
update hung in "pending" status
Hi, https://bodhi.fedoraproject.org/updates/FEDORA-2019-f0f74bf64a and https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb3b2a2164 have been stuck in "pending" status for several hours now. Can someone kick them so they get into testing? Thanks, -Mat -- Mátyás (Mat) Selmeci Open Science Grid Software Team / Center for High-Throughput Computing University of Wisconsin-Madison Department of Computer Sciences ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 09:05:21PM +0200, Nicolas Mailhot via devel wrote: > Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a > écrit : > > > > > > > "KF" == Kevin Fenzi writes: > > > > KF> * If you use metalinks, rpm signatures are just gravy on top, in > > the > > KF> end you are still just trusing SSL CA's. > > > > Only if you trust every mirror to always serve authentic content. > > And, just to provide another data point, we tried this month to make > the network install iso talk to https dnf repos (a reposync of fedora > devel x86_64, without x86 packages, because we don't have the storage > budget to mirror 32 bit packages we don't have the use for them > anyway). The repos themselves worked fine from installed systems. But, > anaconda refused to use them, till they were re-exposed in plain un- > secured http. It's odd that they would work from an installed system and not anaconda. Are you using a self-signed cert on them? If so you can pass inst.noverifyssl to anaconda to tell it to ignore the error but still use https. -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted ___ 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: python2->python3 mass rebuild and auto tools
On 01. 08. 19 1:08, Miro Hrončok wrote: On 01. 08. 19 0:03, Steve Grubb wrote: I have pyexec_PYTHON. What is supposed to be there? And since this is an upstream package consumed by all distributions and old versions of Fedora/ RHEL, what is the portable thing to do? There's other things out there like pybind_dir which are probably messed up, too. Unfortunately, I don't know much about autoools, but I suspect that the same mechanics that were needed for Python 3 to work are now needed for Python 2. What package exactly is failing? Is it audit? I'll have a look. Here: https://src.fedoraproject.org/rpms/audit/pull-request/4 -- 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: python2->python3 mass rebuild and auto tools
On 01. 08. 19 0:03, Steve Grubb wrote: Hello, Hi Steve. I have a package that fails to build because libraries aren't where they are suposed to be. I looked at the project page https://fedoraproject.org/wiki/Changes/Python_means_Python3 and there is no mention of the effect on autotools. Sorry a about not mentioning autotools specifically. I have pyexec_PYTHON. What is supposed to be there? And since this is an upstream package consumed by all distributions and old versions of Fedora/ RHEL, what is the portable thing to do? There's other things out there like pybind_dir which are probably messed up, too. Unfortunately, I don't know much about autoools, but I suspect that the same mechanics that were needed for Python 3 to work are now needed for Python 2. What package exactly is failing? Is it audit? I'll have a look. Should they be hardcoded to mean python2 in autotools and swig? No. That was kinda the point of this change: "python" means Python 3. Python 2 is deprecated and will be retired. 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: python2->python3 mass rebuild and auto tools
- Original Message - > From: "Charalampos Stratakis" > To: "Development discussions related to Fedora" > > Sent: Thursday, August 1, 2019 1:03:51 AM > Subject: Re: python2->python3 mass rebuild and auto tools > > > > - Original Message - > > From: "Steve Grubb" > > To: "Development discussions related to Fedora" > > > > Sent: Thursday, August 1, 2019 12:03:01 AM > > Subject: python2->python3 mass rebuild and auto tools > > > > Hello, > > > > I have a package that fails to build because libraries aren't where they > > are > > suposed to be. I looked at the project page > > > > https://fedoraproject.org/wiki/Changes/Python_means_Python3 > > > > and there is no mention of the effect on autotools. > > > > I have pyexec_PYTHON. What is supposed to be there? And since this is an > > upstream package consumed by all distributions and old versions of Fedora/ > > RHEL, what is the portable thing to do? > > > > There's other things out there like pybind_dir which are probably messed > > up, > > too. > > > > Should they be hardcoded to mean python2 in autotools and swig? > > > > -Steve > > > > ___ > > 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 > > > > Could you point out in which package the problem manifests? > > I've dealt with numerous autotools issues before in respect to Python 3.8, > and most of them boil down to autotools (or the project using autotools) > invoking python-config --libs to embed python, which in order to achieve it > in 3.8 the additional flag --embed needs to be used. > > -- > Regards, > > Charalampos Stratakis > Software Engineer > Python Maintenance Team, Red Hat > And I've just realized I'm talking about a different problem here, not related to this change, heh. Could you still point out the package you are dealing with? -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: python2->python3 mass rebuild and auto tools
- Original Message - > From: "Steve Grubb" > To: "Development discussions related to Fedora" > > Sent: Thursday, August 1, 2019 12:03:01 AM > Subject: python2->python3 mass rebuild and auto tools > > Hello, > > I have a package that fails to build because libraries aren't where they are > suposed to be. I looked at the project page > > https://fedoraproject.org/wiki/Changes/Python_means_Python3 > > and there is no mention of the effect on autotools. > > I have pyexec_PYTHON. What is supposed to be there? And since this is an > upstream package consumed by all distributions and old versions of Fedora/ > RHEL, what is the portable thing to do? > > There's other things out there like pybind_dir which are probably messed up, > too. > > Should they be hardcoded to mean python2 in autotools and swig? > > -Steve > > ___ > 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 > Could you point out in which package the problem manifests? I've dealt with numerous autotools issues before in respect to Python 3.8, and most of them boil down to autotools (or the project using autotools) invoking python-config --libs to embed python, which in order to achieve it in 3.8 the additional flag --embed needs to be used. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Duplicate FTBFS bugs?
On 31. 07. 19 23:29, Richard W.M. Jones wrote: Seems like some script is being run a second time and is filing duplicate FTBFS bugs (unless there's some difference in these bugs which I'm not able to discern): https://bugzilla.redhat.com/show_bug.cgi?id=1735387 & https://bugzilla.redhat.com/show_bug.cgi?id=1734855 https://bugzilla.redhat.com/show_bug.cgi?id=1734862 & https://bugzilla.redhat.com/show_bug.cgi?id=1735393 https://bugzilla.redhat.com/show_bug.cgi?id=1734863 & https://bugzilla.redhat.com/show_bug.cgi?id=1735394 This might have been me by "reblocking" them to the exisitng F31FTBFS tracker. If that's the case, I'm sorry, my intentions were good. I've re-added all existing bugzillas to the duplicate tracker again in case a script is running that checks for those. Context: https://bugzilla.redhat.com/show_bug.cgi?id=1732841 https://bugzilla.redhat.com/show_bug.cgi?id=1700317 https://pagure.io/releng/issue/8275#comment-586553 https://pagure.io/releng/issue/8555#comment-586568 https://pagure.io/releng/pull-request/8574 -- 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: Over 500 orphaned packages seeking new maintainers
* Christopher [30/07/2019 13:20] : > > Is there anything special one must do to "Join" the Java SIG? I would > like to join. SIGs are rather informal and none of them have a joining procedure that I know of. You should subscribe to the mailing list, introduce yourself and request any commit rights you feel you need. Once that's done, you can start making pull requests and doing reviews of package submissions (formal or informal). Emmanuel ___ 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
Schedule for Thursday's FPC Meeting (2019-08-01 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2019-08-01 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): = Day: Thursday == 2019-08-01 09:00 PDT US/Pacific 2019-08-01 12:00 EDT --> US/Eastern <-- 2019-08-01 16:00 UTC UTC 2019-08-01 17:00 BST Europe/London 2019-08-01 18:00 CEST Europe/Berlin 2019-08-01 18:00 CEST Europe/Paris 2019-08-01 21:30 IST Asia/Calcutta New Day: Friday - 2019-08-02 00:00 HKT Asia/Hong_Kong 2019-08-02 00:00 +08 Asia/Singapore 2019-08-02 01:00 JST Asia/Tokyo 2019-08-02 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting = Followups = #topic #902 Cleanup & enhance spec files .fpc 902 https://pagure.io/packaging-committee/issue/902 #topic #904 Caret versioning .fpc 904 https://pagure.io/packaging-committee/issue/904 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #909 Suggest that linting/measuring-coverage is not for %check .fpc 909 https://pagure.io/packaging-committee/issue/909 = New business = #topic #914 Automatic R runtime dependencies .fpc 914 https://pagure.io/packaging-committee/issue/914 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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
python2->python3 mass rebuild and auto tools
Hello, I have a package that fails to build because libraries aren't where they are suposed to be. I looked at the project page https://fedoraproject.org/wiki/Changes/Python_means_Python3 and there is no mention of the effect on autotools. I have pyexec_PYTHON. What is supposed to be there? And since this is an upstream package consumed by all distributions and old versions of Fedora/ RHEL, what is the portable thing to do? There's other things out there like pybind_dir which are probably messed up, too. Should they be hardcoded to mean python2 in autotools and swig? -Steve ___ 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
Duplicate FTBFS bugs?
Seems like some script is being run a second time and is filing duplicate FTBFS bugs (unless there's some difference in these bugs which I'm not able to discern): https://bugzilla.redhat.com/show_bug.cgi?id=1735387 & https://bugzilla.redhat.com/show_bug.cgi?id=1734855 https://bugzilla.redhat.com/show_bug.cgi?id=1734862 & https://bugzilla.redhat.com/show_bug.cgi?id=1735393 https://bugzilla.redhat.com/show_bug.cgi?id=1734863 & https://bugzilla.redhat.com/show_bug.cgi?id=1735394 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd-243-rc1
On Wed, Jul 31, 2019 at 08:52:36PM +0200, Nicolas Mailhot via devel wrote:
> Le mercredi 31 juillet 2019 à 17:03 +0200, Andreas Tunek a écrit :
> >
> >
> > On Wed, 31 Jul 2019, 16:10 Nicolas Mailhot via devel, <
> > devel@lists.fedoraproject.org> wrote:
> > > Le 2019-07-31 14:13, Lennart Poettering a écrit :
> > >
> > > Hi Lennart
> > >
> > > > Note that there's a "stable" backport tree maintained outside of
> > > the
> > > > main repo:
> > > >
> > > > https://github.com/systemd/systemd-stable
> > > >
> > > > Either way, I doubt this discussion is relevant to Fedora, is it?
> > >
> > > It was when a lot of users could not test new Fedora devel kernels
> > > for
> > > about a month, because newer kernels exposed a bug in networkd, and
> > > the
> > > current systemd release + packaging process was unable to produce
> > > a
> > > Fedora devel systemd, that worked with Fedora devel kernels
> > >
> > >
> > > I thought Linux was supposed to never ever break username
> > > programmes?
>
> When you choose, like systemd, to rely heavily on kernel capabilities,
> with close integration, you pay a heavier price when mistake are made
> at the integration level (in this case, as far as I understand it, a
> latent networkd bug triggered by later kernel changes).
>
> And, mistakes happen in real life. So this kind of breakage is a
> natural and inevitable consequence of the way systemd was designed. It
> is not especially unexpected of scandalous by itself.
>
> What was *not* a natural consequence of design choices was the time
> taken to propagate the fix to affected systems. Broken networking when
> pretty much every system nowadays needs networking should have been a
> critical point-release fix, with downstream integrators just needing to
> bump their packaging/distribution process to the dot release update.
Oh, for heaven's sake. What has semantic versioning to do with
anything? The patches to fix the issue were known, and it is really
not complicated to rebuild systemd with a patch or two. This wasn't
done because the few systemd maintainers in Fedora are also upstream
developers and we were busy preparing for a release and solving other
issues and didn't have time to work on this particular bug.
This is at least a second proposal to make the process more
complicated, when the problem is in lack of maintainer time. Such
changes would only make things worse.
Also, when people are running an -rc kernel, some issues are expected.
In the beginning it wasn't even clear if the change in the kernel will
be reverted or not.
> And when,
> finally, systemd makes a new release, it does not even use integrator
> and automation-friendly semver numbering, but the awful human-oriented
> rcx labelling, that requires manual mapping to be understood by
> automation (wasting yet more integrator time).
Nah, not really. In systemd spec:
Version: 243~rc1
%global github_version %(c=%{version}; echo ${c}|tr '~' '-')
and that's all the mapping needed. Things just work ;)
> So, the relevancy to Fedora, that Lennart did not see, is that all this
> lack of care, results in longer breakage time in Fedora.
Seriously. We do care and I have no idea why you would say that we
don't. If you want to help, go triage or solve some bugs, there's ~200
open if Fedora and ~1000 open upstream, plenty to pick from.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
Frantisek Zatloukal writes: > On Wed, Jul 31, 2019 at 11:00 AM Kevin Kofler > wrote: > >> * the performance increase to be had is marginal, given that we are mostly >> talking about code written in C or C++ without even compiler >> vectorization >> (-ftree-vectorize) turned on, >> > > Are you sure? Fore example (and there are more of them), lots of these do > not seem marginal: > https://www.phoronix.com/scan.php?page=news_item=Clear-Linux-2019-Python-Perf > , https://www.phoronix.com/scan.php?page=article=linux-2016-2018=3 I see typically useless benchmarks without enough information, or profiles, that provide no real insight. These things rarely measure what they purport to; also error bars -- we've heard of them. Numpy is presumably dominated by level 3 BLAS (a library which is swappable on Ubuntu, as it should be in Fedora, with potentially two orders of magnitude performance difference in DGEMM), and whatever threading is used. I suspect similarly for the other things. First take Intel proprietary stuff out of the equation, and think about those numbers taken at face value. Note that using avx2 can be worse than sse2/4, and cache effects are often more important (as in optimized BLAS). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
I don't agree with the proposal, and am only interested in EPEL, but: Kevin Kofler writes: > I disagree with ANY raised vector instruction requirement, considering that: > * it would make Fedora incompatible with some hardware out there, That's already so for hardware which is at least of similar age to SSE2-only x86_64, i.e. POWER7; my build logs show -mcpu=power8. > * the performance increase to be had is marginal, given that we are mostly > talking about code written in C or C++ without even compiler vectorization > (-ftree-vectorize) turned on, I forget the details, but libxsmm is something that depends on an instruction introduced with SSE3, and is a good example of portable performance engineering over a wide range of (x86_64) processors. > * there are already mechanisms for runtime feature detection, which are > already widely used in those few packages that can actually benefit from > the vector instructions (because they are performance-sensitive and > because they have handwritten assembly or vector intrinsics code), I disagree that dynamic dispatch is sufficiently widely used in scientific code (probably can't be with Fortran). Also recent GCC can provide decent performance for specific targets without target-specific programming. BLIS' portable C version DGEMM got around 60%(?) the speed of the hand-tuned implementation built for haswell, as reported somewhere in the BLIS issues. For people who don't know, DEGMM (generalized matrix-matrix multiplication) is as SIMD-intensive as it gets, with high enough floating point intensity relative to memory access for large enough dimensions; non-matrix-matrix linear algebra typically doesn't if it doesn't fit in cache. ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019, 22:42 Kevin Fenzi wrote: > On 7/31/19 9:29 AM, Richard W.M. Jones wrote: > > On Wed, Jul 31, 2019 at 05:06:17PM +0100, Tom Hughes wrote: > >> On 31/07/2019 16:58, Pierre-Yves Chibon wrote: > >> > >>> My canary ran took 24 minutes, apparently the CI pipeline was slower > than usual > >>> but the rest of the workflow seemed fine. > >>> > >>> $ koji buildinfo ocaml-result-1.2-12.fc31 > >>> returns: > >>> Tags: f31 f31-updates-pending > >>> > >>> So it should be in the buildroot. Is it not? > >> > >> Well wait-repo is not returning: > >> > >> koji wait-repo --build=ocaml-result-1.2-12.fc31 f31-build > > > > It just went into the buildroot a few minutes ago. I think > > total waiting time was about 2 hours 20 mins for this one. > > Pretty puzzling... it looks like from tagging it went through really > fast, but somehow didn't land in the buildroot. ;( > > I'll look and see if there's some buildroot repo regen problem happening... > FWIW, I just built two packages (snakeyaml and xbean), and for both of them I received the "bodhi pushed this update to stable" email even before "fedpkg build" exited. So it's pretty fast now, at least for small packages like these. Fabio > kevin > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora-Rawhide-20190729.n.0 compose check report
On 7/29/19 10:40 AM, Yash Thakkar wrote: > Please remove me from this mailing list! I am trying to unsubscribe using > unsubscribe option for days! But I don't think that works! As the footer for every mail notes: > 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 just send an email to 'devel-le...@lists.fedoraproject.org' and it will unsubscribe you. 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: Rolling out Phase I of rawhide package gating
On 7/31/19 9:29 AM, Richard W.M. Jones wrote: > On Wed, Jul 31, 2019 at 05:06:17PM +0100, Tom Hughes wrote: >> On 31/07/2019 16:58, Pierre-Yves Chibon wrote: >> >>> My canary ran took 24 minutes, apparently the CI pipeline was slower than >>> usual >>> but the rest of the workflow seemed fine. >>> >>> $ koji buildinfo ocaml-result-1.2-12.fc31 >>> returns: >>> Tags: f31 f31-updates-pending >>> >>> So it should be in the buildroot. Is it not? >> >> Well wait-repo is not returning: >> >> koji wait-repo --build=ocaml-result-1.2-12.fc31 f31-build > > It just went into the buildroot a few minutes ago. I think > total waiting time was about 2 hours 20 mins for this one. Pretty puzzling... it looks like from tagging it went through really fast, but somehow didn't land in the buildroot. ;( I'll look and see if there's some buildroot repo regen problem happening... 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: Rolling out Phase I of rawhide package gating
On 7/31/19 12:05 PM, Nicolas Mailhot via devel wrote: > Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a > écrit : >>> "KF" == Kevin Fenzi writes: >> >> KF> * If you use metalinks, rpm signatures are just gravy on top, in >> the >> KF> end you are still just trusing SSL CA's. >> >> Only if you trust every mirror to always serve authentic content. > > And, just to provide another data point, we tried this month to make > the network install iso talk to https dnf repos (a reposync of fedora > devel x86_64, without x86 packages, because we don't have the storage > budget to mirror 32 bit packages we don't have the use for them > anyway). The repos themselves worked fine from installed systems. But, > anaconda refused to use them, till they were re-exposed in plain un- > secured http. Any errors? Bug filed? as long as the certs were valid/normal certs, there should not be any reason that wouldn't work I wouldn't think. 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
[Bug 1735227] fusioninventory-agent: FTBFS in Fedora rawhide/f31
https://bugzilla.redhat.com/show_bug.cgi?id=1735227 Miro Hrončok changed: What|Removed |Added Blocks||1700317 (F31FTBFS) Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1700317 [Bug 1700317] Fedora 31 FTBFS Tracker -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org
Re: Authentication in fedpkg
On Wed, Jul 31, 2019 at 3:46 PM Kevin Fenzi wrote: > > On 7/31/19 12:16 PM, Björn Persson wrote: > > Fabio Valentini wrote: > >> You can add your "kerberos account" to GNOME online accounts once, and > >> it will automatically renew tickets for you. > >> This way you'll never have to type your FAS password (or run kinit) > >> for this again. > > > > First, I don't use Gnome 3 because a software engineer's workstation has > > other needs than a hand-held Facebook terminal. > > Did you really have to include this? A simple 'I'm sorry, I don't use > Gnome' would have been fine... > > > > Second, As I understand what I've been told about Gnome Online Accounts, > > it would keep me constantly logged in to Fedora servers as long as I'm > > logged in to my workstation. That's appropriate for a corporate network > > or a university campus, which I suppose is what Kerberos is designed > > for. It's not appropriate for a project that I sometimes contribute to > > when I have time and when something needs doing. > > > > Fedora needs an authentication method that authenticates on demand, not > > proactively, using a keyring that isn't tied to a single desktop. > > Things are moving (all be it slowly) toward OIDC. > Are we talking about OIDC like how Bodhi does it or like how fedpkg https auth does it? Because the latter is pretty difficult to use when you're in a server environment. :( > Sorry they are all over the place right now... > We'll eventually get there... -- 真実はいつも一つ！/ 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: Authentication in fedpkg
On 7/31/19 12:16 PM, Björn Persson wrote: > Fabio Valentini wrote: >> You can add your "kerberos account" to GNOME online accounts once, and >> it will automatically renew tickets for you. >> This way you'll never have to type your FAS password (or run kinit) >> for this again. > > First, I don't use Gnome 3 because a software engineer's workstation has > other needs than a hand-held Facebook terminal. Did you really have to include this? A simple 'I'm sorry, I don't use Gnome' would have been fine... > > Second, As I understand what I've been told about Gnome Online Accounts, > it would keep me constantly logged in to Fedora servers as long as I'm > logged in to my workstation. That's appropriate for a corporate network > or a university campus, which I suppose is what Kerberos is designed > for. It's not appropriate for a project that I sometimes contribute to > when I have time and when something needs doing. > > Fedora needs an authentication method that authenticates on demand, not > proactively, using a keyring that isn't tied to a single desktop. Things are moving (all be it slowly) toward OIDC. Sorry they are all over the place right 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: mass rebuild, glusterfs build failed
On 7/31/19 12:01 PM, Kaleb Keithley wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1733602 > > One of the suggestions there is to "drop the arch." I.e. i686. > > If that ends up being the solution that pretty much would force me to drop > the arch too for glusterfs. (GlusterFS has a bit of plumbing around opening > ports in the firewall. It might just fail — silently or not so silently. > It's hard to know, nobody has tested it. > > I suspect dropping the arch might cause some amount of heartache in some > circles. > > OTOH, I haven't paid close enough attention to really understand what it > means to stop building i686 kernels. Does that mean no Fedora distribution > for i686 hardware? Does it even make sense to keep building glusterfs for > i686? I would drop the kernel dependency. It doesn't make sense already in some contexts (containers) and this is a Fedora package for Fedora users, so I think anyone who would install it would have a kernel, and if it's a supported Fedora release it would be larger than 4.18.0. Dropping i686 kernels just means there's no more media/images for i686, but we keep building everything in case we need it for multilib. I would assume now you should keep building things, and if there's a change down the road to limit the scope of i686 more you could drop it when/if it makes sense then. 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: Authentication in fedpkg
On Wed, 31 Jul 2019 at 14:00, Björn Persson wrote: > > I'm sorry to be complaining. I know everybody has too much to do (myself > included), but seriously folks, this needs to be improved. This is not > a good user experience. I hope the plans to retire some less important > services will lead to somebody finding some time to improve the user > interface for these essential tasks. > > FAS has been on the block to replace/fix for over 10 years. Changes in authentication methods require a lot of dedicated work because it affects all workflows somewhere.. and because it would mean so much downtime.. it has never gotten the resources in time and engineers to do. Even taking someone else's existing solution and using it requires rewriting a lot of tools to get it to work consistently. It also sometimes means something we could do before is gone. So instead we have had to jury rig in a new method each time a service comes in.. all in the hopes that next year we can get the replacement. I would love that I could wave a magic wand and fix this.. but I would have done that any time in the last 10 years. -- 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: mass rebuild, glusterfs build failed
On Wed, 31 Jul 2019 at 15:10, Kaleb Keithley wrote: > > > On Fri, Jul 26, 2019 at 1:31 PM Kevin Fenzi wrote: > >> On 7/25/19 11:05 AM, Kaleb Keithley wrote: >> > hmmm. from the root.log >> > >> > DEBUG util.py:585: BUILDSTDERR: Error: >> > DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests >> > DEBUG util.py:585: BUILDSTDERR: - nothing provides kernel >= 4.18.0 >> > needed by firewalld-0.6.4-1.fc31.noarch >> > >> > how to deal with this? Wait for a new firewalld package? >> >> Yep. >> >> I have asked the 'dropping i686 kernels' change owner to file bugs on >> these packages. >> >> Looks like: >> >> firewalld-0.7.1-1.fc31.src.rpm >> > > https://bugzilla.redhat.com/show_bug.cgi?id=1733602 > > One of the suggestions there is to "drop the arch." I.e. i686. > > If that ends up being the solution that pretty much would force me to drop > the arch too for glusterfs. (GlusterFS has a bit of plumbing around opening > ports in the firewall. It might just fail — silently or not so silently. > It's hard to know, nobody has tested it. > > I suspect dropping the arch might cause some amount of heartache in some > circles. > > OTOH, I haven't paid close enough attention to really understand what it > means to stop building i686 kernels. Does that mean no Fedora distribution > for i686 hardware? Does it even make sense to keep building glusterfs for > i686? > > Yes it means no Fedora distribution for i686 for F31+. I would say that unless your binary is needed for multi-arch, then it also does not make sense to make it for i686 at this point. -- 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: Authentication in fedpkg
Fabio Valentini wrote: >You can add your "kerberos account" to GNOME online accounts once, and >it will automatically renew tickets for you. >This way you'll never have to type your FAS password (or run kinit) >for this again. First, I don't use Gnome 3 because a software engineer's workstation has other needs than a hand-held Facebook terminal. Second, As I understand what I've been told about Gnome Online Accounts, it would keep me constantly logged in to Fedora servers as long as I'm logged in to my workstation. That's appropriate for a corporate network or a university campus, which I suppose is what Kerberos is designed for. It's not appropriate for a project that I sometimes contribute to when I have time and when something needs doing. Fedora needs an authentication method that authenticates on demand, not proactively, using a keyring that isn't tied to a single desktop. Björn Persson pgpziqBZjQ23X.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
[Bug 1735227] fusioninventory-agent: FTBFS in Fedora rawhide/f31
https://bugzilla.redhat.com/show_bug.cgi?id=1735227 --- Comment #1 from Fedora Release Engineering --- Created attachment 1596162 --> https://bugzilla.redhat.com/attachment.cgi?id=1596162=edit build.log file build.log too big, will only attach last 32768 bytes -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org
[Bug 1735227] fusioninventory-agent: FTBFS in Fedora rawhide/f31
https://bugzilla.redhat.com/show_bug.cgi?id=1735227 --- Comment #3 from Fedora Release Engineering --- Created attachment 1596164 --> https://bugzilla.redhat.com/attachment.cgi?id=1596164=edit state.log -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org
[Bug 1735227] New: fusioninventory-agent: FTBFS in Fedora rawhide/f31
https://bugzilla.redhat.com/show_bug.cgi?id=1735227 Bug ID: 1735227 Summary: fusioninventory-agent: FTBFS in Fedora rawhide/f31 Product: Fedora Version: rawhide Status: NEW Component: fusioninventory-agent Assignee: maria...@tuxette.fr Reporter: rel...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jo...@x-tnd.be, maria...@tuxette.fr, perl-devel@lists.fedoraproject.org Blocks: 1732841 Target Milestone: --- Classification: Fedora fusioninventory-agent failed to build from source in Fedora rawhide/f31 https://koji.fedoraproject.org/koji/taskinfo?taskID=36633394 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild Please fix fusioninventory-agent at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, fusioninventory-agent will be orphaned. Before branching of Fedora 32, fusioninventory-agent will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1732841 [Bug 1732841] (F31FTBFS) - Fedora 31 FTBFS Tracker -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org
[Bug 1735227] fusioninventory-agent: FTBFS in Fedora rawhide/f31
https://bugzilla.redhat.com/show_bug.cgi?id=1735227 --- Comment #2 from Fedora Release Engineering --- Created attachment 1596163 --> https://bugzilla.redhat.com/attachment.cgi?id=1596163=edit root.log file root.log too big, will only attach last 32768 bytes -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@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-devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
Le mercredi 31 juillet 2019 à 12:25 -0500, Jason L Tibbitts III a écrit : > > > > > > "KF" == Kevin Fenzi writes: > > KF> * If you use metalinks, rpm signatures are just gravy on top, in > the > KF> end you are still just trusing SSL CA's. > > Only if you trust every mirror to always serve authentic content. And, just to provide another data point, we tried this month to make the network install iso talk to https dnf repos (a reposync of fedora devel x86_64, without x86 packages, because we don't have the storage budget to mirror 32 bit packages we don't have the use for them anyway). The repos themselves worked fine from installed systems. But, anaconda refused to use them, till they were re-exposed in plain un- secured http. TLS is a fine thing in theory, but relying on it requires a lot more debugging capabilities, than the ones we built in our tools. TLS stacks are heavily biaised towards refusing to connect as soon as something does not matches their expectations (and they usually forget to tell you what they didn't like). -- Nicolas Mailhot ___ 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: mass rebuild, glusterfs build failed
On Fri, Jul 26, 2019 at 1:31 PM Kevin Fenzi wrote: > On 7/25/19 11:05 AM, Kaleb Keithley wrote: > > hmmm. from the root.log > > > > DEBUG util.py:585: BUILDSTDERR: Error: > > DEBUG util.py:585: BUILDSTDERR: Problem: conflicting requests > > DEBUG util.py:585: BUILDSTDERR: - nothing provides kernel >= 4.18.0 > > needed by firewalld-0.6.4-1.fc31.noarch > > > > how to deal with this? Wait for a new firewalld package? > > Yep. > > I have asked the 'dropping i686 kernels' change owner to file bugs on > these packages. > > Looks like: > > firewalld-0.7.1-1.fc31.src.rpm > https://bugzilla.redhat.com/show_bug.cgi?id=1733602 One of the suggestions there is to "drop the arch." I.e. i686. If that ends up being the solution that pretty much would force me to drop the arch too for glusterfs. (GlusterFS has a bit of plumbing around opening ports in the firewall. It might just fail — silently or not so silently. It's hard to know, nobody has tested it. I suspect dropping the arch might cause some amount of heartache in some circles. OTOH, I haven't paid close enough attention to really understand what it means to stop building i686 kernels. Does that mean no Fedora distribution for i686 hardware? Does it even make sense to keep building glusterfs for i686? -- Kaleb ___ 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: systemd-243-rc1
Le mercredi 31 juillet 2019 à 17:03 +0200, Andreas Tunek a écrit : > > > On Wed, 31 Jul 2019, 16:10 Nicolas Mailhot via devel, < > devel@lists.fedoraproject.org> wrote: > > Le 2019-07-31 14:13, Lennart Poettering a écrit : > > > > Hi Lennart > > > > > Note that there's a "stable" backport tree maintained outside of > > the > > > main repo: > > > > > > https://github.com/systemd/systemd-stable > > > > > > Either way, I doubt this discussion is relevant to Fedora, is it? > > > > It was when a lot of users could not test new Fedora devel kernels > > for > > about a month, because newer kernels exposed a bug in networkd, and > > the > > current systemd release + packaging process was unable to produce > > a > > Fedora devel systemd, that worked with Fedora devel kernels > > > > > > I thought Linux was supposed to never ever break username > > programmes? When you choose, like systemd, to rely heavily on kernel capabilities, with close integration, you pay a heavier price when mistake are made at the integration level (in this case, as far as I understand it, a latent networkd bug triggered by later kernel changes). And, mistakes happen in real life. So this kind of breakage is a natural and inevitable consequence of the way systemd was designed. It is not especially unexpected of scandalous by itself. What was *not* a natural consequence of design choices was the time taken to propagate the fix to affected systems. Broken networking when pretty much every system nowadays needs networking should have been a critical point-release fix, with downstream integrators just needing to bump their packaging/distribution process to the dot release update. Instead, as Lennart explained, systemd has no strong release discipline. systemd didn't provide anyone a fixed version (requiring fishing the fix in its git, and wasting integrator time). And when, finally, systemd makes a new release, it does not even use integrator and automation-friendly semver numbering, but the awful human-oriented rcx labelling, that requires manual mapping to be understood by automation (wasting yet more integrator time). So, the relevancy to Fedora, that Lennart did not see, is that all this lack of care, results in longer breakage time in Fedora. -- Nicolas Mailhot ___ 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: Rolling out Phase I of rawhide package gating
On 7/31/19 11:09 AM, Florian Weimer wrote: > * Jason L. Tibbitts, III: > >>> "FW" == Florian Weimer writes: >> >> FW> At one point, there was a verified hash chain from the https:// >> FW> metalink service, to the repository metadata, down to individual >> FW> packages. Any tampering was detected then. >> >> I understand that the metalink contains enough information to verify the >> returnes repomd.xml files, but I guess I don't really know if there's >> enough data to chase that down to the checksum of every file that's ever >> expected to be on a mirror. > > repomd.xml has hashes for primary.xml etc., and primary.xml contains > digests of the RPM files. In theory, it can all be checked. Yes, it's all checked and if tampered with would fail. You get the metalink via https from our mirrorlist containers running on our proxies. This metalink has in it a list of mirrors that the checksums for the repomd.xml file that is valid. You go to one of those mirrors. If repomd.xml was tampered with, dnf will call it broken and go on. If someone tampers with packages they would not match the other checksums in the repomd.xml and be treated as corrupt. If you are using metalink and not mirrorlist or pointing directly to a mirror, you should be safe. > At one point, RPM wrote unchecked file contents to disk, leading to > vulnerabilities such as CVE-2013-6435. At the time, it was not possible > to teach RPM to verify the data before writing it. > >> If it is, then great, though signatures still have value because there >> are other ways to get RPMs than letting dnf hit the mirror network. > > I think dnf only performs signature checking if the RPMs are downloaded > from repositories. Yep. I am pretty sure that is the case. 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: systemd-243-rc1
On Wed, 31 Jul 2019 at 13:25, Lennart Poettering wrote: > On Mi, 31.07.19 12:57, Tomasz Kłoczko (kloczko.tom...@gmail.com) wrote: > > > As usually that type of versioning convention is rubbish and it only adds > > more work on packaging layer. > > Why you guys did not released that as v243.99 ? > > I like my bikesheds blue. > Yes. Today is a bit sunny in London. Thanks for asking .. and ignoring that rc versioning convention adds some overhead on packaging layer. Your bikeshed argument is really powerful so I can only give up. > Other thing is that looks like systemd devel cycle elongated and it cased > > that some stabilisation fixes are only committed in master branch with > all > > other changes. > > > > Proposal for next systemd devel cycle: > > - create devel branch and commit all devel changes in that branch only + > > stable fixes > > - commit in master branch only stable fixes and release more ofthen > v244.1, > > v244.2 and so on (one time a month or even more often depends on > importance > > of the fixes) > > - release candidates starting from v244.99 > > - when everything in devel will be ready just merge devel branch to > master > > and tag it as new major release. > > Are you volunteering to do the work for this? Or do you just expect us > upstream to maintain twice the amount of releases? > > We don't want to be consumed in just doing release mangament. It's > hard enough, and we definitely prefer if developers focus on one > master, not many, and stop developing new stuff while we are in release > mode. This means, doing parallel branches for upstream development is > not in the cards, sorry. Either everyone stabilizes or everyone works > on new stuff. > > Note that there's a "stable" backport tree maintained outside of the > main repo: > > https://github.com/systemd/systemd-stable In other words you asking me voluntary do the job which is already done. Nice. OK, I'll take that job. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dnf & rpm-devel both seem to be uninstallable in the Rawhide buildroot
On 31. 07. 19 20:18, Richard W.M. Jones wrote: On Wed, Jul 31, 2019 at 08:02:30PM +0200, Miro Hrončok wrote: On 31. 07. 19 19:54, Miro Hrončok wrote: On 31. 07. 19 19:45, Richard W.M. Jones wrote: The error is: DEBUG util.py:585: BUILDSTDERR: Error: DEBUG util.py:585: BUILDSTDERR: Problem 1: package rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires librpmsign.so.9()(64bit), but none of the providers can be installed ... https://src.fedoraproject.org/rpms/ima-evm-utils/c/5c9e2a91303d801bd828ad63bd8fe3ea2bab3e17?branch=master This updated soname version from libimaevm.so.0 to libimaevm.so.1. There was no announcement and no coordination. RPM rebuild running https://koji.fedoraproject.org/koji/taskinfo?taskID=36710136 Great, thanks for fixing that so quickly. Followup: https://src.fedoraproject.org/rpms/ima-evm-utils/pull-request/1 -- 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: Authentication in fedpkg
On Wed, Jul 31, 2019 at 8:00 PM Björn Persson wrote: > > I recently added two new packages to Fedora. Things have changed a bit > since the previous time I did this, and more things can now be done > through fedpkg. I would like to share my experience with this. This is > what the procedure is like for a volunteer who only sometimes works on > Fedora stuff: Even as someone who contributes to fedora on an almost daily basis, these are some things that confuse me from time to time. > · When the package has passed review I need to request a Git repository. > There's a handy command for that: "fedpkg request-repo". But before I > can run that I must log in to a special web interface and get an API > token that I must paste into a configuration file that I've otherwise > never heard of. This comes across as a half-baked design. > The token expires, so next time I add a package I'll have to do this > again. I won't remember the URL, nor the pathname of the file, so I'll > have to look them up every time. This is because pagure handles authenticated requests via an API token. In this case, access with the API token is required to be able to create a new ticket for the "new repository queue". > · Once the repository exists I need to clone it with "fedpkg clone". > This requires SSH authentication. This is the method I like best, > partly because it uses a key encrypted with a master passphrase, so > that the passphrase I type never leaves my workstation, but also because > it's the same SSH that I use all the time, so I already know how to > manage it. SSH key management is actually rather clumsy; I'm just used > to it. > > · The next step is to add files to the repository and upload the source > tarball. Again there's a handy command: "fedpkg import". But that fails > halfway through because I'm not authenticated with Kerberos. It doesn't > even ask me for a password. Instead I have to run a kinit command to > authenticate. This gives the impression that somebody completely forgot > to implement the authentication bit. I think this is caused by the upload to the lookaside cache using curl with kerberos authentication. > Another problem with this method is that it expects me to directly type > in the shared secret. I can't have the secret stored in a keyring > encrypted with a master passphrase. You can add your "kerberos account" to GNOME online accounts once, and it will automatically renew tickets for you. This way you'll never have to type your FAS password (or run kinit) for this again. > Then I retry "fedpkg import", but that fails because of the files it > added to Git the first time, and I have to upload the tarball with > "fedpkg new-sources" instead. > > · Before I build the new package I may need a buildroot override. > "fedpkg override" is the command, and it appears to use yet another > authentication method. This one is actually capable of asking for a > password. It doesn't say which password it wants, but I tried the FAS > password and it was apparently right. It even seems to cache the > password or some authentication token, because it doesn't ask again > when I request a second buildroot override. This is because creating an override uses the bodhi python client bindings. bodhi uses OpenID for authentication, so that's FAS username and FAS password. The bodhi client bindings use openid authentication from the "fedora" python package, which does some limited amount of credentials / cookie caching on disk, which is why you don't have to authenticate with password every time. > This is better thought-out than request-repo and the various upload and > build commands, but even this method expects me to type in the shared > secret. There is no keyring option as far as I can tell. > > One task, one front-end program, four different authentication methods, > each with its own idiosyncrasies. It's not even four separate accounts. > Everything hinges on the same FAS password. (Even SSH keys are managed > with the FAS password.) Why do I have to authenticate to the same > account four times in four different ways? As far as I can tell, that's because it calls different web services in the background, which use different authentication mechanisms. > I'm sorry to be complaining. I know everybody has too much to do (myself > included), but seriously folks, this needs to be improved. This is not > a good user experience. I hope the plans to retire some less important > services will lead to somebody finding some time to improve the user > interface for these essential tasks. I think there's an active effort to use OpenID Connect authentication for more services (at least for bodhi). > I would think that the infrastructure team's lives would be easier with > fewer authentication protocols to worry about, but as a user I'd be > satisfied if the incoherence would be hidden behind a consistent user > interface. Here are some improvements I would like to see: > > 1: If the various upload and build
Re: dnf & rpm-devel both seem to be uninstallable in the Rawhide buildroot
> "MH" == Miro Hrončok writes: MH> https://src.fedoraproject.org/rpms/ima-evm-utils/c/5c9e2a91303d801bd828ad63bd8fe3ea2bab3e17?branch=master MH> This updated soname version from libimaevm.so.0 to libimaevm.so.1. Note that it also added a dependency on the tss2 package. That's small and doesn't have unexpected dependencies (just openssl) so it's not a huge deal, but... it's a sign of just how easy it is for these dependency chains to grow unchecked. Fortunately rpm-sign-libs isn't part of the buildroot. - J< MH> There was no announcement and no coordination. MH> -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok MH> ___ devel mailing list MH> -- devel@lists.fedoraproject.org To unsubscribe send an email to MH> devel-le...@lists.fedoraproject.org Fedora Code of Conduct: MH> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List MH> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines MH> List Archives: MH> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Jason L Tibbitts III - j...@tib.bs - 713/743-3486 - 660PGH System Manager: University of Houston Mathematics ___ 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: dnf & rpm-devel both seem to be uninstallable in the Rawhide buildroot
On Wed, Jul 31, 2019 at 08:02:30PM +0200, Miro Hrončok wrote: > On 31. 07. 19 19:54, Miro Hrončok wrote: > >On 31. 07. 19 19:45, Richard W.M. Jones wrote: > >>The error is: > >> > >>DEBUG util.py:585: BUILDSTDERR: Error: > >>DEBUG util.py:585: BUILDSTDERR: Problem 1: package > >>rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires > >>librpmsign.so.9()(64bit), but none of the providers can be > >>installed > >>... > > > >https://src.fedoraproject.org/rpms/ima-evm-utils/c/5c9e2a91303d801bd828ad63bd8fe3ea2bab3e17?branch=master > > > > > >This updated soname version from libimaevm.so.0 to libimaevm.so.1. > > > >There was no announcement and no coordination. > > RPM rebuild running > https://koji.fedoraproject.org/koji/taskinfo?taskID=36710136 Great, thanks for fixing that so quickly. 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: Rolling out Phase I of rawhide package gating
* Jason L. Tibbitts, III: >> "FW" == Florian Weimer writes: > > FW> At one point, there was a verified hash chain from the https:// > FW> metalink service, to the repository metadata, down to individual > FW> packages. Any tampering was detected then. > > I understand that the metalink contains enough information to verify the > returnes repomd.xml files, but I guess I don't really know if there's > enough data to chase that down to the checksum of every file that's ever > expected to be on a mirror. repomd.xml has hashes for primary.xml etc., and primary.xml contains digests of the RPM files. In theory, it can all be checked. At one point, RPM wrote unchecked file contents to disk, leading to vulnerabilities such as CVE-2013-6435. At the time, it was not possible to teach RPM to verify the data before writing it. > If it is, then great, though signatures still have value because there > are other ways to get RPMs than letting dnf hit the mirror network. I think dnf only performs signature checking if the RPMs are downloaded from repositories. Thanks, Florian ___ 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: s390x rawhide issues?
Tom Callaway skrev: >One of my packages (alienarena) fails to build in rawhide on s390x (and >only that arch), but the build log shows it never even starts. When I look >at the root log, I see this: > >DEBUG util.py:585: BUILDSTDERR: error: unpacking of archive failed on file >/builddir/build/SOURCES/alienarena-7.71.0-svn5638.tar.xz;5d41b327: cpio: >read failed - Inappropriate ioctl for device >DEBUG util.py:585: BUILDSTDERR: error: >/builddir/build/originals/alienarena-7.71.0-3.fc31.src.rpm cannot be >installed This seems to be the canonical ticket: https://pagure.io/koji/issue/1418 The workaround seems to be to resubmit until it works. Björn Persson pgpoFArv5kPGy.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: s390x rawhide issues?
> "TC" == Tom Callaway writes: TC> One of my packages (alienarena) fails to build in rawhide on s390x TC> (and only that arch), but the build log shows it never even TC> starts. Does it fail repeatably? This error is known but as far as I know it's always been transient. It only seems to crop up when the s390x builders are very loaded. - J< ___ 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: dnf & rpm-devel both seem to be uninstallable in the Rawhide buildroot
On 31. 07. 19 19:54, Miro Hrončok wrote: On 31. 07. 19 19:45, Richard W.M. Jones wrote: The error is: DEBUG util.py:585: BUILDSTDERR: Error: DEBUG util.py:585: BUILDSTDERR: Problem 1: package rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires librpmsign.so.9()(64bit), but none of the providers can be installed ... https://src.fedoraproject.org/rpms/ima-evm-utils/c/5c9e2a91303d801bd828ad63bd8fe3ea2bab3e17?branch=master This updated soname version from libimaevm.so.0 to libimaevm.so.1. There was no announcement and no coordination. RPM rebuild running https://koji.fedoraproject.org/koji/taskinfo?taskID=36710136 -- 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: s390x rawhide issues?
On 31. 07. 19 19:08, Tom Callaway wrote: One of my packages (alienarena) fails to build in rawhide on s390x (and only that arch), but the build log shows it never even starts. When I look at the root log, I see this: DEBUG util.py:585: BUILDSTDERR: error: unpacking of archive failed on file /builddir/build/SOURCES/alienarena-7.71.0-svn5638.tar.xz;5d41b327: cpio: read failed - Inappropriate ioctl for device DEBUG util.py:585: BUILDSTDERR: error: /builddir/build/originals/alienarena-7.71.0-3.fc31.src.rpm cannot be installed A new build fixed this for me for various packages that failed for this very reason. https://pagure.io/releng/issue/8555#comment-584582 -- 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
Authentication in fedpkg
I recently added two new packages to Fedora. Things have changed a bit since the previous time I did this, and more things can now be done through fedpkg. I would like to share my experience with this. This is what the procedure is like for a volunteer who only sometimes works on Fedora stuff: · When the package has passed review I need to request a Git repository. There's a handy command for that: "fedpkg request-repo". But before I can run that I must log in to a special web interface and get an API token that I must paste into a configuration file that I've otherwise never heard of. This comes across as a half-baked design. The token expires, so next time I add a package I'll have to do this again. I won't remember the URL, nor the pathname of the file, so I'll have to look them up every time. · Once the repository exists I need to clone it with "fedpkg clone". This requires SSH authentication. This is the method I like best, partly because it uses a key encrypted with a master passphrase, so that the passphrase I type never leaves my workstation, but also because it's the same SSH that I use all the time, so I already know how to manage it. SSH key management is actually rather clumsy; I'm just used to it. · The next step is to add files to the repository and upload the source tarball. Again there's a handy command: "fedpkg import". But that fails halfway through because I'm not authenticated with Kerberos. It doesn't even ask me for a password. Instead I have to run a kinit command to authenticate. This gives the impression that somebody completely forgot to implement the authentication bit. Another problem with this method is that it expects me to directly type in the shared secret. I can't have the secret stored in a keyring encrypted with a master passphrase. Then I retry "fedpkg import", but that fails because of the files it added to Git the first time, and I have to upload the tarball with "fedpkg new-sources" instead. · Before I build the new package I may need a buildroot override. "fedpkg override" is the command, and it appears to use yet another authentication method. This one is actually capable of asking for a password. It doesn't say which password it wants, but I tried the FAS password and it was apparently right. It even seems to cache the password or some authentication token, because it doesn't ask again when I request a second buildroot override. This is better thought-out than request-repo and the various upload and build commands, but even this method expects me to type in the shared secret. There is no keyring option as far as I can tell. One task, one front-end program, four different authentication methods, each with its own idiosyncrasies. It's not even four separate accounts. Everything hinges on the same FAS password. (Even SSH keys are managed with the FAS password.) Why do I have to authenticate to the same account four times in four different ways? I'm sorry to be complaining. I know everybody has too much to do (myself included), but seriously folks, this needs to be improved. This is not a good user experience. I hope the plans to retire some less important services will lead to somebody finding some time to improve the user interface for these essential tasks. I would think that the infrastructure team's lives would be easier with fewer authentication protocols to worry about, but as a user I'd be satisfied if the incoherence would be hidden behind a consistent user interface. Here are some improvements I would like to see: 1: If the various upload and build commands could ask for the FAS password and perform the Kerberos authentication, instead of just giving up, then that would be a good start. 2: If the request-repo command and its relatives could ask for the FAS password and use that to acquire their API tokens under the hood, then that would greatly improve usability. 3: Once points 1 and 2 are done, it would be great if all commands that need the FAS password were able to fetch it from a common keyring. The first time the keyring program would ask me to unlock the keyring with the master passphrase. The master passphrase wouldn't be sent anywhere; it would only be used for decrypting the FAS password. After that the password would be automatically fetched from the keyring each time it's needed, just like it works with the SSH agent. That way I'd only need to remember the master passphrase, and I wouldn't need to manually copy the FAS password from the keyring to various password prompts. 4: If point 3 would be implemented, then the FAS password would be about as user-friendly as an SSH key. Then, and not before, it might make sense to use Kerberos authentication in SSH, if the Kerberos bits were able to fetch the password from the keyring described in point 3. 5: This point is less important than the others, but it would also be nice if Pagure would refrain from spamming me with warnings that my API key (token, key, whatever) is about to expire and
Re: Rolling out Phase I of rawhide package gating
> "FW" == Florian Weimer writes: FW> At one point, there was a verified hash chain from the https:// FW> metalink service, to the repository metadata, down to individual FW> packages. Any tampering was detected then. I understand that the metalink contains enough information to verify the returnes repomd.xml files, but I guess I don't really know if there's enough data to chase that down to the checksum of every file that's ever expected to be on a mirror. If it is, then great, though signatures still have value because there are other ways to get RPMs than letting dnf hit the mirror network. - J< ___ 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: dnf & rpm-devel both seem to be uninstallable in the Rawhide buildroot
On 31. 07. 19 19:45, Richard W.M. Jones wrote: The error is: DEBUG util.py:585: BUILDSTDERR: Error: DEBUG util.py:585: BUILDSTDERR: Problem 1: package rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires librpmsign.so.9()(64bit), but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - package rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires rpm-sign-libs(x86-64) = 4.15.0-0.beta.2.fc31.1, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - conflicting requests DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by rpm-sign-libs-4.15.0-0.beta.2.fc31.1.x86_64 DEBUG util.py:585: BUILDSTDERR: Problem 2: package dnf-4.2.7-3.fc31.noarch requires python3-dnf = 4.2.7-3.fc31, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - package python3-dnf-4.2.7-3.fc31.noarch requires python3-rpm >= 4.14.0, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - conflicting requests DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by python3-rpm-4.15.0-0.beta.2.fc31.1.x86_64 DEBUG util.py:585: BUILDSTDERR: Problem 3: package python3-dnf-plugins-core-4.0.7-2.fc31.noarch requires python3-dnf >= 4.2.1, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - package dnf-plugins-core-4.0.7-2.fc31.noarch requires python3-dnf-plugins-core = 4.0.7-2.fc31, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - package python3-dnf-4.2.7-3.fc31.noarch requires python3-rpm >= 4.14.0, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - conflicting requests DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by python3-rpm-4.15.0-0.beta.2.fc31.1.x86_64 https://src.fedoraproject.org/rpms/ima-evm-utils/c/5c9e2a91303d801bd828ad63bd8fe3ea2bab3e17?branch=master This updated soname version from libimaevm.so.0 to libimaevm.so.1. There was no announcement and no coordination. -- 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: Rolling out Phase I of rawhide package gating
* Jason L. Tibbitts, III: >> "KF" == Kevin Fenzi writes: > > KF> * If you use metalinks, rpm signatures are just gravy on top, in the > KF> end you are still just trusing SSL CA's. > > Only if you trust every mirror to always serve authentic content. At one point, there was a verified hash chain from the https:// metalink service, to the repository metadata, down to individual packages. Any tampering was detected then. I don't know if all the pieces (including the installer) still use the metalink service over https:// and verify the hashes. Thanks, Florian ___ 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
dnf & rpm-devel both seem to be uninstallable in the Rawhide buildroot
The error is: DEBUG util.py:585: BUILDSTDERR: Error: DEBUG util.py:585: BUILDSTDERR: Problem 1: package rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires librpmsign.so.9()(64bit), but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - package rpm-devel-4.15.0-0.beta.2.fc31.1.x86_64 requires rpm-sign-libs(x86-64) = 4.15.0-0.beta.2.fc31.1, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - conflicting requests DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by rpm-sign-libs-4.15.0-0.beta.2.fc31.1.x86_64 DEBUG util.py:585: BUILDSTDERR: Problem 2: package dnf-4.2.7-3.fc31.noarch requires python3-dnf = 4.2.7-3.fc31, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - package python3-dnf-4.2.7-3.fc31.noarch requires python3-rpm >= 4.14.0, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - conflicting requests DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by python3-rpm-4.15.0-0.beta.2.fc31.1.x86_64 DEBUG util.py:585: BUILDSTDERR: Problem 3: package python3-dnf-plugins-core-4.0.7-2.fc31.noarch requires python3-dnf >= 4.2.1, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - package dnf-plugins-core-4.0.7-2.fc31.noarch requires python3-dnf-plugins-core = 4.0.7-2.fc31, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - package python3-dnf-4.2.7-3.fc31.noarch requires python3-rpm >= 4.14.0, but none of the providers can be installed DEBUG util.py:585: BUILDSTDERR: - conflicting requests DEBUG util.py:585: BUILDSTDERR: - nothing provides libimaevm.so.0()(64bit) needed by python3-rpm-4.15.0-0.beta.2.fc31.1.x86_64 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
> "KF" == Kevin Fenzi writes: KF> * If you use metalinks, rpm signatures are just gravy on top, in the KF> end you are still just trusing SSL CA's. Only if you trust every mirror to always serve authentic content. - J< ___ 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
FedoraRespin-30-updates-20190730.0 compose check report
No missing expected images. Failed openQA tests: 1/27 (x86_64) ID: 428120 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/428120 Soft failed openQA tests: 1/27 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 428103 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/428103 Passed openQA tests: 25/27 (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
s390x rawhide issues?
One of my packages (alienarena) fails to build in rawhide on s390x (and only that arch), but the build log shows it never even starts. When I look at the root log, I see this: DEBUG util.py:585: BUILDSTDERR: error: unpacking of archive failed on file /builddir/build/SOURCES/alienarena-7.71.0-svn5638.tar.xz;5d41b327: cpio: read failed - Inappropriate ioctl for device DEBUG util.py:585: BUILDSTDERR: error: /builddir/build/originals/alienarena-7.71.0-3.fc31.src.rpm cannot be installed Is something unhappy on s390x on rawhide? Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=36706646 Thanks in advance, Tom ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 05:06:17PM +0100, Tom Hughes wrote: > On 31/07/2019 16:58, Pierre-Yves Chibon wrote: > > >My canary ran took 24 minutes, apparently the CI pipeline was slower than > >usual > >but the rest of the workflow seemed fine. > > > >$ koji buildinfo ocaml-result-1.2-12.fc31 > >returns: > > Tags: f31 f31-updates-pending > > > >So it should be in the buildroot. Is it not? > > Well wait-repo is not returning: > > koji wait-repo --build=ocaml-result-1.2-12.fc31 f31-build It just went into the buildroot a few minutes ago. I think total waiting time was about 2 hours 20 mins for this one. 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: Rolling out Phase I of rawhide package gating
On 7/31/19 9:06 AM, Tom Hughes wrote: > On 31/07/2019 16:58, Pierre-Yves Chibon wrote: > >> My canary ran took 24 minutes, apparently the CI pipeline was slower >> than usual >> but the rest of the workflow seemed fine. >> >> $ koji buildinfo ocaml-result-1.2-12.fc31 >> returns: >> Tags: f31 f31-updates-pending >> >> So it should be in the buildroot. Is it not? > > Well wait-repo is not returning: > > koji wait-repo --build=ocaml-result-1.2-12.fc31 f31-build It's there now. Odd that it would take that long for a newrepo... According to koji tag history it should have been done like 10 hours ago, and signing took... 20 seconds. Wed Jul 31 07:50:50 2019: ocaml-result-1.2-12.fc31 tagged into f31-updates-candidate by rjones Wed Jul 31 07:51:00 2019: ocaml-result-1.2-12.fc31 untagged from f31-updates-candidate by autopen Wed Jul 31 07:51:00 2019: ocaml-result-1.2-12.fc31 tagged into f31-updates-testing-pending by autopen Wed Jul 31 07:51:06 2019: ocaml-result-1.2-12.fc31 untagged from f31-updates-testing-pending by bodhi Wed Jul 31 07:51:09 2019: ocaml-result-1.2-12.fc31 tagged into f31 by bodhi [still active] Wed Jul 31 07:51:10 2019: ocaml-result-1.2-12.fc31 tagged into f31-updates-pending by bodhi [still active] 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 08:52:52AM -0700, Kevin Fenzi wrote: > Do you have an example build for me to look at? I waited 2 hours for ocaml-result-1.2-12.fc31. In fact it's just now become available in the buildroot. I don't know if that helps. The next build I will be waiting for (when it completes) is ocaml-dune-1.10.0-4.fc31 > Packages are signed before CI runs on them. This is so the _exact_ thing > we are going to be using/shipping/building against is the thing that we > actually test. When you instead test something, then change it, you > leave yourself open to issues with whatever changes you are doing. > > CI runs before they land in the buildroot as we want to not build > against anything that was gated for whatever reason. Makes sense, thanks. 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: Rolling out Phase I of rawhide package gating
On 31/07/2019 16:58, Pierre-Yves Chibon wrote: My canary ran took 24 minutes, apparently the CI pipeline was slower than usual but the rest of the workflow seemed fine. $ koji buildinfo ocaml-result-1.2-12.fc31 returns: Tags: f31 f31-updates-pending So it should be in the buildroot. Is it not? Well wait-repo is not returning: koji wait-repo --build=ocaml-result-1.2-12.fc31 f31-build Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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: Rolling out Phase I of rawhide package gating
On 7/31/19 7:35 AM, Tomasz Torcz wrote: > On Wed, Jul 31, 2019 at 03:15:32PM +0100, Richard W.M. Jones wrote: >> On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: >>> In this case it's koji. >>> >>> For every package in the mass rebuild (f31-pending tag) robosign asks >>> koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". >>> robosign: "great, then I ask you to write out the signed rpms now" >>> koji: "ok, writing them out to disk again" >>> >>> it's mostly this last step thats slow. I am not sure if koji is just >>> seeing if they were written out and returning, or actually re-writing >>> them out. It seems like it might be the latter, which makes me suspect >>> koji could optimize this somewhat. >> >> It's still taking a long time today to get builds through Koji and >> into Rawhide. Is there a reason we need to sign builds in Rawhide? > > Because administrator of Fedora infrastructure run rawhide on laptops, and > we > don't want them to be easily* hackable. > > * or maybe not easily, but easier than users of regular releases Ha. No. It's for a variety of reasons: * Various groups that interact with the packages do not want to have to code in exceptions or treat some things differently. (QA, CI, package tools). * Signing packages is a clear way to indicate where they are from. (look at the 'keychecker' package. If you see a foo-1.0-1.fc29.x86_64.rpm package you can check it's signature and see that it came from rawhide or f29 or no where known, etc. * If you use metalinks, rpm signatures are just gravy on top, in the end you are still just trusing SSL CA's. * Making sure everything is signed in rawhide allows us to test/develop tooling that operates on composes instead of having to test those in stable release branches. There's likely other things too... 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 04:39:09PM +0100, Richard W.M. Jones wrote: > On Wed, Jul 31, 2019 at 04:35:11PM +0100, Tom Hughes wrote: > > On 31/07/2019 16:10, Pierre-Yves Chibon wrote: > > >On Wed, Jul 31, 2019 at 03:15:32PM +0100, Richard W.M. Jones wrote: > > >>On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: > > >>>In this case it's koji. > > >>> > > >>>For every package in the mass rebuild (f31-pending tag) robosign asks > > >>>koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". > > >>>robosign: "great, then I ask you to write out the signed rpms now" > > >>>koji: "ok, writing them out to disk again" > > >>> > > >>>it's mostly this last step thats slow. I am not sure if koji is just > > >>>seeing if they were written out and returning, or actually re-writing > > >>>them out. It seems like it might be the latter, which makes me suspect > > >>>koji could optimize this somewhat. > > >> > > >>It's still taking a long time today to get builds through Koji and > > >>into Rawhide. Is there a reason we need to sign builds in Rawhide? > > > > > >My canary took 14 minutes this morning, so that's within the usual time > > >for it. > > > > > >I'll run it again right to see if it is slower now. > > > > It seems to vary quite a bit. So far today I've seen about 45 minutes > > then 15 and I'm now waiting on another one that's at 50 minutes and > > counting. > > I've been waiting so far nearly 2 hours for this one to get into the > buildroot: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1344542 My canary ran took 24 minutes, apparently the CI pipeline was slower than usual but the rest of the workflow seemed fine. $ koji buildinfo ocaml-result-1.2-12.fc31 returns: Tags: f31 f31-updates-pending So it should be in the buildroot. Is it not? Pierre ___ 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: systemd-243-rc1
On Wed, Jul 31, 2019 at 04:08:13PM +0200, Nicolas Mailhot via devel wrote: > Le 2019-07-31 14:13, Lennart Poettering a écrit : > > Hi Lennart > > >Note that there's a "stable" backport tree maintained outside of the > >main repo: > > > >https://github.com/systemd/systemd-stable > > > >Either way, I doubt this discussion is relevant to Fedora, is it? > > It was when a lot of users could not test new Fedora devel kernels > for about a month, because newer kernels exposed a bug in networkd, > and the current systemd release + packaging process was unable to > produce a Fedora devel systemd, that worked with Fedora devel > kernels I'm sorry the we were slow the deliver the work-around for this issue in Fedora. It's a simple case of having too many packages and too little time. If you or someone else wants to help with systemd maintainance in Fedora, triaging bugs in bugzilla and proposing PRs for systemd-stable are always welcome. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
On 7/31/19 8:07 AM, Richard W.M. Jones wrote: > On Wed, Jul 31, 2019 at 10:22:36AM -0400, Stephen John Smoogen wrote: >> On Wed, 31 Jul 2019 at 10:16, Richard W.M. Jones wrote: >> >>> On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: In this case it's koji. For every package in the mass rebuild (f31-pending tag) robosign asks koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". robosign: "great, then I ask you to write out the signed rpms now" koji: "ok, writing them out to disk again" it's mostly this last step thats slow. I am not sure if koji is just seeing if they were written out and returning, or actually re-writing them out. It seems like it might be the latter, which makes me suspect koji could optimize this somewhat. >>> >>> It's still taking a long time today to get builds through Koji and >>> into Rawhide. Is there a reason we need to sign builds in Rawhide? Can you define 'a long time'? Do you have an example build for me to look at? >> 1. Because everyone's rawhide.repo says they are signed >> 2. Everytime we get unsigned packages people start freaking out that some >> nation state is trying to take over their computer. >> 3. Because nation states do that and those packages will become F32/F33 at >> some point. > > Actually my question was wrong. Is there any reason we need to sign > builds while they are internal to Koji (ie. proving BuildRequires for > subsequent builds)? They could still be signed when they go out to > Rawhide. Packages are signed before CI runs on them. This is so the _exact_ thing we are going to be using/shipping/building against is the thing that we actually test. When you instead test something, then change it, you leave yourself open to issues with whatever changes you are doing. CI runs before they land in the buildroot as we want to not build against anything that was gated for whatever reason. 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 04:35:11PM +0100, Tom Hughes wrote: > On 31/07/2019 16:10, Pierre-Yves Chibon wrote: > >On Wed, Jul 31, 2019 at 03:15:32PM +0100, Richard W.M. Jones wrote: > >>On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: > >>>In this case it's koji. > >>> > >>>For every package in the mass rebuild (f31-pending tag) robosign asks > >>>koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". > >>>robosign: "great, then I ask you to write out the signed rpms now" > >>>koji: "ok, writing them out to disk again" > >>> > >>>it's mostly this last step thats slow. I am not sure if koji is just > >>>seeing if they were written out and returning, or actually re-writing > >>>them out. It seems like it might be the latter, which makes me suspect > >>>koji could optimize this somewhat. > >> > >>It's still taking a long time today to get builds through Koji and > >>into Rawhide. Is there a reason we need to sign builds in Rawhide? > > > >My canary took 14 minutes this morning, so that's within the usual time for > >it. > > > >I'll run it again right to see if it is slower now. > > It seems to vary quite a bit. So far today I've seen about 45 minutes > then 15 and I'm now waiting on another one that's at 50 minutes and > counting. I've been waiting so far nearly 2 hours for this one to get into the buildroot: https://koji.fedoraproject.org/koji/buildinfo?buildID=1344542 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Rolling out Phase I of rawhide package gating
On 31/07/2019 16:10, Pierre-Yves Chibon wrote: On Wed, Jul 31, 2019 at 03:15:32PM +0100, Richard W.M. Jones wrote: On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: In this case it's koji. For every package in the mass rebuild (f31-pending tag) robosign asks koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". robosign: "great, then I ask you to write out the signed rpms now" koji: "ok, writing them out to disk again" it's mostly this last step thats slow. I am not sure if koji is just seeing if they were written out and returning, or actually re-writing them out. It seems like it might be the latter, which makes me suspect koji could optimize this somewhat. It's still taking a long time today to get builds through Koji and into Rawhide. Is there a reason we need to sign builds in Rawhide? My canary took 14 minutes this morning, so that's within the usual time for it. I'll run it again right to see if it is slower now. It seems to vary quite a bit. So far today I've seen about 45 minutes then 15 and I'm now waiting on another one that's at 50 minutes and counting. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module
> "SG" == Stephen Gallagher writes:
SG> Do any tools exist to simplify the conversion to MDB? Can this be
SG> automated?
I'd like to know this as well. It's always better to provide tools or
extremely clear and detailed instructions, because it's not safe to
assume that people know how to do this kind of thing even if they are
running an LDAP server.
I don't particularly have a problem with being forced to enable some
compatibility option after an OS upgrade in advance of functionality
actually being deprecated and not able to be used at all. The latter
gets you into a pretty bad "no way out" situation. ("You should have
read the release notes! Hope you have backups.") It's still better to
get this kind of thing documented as well as possible.
- J<
___
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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 03:15:32PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: > > In this case it's koji. > > > > For every package in the mass rebuild (f31-pending tag) robosign asks > > koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". > > robosign: "great, then I ask you to write out the signed rpms now" > > koji: "ok, writing them out to disk again" > > > > it's mostly this last step thats slow. I am not sure if koji is just > > seeing if they were written out and returning, or actually re-writing > > them out. It seems like it might be the latter, which makes me suspect > > koji could optimize this somewhat. > > It's still taking a long time today to get builds through Koji and > into Rawhide. Is there a reason we need to sign builds in Rawhide? My canary took 14 minutes this morning, so that's within the usual time for it. I'll run it again right to see if it is slower now. Pierre ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 10:22:36AM -0400, Stephen John Smoogen wrote: > On Wed, 31 Jul 2019 at 10:16, Richard W.M. Jones wrote: > > > On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: > > > In this case it's koji. > > > > > > For every package in the mass rebuild (f31-pending tag) robosign asks > > > koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". > > > robosign: "great, then I ask you to write out the signed rpms now" > > > koji: "ok, writing them out to disk again" > > > > > > it's mostly this last step thats slow. I am not sure if koji is just > > > seeing if they were written out and returning, or actually re-writing > > > them out. It seems like it might be the latter, which makes me suspect > > > koji could optimize this somewhat. > > > > It's still taking a long time today to get builds through Koji and > > into Rawhide. Is there a reason we need to sign builds in Rawhide? > > > > > 1. Because everyone's rawhide.repo says they are signed > 2. Everytime we get unsigned packages people start freaking out that some > nation state is trying to take over their computer. > 3. Because nation states do that and those packages will become F32/F33 at > some point. Actually my question was wrong. Is there any reason we need to sign builds while they are internal to Koji (ie. proving BuildRequires for subsequent builds)? They could still be signed when they go out to Rawhide. 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
Re: systemd-243-rc1
On Wed, 31 Jul 2019, 16:10 Nicolas Mailhot via devel, < devel@lists.fedoraproject.org> wrote: > Le 2019-07-31 14:13, Lennart Poettering a écrit : > > Hi Lennart > > > Note that there's a "stable" backport tree maintained outside of the > > main repo: > > > > https://github.com/systemd/systemd-stable > > > > Either way, I doubt this discussion is relevant to Fedora, is it? > > It was when a lot of users could not test new Fedora devel kernels for > about a month, because newer kernels exposed a bug in networkd, and the > current systemd release + packaging process was unable to produce a > Fedora devel systemd, that worked with Fedora devel kernels > > > I thought Linux was supposed to never ever break username programmes? > > Regards, > > -- > Nicolas Mailhot > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Ship BerkleyDB backend as a module
On Tue, Jul 23, 2019 at 8:45 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/OpenLDAPwithBerkleyDBasModule > > == Summary == > Change the ''openldap-servers'' package so that BDB and HDB backends > are required to be dynamically loaded. > > == Owner == > * Name: [[User:mhonek| Matus Honek]] > * Email: mhonek (at) redhat (dot) com > ... > == Upgrade/compatibility impact == > Server using BDB or HDB backends without modified configuration would > fail to start. See ''User Experience'' section for more information. > Is this avoidable or do you consider it desirable? Is there any harm in shipping a default configuration that does the loadmodule for both deprecated backends? My guess here is that you want this to be an explicit breakage to help users learn that the backend is no longer supported. If that's the case, I'd like to see that spelled out in the Change. Do any tools exist to simplify the conversion to MDB? Can this be automated? ___ 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: Rolling out Phase I of rawhide package gating
On Wed, Jul 31, 2019 at 03:15:32PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: > > In this case it's koji. > > > > For every package in the mass rebuild (f31-pending tag) robosign asks > > koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". > > robosign: "great, then I ask you to write out the signed rpms now" > > koji: "ok, writing them out to disk again" > > > > it's mostly this last step thats slow. I am not sure if koji is just > > seeing if they were written out and returning, or actually re-writing > > them out. It seems like it might be the latter, which makes me suspect > > koji could optimize this somewhat. > > It's still taking a long time today to get builds through Koji and > into Rawhide. Is there a reason we need to sign builds in Rawhide? Because administrator of Fedora infrastructure run rawhide on laptops, and we don't want them to be easily* hackable. * or maybe not easily, but easier than users of regular releases -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ 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: Rolling out Phase I of rawhide package gating
On Wed, 31 Jul 2019 at 10:16, Richard W.M. Jones wrote: > On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: > > In this case it's koji. > > > > For every package in the mass rebuild (f31-pending tag) robosign asks > > koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". > > robosign: "great, then I ask you to write out the signed rpms now" > > koji: "ok, writing them out to disk again" > > > > it's mostly this last step thats slow. I am not sure if koji is just > > seeing if they were written out and returning, or actually re-writing > > them out. It seems like it might be the latter, which makes me suspect > > koji could optimize this somewhat. > > It's still taking a long time today to get builds through Koji and > into Rawhide. Is there a reason we need to sign builds in Rawhide? > > 1. Because everyone's rawhide.repo says they are signed 2. Everytime we get unsigned packages people start freaking out that some nation state is trying to take over their computer. 3. Because nation states do that and those packages will become F32/F33 at some point. -- 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: Rolling out Phase I of rawhide package gating
On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote: > In this case it's koji. > > For every package in the mass rebuild (f31-pending tag) robosign asks > koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is". > robosign: "great, then I ask you to write out the signed rpms now" > koji: "ok, writing them out to disk again" > > it's mostly this last step thats slow. I am not sure if koji is just > seeing if they were written out and returning, or actually re-writing > them out. It seems like it might be the latter, which makes me suspect > koji could optimize this somewhat. It's still taking a long time today to get builds through Koji and into Rawhide. Is there a reason we need to sign builds in Rawhide? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
On Wed, 31 Jul 2019 at 09:15, Frantisek Zatloukal wrote: > Personally, I am not at all against raising the bar for baseline x86_64. > Of course, it'd be ideal to have some sort of derived x86_64_avx arch, but > if we find out it'd require too much of an investment into infra/releng, > I'd be +1 for just changing the base x86_64. Sure, it'd make sense to > actually see some numbers from Fedora compiled with SSE4/AVX/AVX2 and not > just guess from Clear Linux results. > > I see AVX2 is just too high baseline (although, all my PCs and laptops > support that for at least 2 years), but raising the baseline to something > like AVX or SSE4 might make sense. I don't know why people with *not > ancient* computers should have degraded performance just because we want to > support everything from K8 from 2003. But as I said, it'd be nice to see > some benchmarks to base the decision on and have optimized x86_64 as > secondary arch, if possible. > > On Wed, Jul 31, 2019 at 11:00 AM Kevin Kofler > wrote: > >> * the performance increase to be had is marginal, given that we are mostly >> talking about code written in C or C++ without even compiler >> vectorization >> (-ftree-vectorize) turned on, >> > > Are you sure? Fore example (and there are more of them), lots of these do > not seem marginal: > https://www.phoronix.com/scan.php?page=news_item=Clear-Linux-2019-Python-Perf > , > https://www.phoronix.com/scan.php?page=article=linux-2016-2018=3 > > > The problem with words like marginal is that what Kevin in his head and what you have in your head probably mean two different things. Also when I see such statistics, I usually wonder "Are they repeatable?" Not just in the case that someone else runs Clear Linux and gets similar timings.. but if I compile my code with those options do I get those numbers or do I need to use Clear Linux to do so because there are other changes not taken into account by just compiling things with an option? This was something we ran into several times in the past with the race to keep up with Mandrake or SuSE during the i486/i586/i686 days.. and again with various super computer rebuilds years later. We can compile the code with the same options but you may not get the same speeds. There can be other changes in the structure of the executable chain from kernel down to file node structure. All of those need to be taken into account to 'duplicate' test results. Without doing that testing and confirming that we know all the options, we are no better off than the person who says they compile everything with -funrolloops -- 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: systemd-243-rc1
Le 2019-07-31 14:13, Lennart Poettering a écrit : Hi Lennart Note that there's a "stable" backport tree maintained outside of the main repo: https://github.com/systemd/systemd-stable Either way, I doubt this discussion is relevant to Fedora, is it? It was when a lot of users could not test new Fedora devel kernels for about a month, because newer kernels exposed a bug in networkd, and the current systemd release + packaging process was unable to produce a Fedora devel systemd, that worked with Fedora devel kernels Regards, -- Nicolas Mailhot ___ 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: Mock - signal reaction
Well, this is a question from Miroslav Suchý on my PR with a solution. https://github.com/rpm-software-management/mock/pull/293 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
Personally, I am not at all against raising the bar for baseline x86_64. Of course, it'd be ideal to have some sort of derived x86_64_avx arch, but if we find out it'd require too much of an investment into infra/releng, I'd be +1 for just changing the base x86_64. Sure, it'd make sense to actually see some numbers from Fedora compiled with SSE4/AVX/AVX2 and not just guess from Clear Linux results. I see AVX2 is just too high baseline (although, all my PCs and laptops support that for at least 2 years), but raising the baseline to something like AVX or SSE4 might make sense. I don't know why people with *not ancient* computers should have degraded performance just because we want to support everything from K8 from 2003. But as I said, it'd be nice to see some benchmarks to base the decision on and have optimized x86_64 as secondary arch, if possible. On Wed, Jul 31, 2019 at 11:00 AM Kevin Kofler wrote: > * the performance increase to be had is marginal, given that we are mostly > talking about code written in C or C++ without even compiler > vectorization > (-ftree-vectorize) turned on, > Are you sure? Fore example (and there are more of them), lots of these do not seem marginal: https://www.phoronix.com/scan.php?page=news_item=Clear-Linux-2019-Python-Perf , https://www.phoronix.com/scan.php?page=article=linux-2016-2018=3 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 31 Self-Contained Change proposal: Simply reclaim disk space in Anaconda
The Anaconda team has decided to withdraw this proposal. We have discussed your concerns and it is true, that the impact on users with Windows could be significant. The problem seems to be the unfortunate design and unfriendliness of the current Manual Partitioning screen. We will keep that in mind and try to address this problem in the future. Thank you all for your feedback! ___ 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: systemd-243-rc1
On Tue, Jul 30, 2019 at 10:00:57PM -0400, Colin Walters wrote: > > > On Tue, Jul 30, 2019, at 4:13 PM, Zbigniew Jędrzejewski-Szmek wrote: > > > Please note that the cgroup hierarchy default remains as "hybrid". > > Upstream has switched the default to "unified", but I reverted this > > switch in Fedora. If there are no major issues reported with this > > pre-release, the next build will have "unified", as described in > > https://fedoraproject.org/wiki/Changes/CGroupsV2. > > That page currently says: "Upgraded machines will continue to work with > CGroupsV1 unless the administrator changes the default." Indeed, this is wrong. Users and administrators who want to retain the old setting will need to add a kernel commandline option. I updated the wiki page to say this. > But I don't see any mechanism in the stack to handle this - > presumably it'd have to be adding a new bootloader options for new > installs, not flip the switch in systemd, right? The plan is to switch the default, and have people who want or need to opt-out set the kernel commandline option. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd-243-rc1
On Mi, 31.07.19 12:57, Tomasz Kłoczko (kloczko.tom...@gmail.com) wrote: > As usually that type of versioning convention is rubbish and it only adds > more work on packaging layer. > Why you guys did not released that as v243.99 ? I like my bikesheds blue. > Other thing is that looks like systemd devel cycle elongated and it cased > that some stabilisation fixes are only committed in master branch with all > other changes. > > Proposal for next systemd devel cycle: > - create devel branch and commit all devel changes in that branch only + > stable fixes > - commit in master branch only stable fixes and release more ofthen v244.1, > v244.2 and so on (one time a month or even more often depends on importance > of the fixes) > - release candidates starting from v244.99 > - when everything in devel will be ready just merge devel branch to master > and tag it as new major release. Are you volunteering to do the work for this? Or do you just expect us upstream to maintain twice the amount of releases? We don't want to be consumed in just doing release mangament. It's hard enough, and we definitely prefer if developers focus on one master, not many, and stop developing new stuff while we are in release mode. This means, doing parallel branches for upstream development is not in the cards, sorry. Either everyone stabilizes or everyone works on new stuff. Note that there's a "stable" backport tree maintained outside of the main repo: https://github.com/systemd/systemd-stable Either way, I doubt this discussion is relevant to Fedora, is it? Lennart -- Lennart Poettering, Berlin ___ 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: systemd-243-rc1
On Tue, 30 Jul 2019 at 21:19, Zbigniew Jędrzejewski-Szmek wrote: > Hello everyone, > > a new pre-release of systemd was tagged today, and it's building in > rawhide now. See https://github.com/systemd/systemd/blob/v243-rc1/NEWS As usually that type of versioning convention is rubbish and it only adds more work on packaging layer. Why you guys did not released that as v243.99 ? Other thing is that looks like systemd devel cycle elongated and it cased that some stabilisation fixes are only committed in master branch with all other changes. Proposal for next systemd devel cycle: - create devel branch and commit all devel changes in that branch only + stable fixes - commit in master branch only stable fixes and release more ofthen v244.1, v244.2 and so on (one time a month or even more often depends on importance of the fixes) - release candidates starting from v244.99 - when everything in devel will be ready just merge devel branch to master and tag it as new major release. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: portable performance engineering
You wrote: > Dave Love wrote: >> they'd be rather limited by the compiler options we're supposed to use, >> that don't include vectorization, so you don't even get the benefit you >> could from SSE2. (I've been told off in review for turning that on, >> though an FPC member has approved it.) > > Why don't we enable -ftree-vectorize by default? I'm happy for it not to be default, as long as sane optimization options are allowed, and people don't think that they'll get all the benefit of recent micro-architectures without them. Note that you're likely to need unrolling to benefit from vectorization in numerical code anyhow. > As I wrote elsewhere in this huge thread: just turn the program into a > library with a dummy main program. That will produce technical problems as well as big maintenance ones, and all this isn't useful without the hwcaps anyhow. Effort is best put into engineering the programs. > You mean the atlas-* subpackages that one has to manually install? That's > actually one big reason to NOT use ATLAS, now that we have OpenBLAS that > does it right. The main reason not to use ATLAS is that it's not performant (or wasn't, last I checked). As far as I know, OpenBLAS still isn't competitive with BLIS for avx512, which is the main reason I packaged BLIS and made shims to subvert slower BLASes. >> and at least one package (libxsmm) has a minimum requirement of SSE3 >> without complaint. (I got that down from SSE4 for the benefit of systems >> we had, though you wouldn't use them for anything CPU-bound.) > > Now you have a complaint. :-) > > The baseline is SSE2, so the packages are supposed to support systems with > nothing beyond SSE2. Just waiting until somebody reports the inevitable > SIGILL is not a nice thing to do. > > Now, if upstream doesn't support non-SSE3 CPUs, it might be nontrivial to > fix the issue. But in principle, a package that requires SSE3 must be > considered a bug. Too bad IMHO. The probability of anyone running cp2k on that sort of system in a mode that invokes libxsmm is too small. Meanwhile, in that space, I can't get ga rebuilt so LAMMPS will actually run on a non-Infiniband fabric, and a bunch of other things that need fixing. Even if people aren't well disposed to engineering, "Everything in the real world is engineering tradeoffs" (Richard O'Keefe). ___ 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: portable performance engineering
Benson Muite writes: > Tradeoffs to satisfy a wide variety of users - a base system with most > common software easy to try which can then be re-installed for > performance. Flatpacks should help with easy but not performance > optimal installation of many packages. Spack (https://spack.io/) may > be a packaging approach that gives some performance portability - one > can get a compilation recipie so that performance is reasonable > good. Easybuild (https://easybuild.readthedocs.io) is another way to > go. Source based systems such as Gentoo may give better performance if > configured correctly. That completely misses the point, apart from one about discouarging packaging and contributing to Fedora maintenance. Please assume that I know plenty about alternative packaging systems like Spack, and non-packaging systems like easybuild, which don't address the issue. If I want to rebuild rpms with different CFLAGS, obviously I can. Flatpak is irrelevant, but part of an unfortunate trend. If you advocate a solution, it better be capable of running in a manageable way across many nodes of a potentially non-x86_64 heterogeneous HPC cluster. ___ 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: Join the new Minimization Team
I also want to join! -- Jun Aruga | He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
Panu Matilainen wrote: > This proposal seems mostly like an experiment in disguise to find out > whether the Fedora developers can agree on *something*, This also looks to me like the tactic to ask for the moon to get a "compromise" that is still unacceptable. > and quite clearly the answer is yes, at least this once we can all agree > to disagree with the proposed change. I disagree with ANY raised vector instruction requirement, considering that: * it would make Fedora incompatible with some hardware out there, * the performance increase to be had is marginal, given that we are mostly talking about code written in C or C++ without even compiler vectorization (-ftree-vectorize) turned on, * there are already mechanisms for runtime feature detection, which are already widely used in those few packages that can actually benefit from the vector instructions (because they are performance-sensitive and because they have handwritten assembly or vector intrinsics code), * upstreams still widely support SSE2, so I don't see a burden for maintainers to keep it going (unlike the case of pre-SSE2 32-bit x86 where a few upstreams had dropped support). 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: Discussion around app retirements and categorizations by the CPE team
On Wed, 31 Jul 2019 at 09:17, 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. > I think to be clear we are talking about the paste service hosted here (https://paste.fedoraproject.org/) and not the fpaste cli tool. The cli tool is not maintained by the CPE team and the cli tool can be changed to use a different service. We are planning to coordinate with the fpaste maintainer to insure that the cli was migrated to another service before we shut down paste.fp.o. Clément > Best, > Pierre > ___ > 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
wine/dxvk: Help with testing
Hi, I've proposed some packaging changes [0] to Fedora wine package. TLDR: It splits d3d libraries into subpackages and lays groundwork for future dxvk packaging [1]. Details are in the PR. *What is DXVK?* Vulkan-based D3D11 and D3D10 implementation for Linux / Wine. In short, you can replace wine's d3d10/11 implementation with DXVK, which typically results in huge performance gains and far superior compatibility compared to wine d3d libraries. You can find more here: https://github.com/doitsujin/dxvk *How to test?* *# Have either Fedora 30 or Fedora 31* dnf copr enable frantisekz/wine-dxvk dnf update wine dnf install wine-dxvk --allowerasing Then fire up as many DirectX 9,10,11 apps as you can :) and post results into this thread, especially if something got broken compared to normal dxvk installation or if some d3d9 apps regressed. DXVK works for d3d10 and d3d11, but note that I am also interested in apps using d3d9, because dxvk package replaces wine's dxgi library that's then used even for stuff that doesn't run through dxvk. Just make sure you don't have DXVK manually installed already in your wine prefix. [0] https://src.fedoraproject.org/rpms/wine/pull-request/3 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1733798 Feel free to ping me on frantisekz@#fedora-qa if you need anything. Thanks a lot! ___ 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: Self Introduction: Ondřej Míchal
Hi Ondřej, welcome to the Fedora project! On Wed, Jul 31, 2019 at 10:30 AM Ondřej Míchal wrote: > > Greetings, > > my name is Ondřej Míchal, I'm a student from Czech Republic who was lucky > enough to get an internship at Red Hat for this year. I've been using Linux-y > systems for almost 4 years already and Fedora for the past two. My main job > as an intern is to work on Toolbox project that is heavily used in Fedora > Silverblue. My other job is to create flatpaks from rpms to help propagate > the use of flatpaks. I've never made any kind of packages before, so please > bear with me if I make any mistakes. > > Best wishes, > > Ondřej Míchal > ___ > 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
Self Introduction: Ondřej Míchal
Greetings, my name is Ondřej Míchal, I'm a student from Czech Republic who was lucky enough to get an internship at Red Hat for this year. I've been using Linux-y systems for almost 4 years already and Fedora for the past two. My main job as an intern is to work on Toolbox project that is heavily used in Fedora Silverblue. My other job is to create flatpaks from rpms to help propagate the use of flatpaks. I've never made any kind of packages before, so please bear with me if I make any mistakes. Best wishes, Ondřej Míchal ___ 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
xmlunit 2 license change
The package xmlunit since version 2 uses two licenses. The legacy module retains BSD from version 1. The rest is licensed under ASL 2.0. I improperly marked it as ASL 2.0 only, this should be fixed in this PR: https://src.fedoraproject.org/rpms/xmlunit/pull-request/2 if we still want to update the ursine package. I fixed this in MBI: https://src.fedoraproject.org/fork/mbi/rpms/xmlunit/c/cdf8080bd32bde75520fff74828ddbae14a0213b?branch=master -- Marián Konček ___ 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 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. Best, Pierre ___ 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: Join the new Minimization Team
Count me in! I'm not sure if I will have much time to do actual work, but surely I can help people with advises :) On Tue, Jul 30, 2019 at 4:58 PM Adam Samalik wrote: > > Hi everyone! > > I'm starting a Minimization Objective [1] focusing on minimising the > installation size of some of the popular apps, runtimes, and other pieces of > software in Fedora. > > And there is a new Minimization Team [2] forming. Members of the team will > consult and work with Fedora maintainers, develop tooling and services, > generate reports showing the status of the Fedora ecosystem and a comparison > with other ecosystems, etc. The goal is to build an environment where it's > easy for our maintainers to keep things small over time, it's not just a > one-off effort. Please see the Action Plan [3] for more details. > > Want to become a member? Let me know! > > Cheers! > Adam > > [1] https://docs.fedoraproject.org/en-US/minimization/ > [2] https://docs.fedoraproject.org/en-US/minimization/team/ > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/ > > > -- > > Adam Šamalík > --- > Senior Software Engineer > Red Hat > ___ > 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
