Re: mesa 21.0.0-rc3 making rawhide really unstable?
On Thu, Feb 4, 2021 at 12:02 AM Fabio Valentini wrote: > > On Wed, Feb 3, 2021 at 12:42 PM Milan Crha wrote: > > > > On Wed, 2021-02-03 at 15:26 +1000, David Airlie wrote: > > > Please test: > > > > > > mesa-21.0.0~rc3-2.fc34 > > > > > > which I just built for rawhide. > > > > Hi, > > for what it's worth, it helped me with gdm, it opens now, but I cannot > > log in to "GNOME on Xorg", I'm immediately returned back to the gdm. > > Logging to "GNOME" (aka Wayland) works. > > Can confirm, gdm and gnome/wayland works again, but all Xorg based > sessions are now even more broken, e.g. you're returned to gdm a > second after you enter your password. Has anyone got a backtrace they could put in a bug? I'm not seeing a crash with X.org here in my test VMs. Dave. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 1655461] w3c-markup-validator-21.2.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1655461 --- Comment #19 from Upstream Release Monitoring --- Skipping the scratch build because an SRPM could not be built: ['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-7wsr73fo/w3c-markup-validator.spec'] returned 1: b'error: Bad source: ./w3c-markup-validator-21.2.5.tar.xz: No such file or directory\n' -- 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 1655461] w3c-markup-validator-21.2.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1655461 Upstream Release Monitoring changed: What|Removed |Added Summary|w3c-markup-validator-20.6.3 |w3c-markup-validator-21.2.5 |0 is available |is available --- Comment #18 from Upstream Release Monitoring --- Latest upstream release: 21.2.5 Current version/release in rawhide: 1.3-21.fc34 URL: https://validator.github.io/validator/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5111/ -- 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: Reproducible builds
On Thu, Feb 4, 2021 at 9:23 PM Kevin Fenzi wrote: > > On Fri, Feb 05, 2021 at 12:17:28AM +0100, Marek Marczykowski-Górecki wrote: > > > > Does it make sense? > > That does make sense to me... and perhaps this fits in with that we > generate debuginfo/debugsource rpms when we build something. We just expand > things > to also produce a buildinfo subpackage (of course then we need tools to > gather them/put them in a repo/allow users to install them, etc). > > Then, you could 'dnf install foobar-buildinfo-1.0-1.fc35' and possibly > there could be tools that would read that .buildinfo and feed the > src.rpm into mock or whatever with that input? > That is, of course, another valid strategy, and may make sense given the archful nature of some things. -- 真実はいつも一つ！/ 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: Reproducible builds
On Fri, Feb 05, 2021 at 12:17:28AM +0100, Marek Marczykowski-Górecki wrote: > > Does it make sense? That does make sense to me... and perhaps this fits in with that we generate debuginfo/debugsource rpms when we build something. We just expand things to also produce a buildinfo subpackage (of course then we need tools to gather them/put them in a repo/allow users to install them, etc). Then, you could 'dnf install foobar-buildinfo-1.0-1.fc35' and possibly there could be tools that would read that .buildinfo and feed the src.rpm into mock or whatever with that input? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1919730] Please build perl-Net-XMPP for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1919730 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-EPEL-2021-1368e70972 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1368e70972 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1924943 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2021-2cd1ef7d50 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2cd1ef7d50 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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 1920399] perl-Log-Report-1.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1920399 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Log-Report-1.32-1.fc34 |perl-Log-Report-1.32-1.fc34 |perl-Log-Report-1.32-1.fc32 |perl-Log-Report-1.32-1.fc32 ||perl-Log-Report-1.32-1.fc33 --- Comment #8 from Fedora Update System --- FEDORA-2021-d183e95f5f has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report. -- 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 1920399] perl-Log-Report-1.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1920399 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Log-Report-1.32-1.fc34 |perl-Log-Report-1.32-1.fc34 ||perl-Log-Report-1.32-1.fc32 Resolution|--- |ERRATA Last Closed||2021-02-05 01:32:06 --- Comment #7 from Fedora Update System --- FEDORA-2021-2cbaca83c9 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- 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: Reproducible builds
On Wed, Feb 3, 2021 at 8:42 PM Neal Gompa wrote: > The Koji build system already records buildinfo data in a slightly > different form, where build IDs are linked to all the inputs that > constructed the build environment as recorded by Koji itself. This > implicitly includes a definition of all the RPM macros that are inputs > for a build, too. There is a presentation about Koji and the reproducible-builds.org effort at https://www.youtube.com/watch?v=wxzGdX5iMgw ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Pytest 4 in Fedora, let's get rid of it please
On 02. 02. 21 18:09, Miro Hrončok wrote: 3) Retire python-pytest4 and python-pytest-relaxed This requires disabling tests in invoke and slightly patching tests of paramiko. Once pytest-relaxed supports recent pytest, we can reintroduce it. BTW the patch for paramiko exists: https://github.com/paramiko/paramiko/pull/1665 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Reproducible builds
On Wed, Feb 03, 2021 at 10:41:30PM -0500, Neal Gompa wrote: > On Wed, Feb 3, 2021 at 4:51 PM Frédéric Pierret > wrote: > > > > Hi, > > > > As discussed few weeks ago, I'm working on reproducible builds for Fedora. > > I've submitted a request for review for new packages: > > https://bugzilla.redhat.com/show_bug.cgi?id=1924918. Notably, reprotest is > > a striking tool to test reproduciblity by changing multiples build factors > > (time, user, lang, etc.) and highlight differences (if exists) with > > diffoscope (see https://salsa.debian.org/reproducible-builds/reprotest). > > > > On the same topic, I'm developing rpmreproduce (see > > https://github.com/fepitre/rpmreproduce) which is very much work in > > progress. This tool allows to rebuild a RPM with the same environment, > > packages versions etc. This is in the continuity of a previous attempt > > https://github.com/kholia/ReproducibleBuilds. Currently, it uses a > > "buildinfo" file as input (see > > https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles) but there is not > > such file in Fedora (yet?). In Qubes OS, we use an original implementation > > for RPM done at the occasion of Reproducible Builds summit: > > https://github.com/QubesOS/qubes-builder-rpm/blob/master/scripts/rpmbuildinfo > > or > > https://raw.githubusercontent.com/fepitre/rpmreproduce/master/scripts/rpmbuildinfo > > (latest dev/test version). This tool is in charge to download exact > > version dependencies as specified in the buildinfo, create a local > > repository, download the corresponding source RPM and then, rebuild it with > > mock and only this locally created repository that reflects the original > > build environment. > > > > I take this opportunity to invite RPM devs to discuss about a possible > > upstream implementation of buildinfo file format. For example, we could > > think about having a buildinfo file automatically generated by rpmbuild as > > dpkg is doing similarly in Debian. I would be happy to do the work for that. > > > > The Koji build system already records buildinfo data in a slightly > different form, where build IDs are linked to all the inputs that > constructed the build environment as recorded by Koji itself. This > implicitly includes a definition of all the RPM macros that are inputs > for a build, too. > > I would generally expect that information like this at the rpmbuild > level should probably be stored in the Source RPM. Since a Source RPM > is an atomic unit containing a build description and the inputs needed > to make the build work, it would make sense that more comprehensive > build environment data would go there. Source RPMs already contain > some rudimentary stuff, like the compiler build flags set in the build > environment during the package build time. It would make sense to > expand this to cover all inputs traditionally covered by the buildinfo > file in Debian. Isn't it going to be an issue that the initial SRPM can't possibly have this info? Buildinfo generally is a product of a build, similar to build log, just more structured, which can be used as a build input in some cases too (reproducing particular binary rpm). Copying from Debian wiki: The .buildinfo file has several goals which are related to each other: * It records information about the system environment used during a particular build -- packages installed (toolchain, etc), system architecture, etc. This can be useful for forensics/debugging. * It can also be used to try to recreate (partially or in full) the system environment when trying to reproduce a particular build. It makes a perfect sense to take a single SRPM and build in two different environments (for example for f33 and f34) - resulting in two different sets of binary RPMs and two buildinfo files (wherever they will be). So, if including in an RPM, I'd say it is more logical to include in a binary RPM - a build output. In fact, Archlinux does exactly that (in their package format). If it would be in an SRPM, then you'd need to rebuild/modify SRPM _after_ building binary RPMs, which feels wrong... Does it make sense? -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: newRepo taking a while this morning ...
On Thu, Feb 04, 2021 at 05:32:47PM +, Richard W.M. Jones wrote: > On Wed, Feb 03, 2021 at 11:56:50AM -0800, Kevin Fenzi wrote: > > Would 30 days be workable? > > The only time I use side tags is for the OCaml build. > > 30 days would be fine for the builds. But one issue we had last time > was that Bodhi (IIRC) took forever to move the built packages to > Fedora - much longer than 30 days. I don't recall exactly what the > problem was though. Wow...thats surprising to me. 30 days? I could see a few days if there was some problem, but 30days seems way long. We can usually fix up things to work faster than that. :) kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: pytest 6.2.x update incoming
On 27. 01. 21 0:37, Miro Hrončok wrote: On 26. 01. 21 20:15, Miro Hrončok wrote: Hello Pythonistas. I'd like to update pytest to 6.2 in rawhide after the mass rebuild. The impact on not-already-broken packages is surprisingly small. pybind11: fixed upstream in git Fixed. python-alembic: uses removed feature, old version is packaged python-docopt: uses removed feature, stalled upstream issue exists python-fiat: broken by python-pytest-cases python-hypothesis: pytest regression fixed in git, hypothesis adapted upstream Fixed. python-jaraco-classes: missing BR Fixed. python-pytest-cases: uses removed feature, old version is packaged python-pytest-ordering: investigating, possible pytest regression Fixed in https://src.fedoraproject.org/rpms/python-pytest-ordering/pull-request/1 python-pytest-toolbox: missing BR python-setuptools_scm: fixed upstream Fixed. python-watchgod: missing BR python-werkzeug: fails on new warnings (treated as errors) See the details in https://src.fedoraproject.org/rpms/pytest/pull-request/19 Let me know if I shall wait or if you want my help with fixing some of the affected packages. If nobody speaks up, I plan to fix hypothesis, setuptools_scm and upgrade pytest in a ~1 week. I forgot about python-cherrypy, which is affected by the same thing as python-werkzeug. Details in https://src.fedoraproject.org/rpms/pytest/pull-request/19#comment-65512 The pytest update has been shipped and the listed packages now fail to build: https://koschei.fedoraproject.org/affected-by/python3-pytest?epoch1=0=6.0.2=2.fc34=0=6.2.2=1.fc34=f34 (numpy seem unrelated) If you need my help with fixes, don't hesitate to ask for it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
[Bug 1925321] New: perl-File-Path-Tiny-1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1925321 Bug ID: 1925321 Summary: perl-File-Path-Tiny-1.0 is available Product: Fedora Version: rawhide Status: NEW Component: perl-File-Path-Tiny Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: holca...@gmail.com, iarn...@gmail.com, jakub.jedel...@gmail.com, jples...@redhat.com, perl-devel@lists.fedoraproject.org, tjczep...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 1.0 Current version/release in rawhide: 0.9-12.fc34 URL: http://search.cpan.org/dist/File-Path-Tiny Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7099/ -- 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: Ars claims: Fedora 32 is sluggish
On Wed, Feb 3, 2021 at 8:48 PM Matthew Miller wrote: > > On Wed, Feb 03, 2021 at 10:53:32AM -0600, Michael Catanzaro wrote: > > Has anybody investigated Jim Salter's claims that Fedora 32 is slow > > to launch applications? Recent article: > > > > https://arstechnica.com/gadgets/2021/02/ubuntu-core-20-adds-secure-boot-with-hardware-backed-encryption/ > > > > "in my experience, Fedora 32 is noticeably, demonstrably more > > sluggish to launch applications than Ubuntu is in general." > > I genuinely wonder if this is due to the launch animation. I know that > subjectively for myself using the Impatience to triple the speed makes my > desktop feel more snappy. I do not particularly enjoy self-flagellation, but I think that besides some conscious system-wide choices that could measurably affect performance for everyone (e.g. compiler flags), we suffer from a lack of interest towards bugs that happen behind the scenes and impact a subset of our users. Even in cases when upstream is aware of an issue and a fix is promptly made available, in some cases it never finds its way to a supported Fedora version or that happens with a considerable lag. In the last 4 or so years I remember issues with tracker, gnome-shell, mutter/clutter and friends on specific GPUs, default or popular shell extensions and dbus services. A recent bug which is also related to the topic of Jim Salter's article is #1916652. SELinux and Flatpak are supposed to be first-class citizens in Fedora, yet we get bugs like that. There has been a flatpak update in the interim, but it didn't address the problem. And while on a 16-core system this barely registers (unless someone has SELinux Troubleshooter installed), I reproduced it on a dual-core Celeron and it took almost five minutes to get the system to a usable state. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help wanted: Multiple packages with different ver-rel from one spec
On 04/02/2021 19:48, Miro Hrončok wrote: So the ver-rels are: main: 1.2.3-1.fc34 foo: 7.8.9-1.2.3^1.fc34 Once the base_release is bumped: main: 1.2.3-2.fc34 foo: 7.8.9-1.2.3^2.fc34 And once the main version is bumped without foo, base_release back to 1: main: 1.2.4-1.fc34 foo: 7.8.9-1.2.4^1.fc34 Yes this is how nodejs/npm work - the npm package is built from the nodejs source but has it's own version to the package version is done as: -.. So currently in F33 you have: nodejs-14.15.4-1.fc33.x86_64 npm-6.14.10-1.14.15.4.1.fc33.x86_64 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: Ars claims: Fedora 32 is sluggish
On Thu, 2021-02-04 at 13:25 -0500, Matthew Miller wrote: > On Thu, Feb 04, 2021 at 10:33:37AM -0700, Nathanael D. Noblet wrote: > > > I genuinely wonder if this is due to the launch animation. I know > > > that > > > subjectively for myself using the Impatience to triple the speed > > > makes > > > my desktop feel more snappy. > > > > Sorry, what is 'the Impatience'? How does it improve the desktop > > performance? > > It is this extension: > https://github.com/timbertson/gnome-shell-impatience > > It does not _actually_ improve performance. It gives you a slider > which can > be used to double or triple (or whatever) the speed of the > animations, which > has — to my easily-tricked brain — the effect of making the desktop > _seem_ > more responsive. Try it and see if it works for you too! Oh my goodness that's hilarious and all kinds of awesome. The name of the extension is great. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ars claims: Fedora 32 is sluggish
On Thu, 4 Feb 2021 at 21:12, clime wrote: > On Thu, 4 Feb 2021 at 19:36, Matthew Miller > wrote: > >> On Thu, Feb 04, 2021 at 10:33:37AM -0700, Nathanael D. Noblet wrote: >> > > I genuinely wonder if this is due to the launch animation. I know that >> > > subjectively for myself using the Impatience to triple the speed makes >> > > my desktop feel more snappy. >> > >> > Sorry, what is 'the Impatience'? How does it improve the desktop >> > performance? >> >> It is this extension: >> https://github.com/timbertson/gnome-shell-impatience >> >> It does not _actually_ improve performance. It gives you a slider which >> can >> be used to double or triple (or whatever) the speed of the animations, >> which >> has — to my easily-tricked brain — the effect of making the desktop _seem_ >> more responsive. Try it and see if it works for you too! >> > > Thanks, it helps even for going to overlay and back and for switching > workspaces. > I now have more time to procrastinate, which is great! > > >> >> -- >> Matthew Miller >> >> Fedora Project Leader >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/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: Ars claims: Fedora 32 is sluggish
On Thu, 4 Feb 2021 at 19:36, Matthew Miller wrote: > On Thu, Feb 04, 2021 at 10:33:37AM -0700, Nathanael D. Noblet wrote: > > > I genuinely wonder if this is due to the launch animation. I know that > > > subjectively for myself using the Impatience to triple the speed makes > > > my desktop feel more snappy. > > > > Sorry, what is 'the Impatience'? How does it improve the desktop > > performance? > > It is this extension: https://github.com/timbertson/gnome-shell-impatience > > It does not _actually_ improve performance. It gives you a slider which can > be used to double or triple (or whatever) the speed of the animations, > which > has — to my easily-tricked brain — the effect of making the desktop _seem_ > more responsive. Try it and see if it works for you too! > Thanks, it helps even for going to overlay and back and for switching workspaces. > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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: Help wanted: Multiple packages with different ver-rel from one spec
On 04. 02. 21 20:19, Fabio Valentini wrote:
Some handle situations like these by setting Version for each
subpackaged component separately and only ever incrementing Release
and never resetting it to 0.
In the past, I've done:
Version: 1.2.3
# rpmdev-bumpspec will bump this:
%global base_release 1
Release: %{base_release}%{?dist}
%global foo_version 7.8.9
# To ensure ascending EVR for foo, we include main's version into release
%global foo_release %{version}^%{base_release}%{?dist}
# by using custom version of a subpackage %%version gets redefined, we preserve
the value fir further use in the spec
%global main_version %{version}
...
%package -n foo
Version: %{foo_version}
Release: %{foo_release}
---
So the ver-rels are:
main: 1.2.3-1.fc34
foo: 7.8.9-1.2.3^1.fc34
Once the base_release is bumped:
main: 1.2.3-2.fc34
foo: 7.8.9-1.2.3^2.fc34
And once the main version is bumped without foo, base_release back to 1:
main: 1.2.4-1.fc34
foo: 7.8.9-1.2.4^1.fc34
--
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: Help wanted: Multiple packages with different ver-rel from one spec
On Thu, Feb 4, 2021 at 7:24 PM Artur Frenszek-Iwicki
wrote:
>
> The Lazarus package currently builds three RPMs: "lazarus", which contains
> the IDE, and the "qt5pas" library, along with "qt5pas-devel".
> qt5pas is, technically, a separate project with its own versioning - but
> since its distributed alongside Lazarus, and Lazarus depends on it, it made
> sense to build them from one SRPM.
>
> In the spec, I specify a different Version: for qt5pas. This isn't a problem
> per-se, but means that if I upgrade Lazarus (so Version goes up and Release
> goes back to 1), I get a lower NVR for qt5pas. So I made a macro which gets
> calculated based on Lazarus's NVR, so it won't go down, and used it as the
> Release:. So now I have:
> - in qt5pas: "Release = %{qt5pas-release}"
> - in lazarus: "Requires: qt5pas = %{qt5pas-version}-%{qt5pas-release}"
>
> Now, the problem is: whenever a Mass Rebuild occurs, the releng scripts see
> the "Release = %{qt5pas-release}" bit and just slap ".1" at the end, which in
> turn causes the "Requires: qt5pas = %{qt5pas-version}-%{qt5pas-release}" bit
> to be unsatisfiable.
>
> While I could, obviously, just make a commit stripping the ".1" and rebuild
> the package, this approach is wasteful in regards to both my time and koji
> processing power, and unfriendly towards automation (as it means a mass
> rebuild will always produce broken packages). So I'm now wondering what would
> be the best approach.
> - Move qt5pas to a separate dist-git repo: Would solve the problem above, but
> make syncing the packages harder.
> - Drop the separate version for qt5pas and just use Lazarus's version (would
> need an Epoch bump, probably). This would make the package's version not
> match what is shipped.
>
> Any other approach I could adopt?
The approach in lazarus sounds error-prone, and it looks like
rpmdev-bumpspec does not recognise what you're using and just slaps a
".1" at the end, which is wrong in your case.
I am aware of at least three (?) other "noteworthy" packages that have
to deal with this (or at least, had to do something like this in the
past):
- ruby (with the gems that are bundled with the interpreter),
- perl (with the modules that are bundled with the interpreter), and
- rust (with tools like cargo that are bundled with the compiler)
Some handle situations like these by setting Version for each
subpackaged component separately and only ever incrementing Release
and never resetting it to 0. Rust handles this by just not setting the
Version of cargo to its "real" version, but have it inherit the
version from the Rust compiler instead.
The "cleanest" way to deal with this would probably be to package them
in separate "source" packages (even if built from the same upstream
tarball), but if that would not work, look at how other packages
handle this. :)
Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Help wanted: Multiple packages with different ver-rel from one spec
On Thu, Feb 04, 2021 at 06:58:15PM -, Artur Frenszek-Iwicki wrote: > The library provides Qt5 bindings for applications developed using > Lazarus, so being broken into a subpackage allows for dependent packages > to pull in only the library, instead of the whole IDE. Ah, I see. It might really be best to package them separately still, and perhaps convince upstream to distribute the upstream sources side by side rather than bundled together. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help wanted: Multiple packages with different ver-rel from one spec
The library provides Qt5 bindings for applications developed using Lazarus, so being broken into a subpackage allows for dependent packages to pull in only the library, instead of the whole IDE. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help wanted: Multiple packages with different ver-rel from one spec
I am not the maintainer of the package, but I am aware that there are two sources with two versions here: https://src.fedoraproject.org/rpms/python-pyasn1/blob/f33/f/python-pyasn1.spec The sub-package ends up with a provides with the modules version: # rpm -q --provides python3-pyasn1-modules python-modules = 0.4.8-3.fc33 python-pyasn1-modules = 0.4.8-3.fc33 python3-pyasn1-modules = 0.4.8-3.fc33 python3.9-modules = 0.4.8-3.fc33 python3.9-pyasn1-modules = 0.4.8-3.fc33 python3.9dist(pyasn1-modules) = 0.2.8 python3dist(pyasn1-modules) = 0.2.8 Perhaps something along these lines could be helpful. On 2/4/21 1:44 PM, Matthew Miller wrote: On Thu, Feb 04, 2021 at 06:37:12PM -, Artur Frenszek-Iwicki wrote: Same tarball, separate versions. Dependency is one-way. Well, that's annoying. I guess the next thought is: is there any point in having the bundled library actually broken out into a subpackage, or should it just be hidden as a bundled implementation detail? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help wanted: Multiple packages with different ver-rel from one spec
On Thu, Feb 04, 2021 at 06:37:12PM -, Artur Frenszek-Iwicki wrote: > Same tarball, separate versions. Dependency is one-way. Well, that's annoying. I guess the next thought is: is there any point in having the bundled library actually broken out into a subpackage, or should it just be hidden as a bundled implementation detail? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help wanted: Multiple packages with different ver-rel from one spec
Same tarball, separate versions. Dependency is one-way. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Help wanted: Multiple packages with different ver-rel from one spec
On Thu, Feb 04, 2021 at 06:24:37PM -, Artur Frenszek-Iwicki wrote: > The Lazarus package currently builds three RPMs: "lazarus", which contains > the IDE, and the "qt5pas" library, along with "qt5pas-devel". qt5pas is, > technically, a separate project with its own versioning - but since its > distributed alongside Lazarus, and Lazarus depends on it, it made sense to > build them from one SRPM. Is it distributed literally in the same source tarball but versioned separately, or distributed as a different source side by side? Is the dependency relationship one-way or is it a loop? If they're really different sources and not a loop, I think you're just making more work for yourself and it'd really be best to have separate packages. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Ars claims: Fedora 32 is sluggish
On Thu, Feb 04, 2021 at 10:33:37AM -0700, Nathanael D. Noblet wrote: > > I genuinely wonder if this is due to the launch animation. I know that > > subjectively for myself using the Impatience to triple the speed makes > > my desktop feel more snappy. > > Sorry, what is 'the Impatience'? How does it improve the desktop > performance? It is this extension: https://github.com/timbertson/gnome-shell-impatience It does not _actually_ improve performance. It gives you a slider which can be used to double or triple (or whatever) the speed of the animations, which has — to my easily-tricked brain — the effect of making the desktop _seem_ more responsive. Try it and see if it works for you too! -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Help wanted: Multiple packages with different ver-rel from one spec
The Lazarus package currently builds three RPMs: "lazarus", which contains the
IDE, and the "qt5pas" library, along with "qt5pas-devel".
qt5pas is, technically, a separate project with its own versioning - but since
its distributed alongside Lazarus, and Lazarus depends on it, it made sense to
build them from one SRPM.
In the spec, I specify a different Version: for qt5pas. This isn't a problem
per-se, but means that if I upgrade Lazarus (so Version goes up and Release
goes back to 1), I get a lower NVR for qt5pas. So I made a macro which gets
calculated based on Lazarus's NVR, so it won't go down, and used it as the
Release:. So now I have:
- in qt5pas: "Release = %{qt5pas-release}"
- in lazarus: "Requires: qt5pas = %{qt5pas-version}-%{qt5pas-release}"
Now, the problem is: whenever a Mass Rebuild occurs, the releng scripts see the
"Release = %{qt5pas-release}" bit and just slap ".1" at the end, which in turn
causes the "Requires: qt5pas = %{qt5pas-version}-%{qt5pas-release}" bit to be
unsatisfiable.
While I could, obviously, just make a commit stripping the ".1" and rebuild the
package, this approach is wasteful in regards to both my time and koji
processing power, and unfriendly towards automation (as it means a mass rebuild
will always produce broken packages). So I'm now wondering what would be the
best approach.
- Move qt5pas to a separate dist-git repo: Would solve the problem above, but
make syncing the packages harder.
- Drop the separate version for qt5pas and just use Lazarus's version (would
need an Epoch bump, probably). This would make the package's version not match
what is shipped.
Any other approach I could adopt?
Thanks in advance,
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Ars claims: Fedora 32 is sluggish
On Wed, 2021-02-03 at 14:48 -0500, Matthew Miller wrote: > I genuinely wonder if this is due to the launch animation. I know > that > subjectively for myself using the Impatience to triple the speed > makes my > desktop feel more snappy. Sorry, what is 'the Impatience'? How does it improve the desktop performance? -- Nathanael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: newRepo taking a while this morning ...
On Wed, Feb 03, 2021 at 11:56:50AM -0800, Kevin Fenzi wrote: > Would 30 days be workable? The only time I use side tags is for the OCaml build. 30 days would be fine for the builds. But one issue we had last time was that Bodhi (IIRC) took forever to move the built packages to Fedora - much longer than 30 days. I don't recall exactly what the problem was though. 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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2021-02-05 from 17:00:00 to 18:00:00 US/Eastern At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ 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: Status update for the new AAA system
On Thu, 4 Feb 2021 at 11:37, Vít Ondruch wrote: > > Dne 04. 02. 21 v 15:52 Aurelien Bompard napsal(a): > > Hey folks! > > > > As you've probably heard before, we're upgrading our authentication > system to something that is based on FreeIPA. > > Here's a quick status report on that initiative. > > > Thx for the update! > > > > We're currently in an integration phase, figuring out the smaller > details of configuration and infrastructure setup before we switch > production. > > - The infra team wants to do a couple things that FreeIPA does not > support out of the box, like enforcing 2FA for specific services such as > sudo, so we need to think about how we want to do it. > > - Also, using kinit with 2FA tokens proved to be more complex than we'd > like it to be. > > - We're trying out a more continuous approach to importing accounts, > because a full run takes 3 days and during the migration we'll want to run > the import script without having a 3 days downtime. > > - We also have to do some FreeIPA performance tuning, because we have > something like 120k accounts and the default configuration is not > appropriate for that amount of data, especially when we want to list all > groups or worse, all users. > > > Isn't there a plan to reduce the number of imported accounts? As far as > I remember, there is not more then 1000 active Fedora contributors ... > > The issue is that every method that we have come up runs into the same issue we have had with the last forced password change. It was a nightmare from the administrator side with a lot of personal attacks, complaints to management, and verbal abuse about 'made-work' for the people outside that 1000 very active Fedora contributors who found that their account was locked. There are people who log in once a year, there are people who log into the wiki and discourse that fas doesn't see because the openid system masks that, etc etc. The list of corner cases and the amount of work that N thousand people would have to replicate was large and so it was seen as better to just import them all versus come up with a filter, get told that our filter was wrong, repeat until another 12 months go by -- 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: Status update for the new AAA system
Dne 04. 02. 21 v 15:52 Aurelien Bompard napsal(a): Hey folks! As you've probably heard before, we're upgrading our authentication system to something that is based on FreeIPA. Here's a quick status report on that initiative. Thx for the update! We're currently in an integration phase, figuring out the smaller details of configuration and infrastructure setup before we switch production. - The infra team wants to do a couple things that FreeIPA does not support out of the box, like enforcing 2FA for specific services such as sudo, so we need to think about how we want to do it. - Also, using kinit with 2FA tokens proved to be more complex than we'd like it to be. - We're trying out a more continuous approach to importing accounts, because a full run takes 3 days and during the migration we'll want to run the import script without having a 3 days downtime. - We also have to do some FreeIPA performance tuning, because we have something like 120k accounts and the default configuration is not appropriate for that amount of data, especially when we want to list all groups or worse, all users. Isn't there a plan to reduce the number of imported accounts? As far as I remember, there is not more then 1000 active Fedora contributors ... Vít To sum it up, we're currently working on integration and migration preparation. We need to fix these issues before we go to prod, but it's a bit difficult to say how long it's going to take (especially with perf tuning, fix one perf issue and there can be another one right behind). One sure thing is that it's better to have these issues now rather than after the switch to prod. Cheers! Aurélien ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org OpenPGP_signature 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
Review request: f34-backgrounds
Hello team, f34-backgrounds package needs a review before the branching to Fedora 34 https://bugzilla.redhat.com/show_bug.cgi?id=1924959 Thanks in advance. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Modify %cmake_install behavior?
On Thu, Feb 4, 2021 at 9:58 AM Neal Gompa wrote: > On Thu, Feb 4, 2021 at 9:48 AM Richard Shaw wrote: > > > > Currently if in source builds are set to true, %cmake_install appends a > "." current directory. > > > > I'm working on building Avidemux on RPM Fusion and it requires multiple > cmake builds and fakeroot installs which means I have to allow "in source > builds" to stop the new behavior even though I'm manually performing > multiple out-of-source builds. > > > > During %install I would much prefer to do something likes: > > %cmake_install > > %cmake_install > > %cmake_install ... > > > > But that's currently not possible because it assumes "." is appropriate. > I'd really rather not have to pushd into each directory as that's just ugly > :) > > > > Is there a way to modify the behavior of the macro to not append "."? > > > > You could possibly change %_vpath_builddir for each of them. You can > do that for each %cmake, %cmake_build, and %cmake_install invocation > without turning off out of source builds. > For now I reverted back to %make_install using -C with the caveat that if %cmake_... changes to Ninja it will break. I don't suppose the macro could be made to have optional arguments? Pseudo-code: if $arg; use as ; otherwise use "." Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Modify %cmake_install behavior?
On Thu, Feb 4, 2021 at 9:48 AM Richard Shaw wrote: > > Currently if in source builds are set to true, %cmake_install appends a "." > current directory. > > I'm working on building Avidemux on RPM Fusion and it requires multiple cmake > builds and fakeroot installs which means I have to allow "in source builds" > to stop the new behavior even though I'm manually performing multiple > out-of-source builds. > > During %install I would much prefer to do something likes: > %cmake_install > %cmake_install > %cmake_install ... > > But that's currently not possible because it assumes "." is appropriate. I'd > really rather not have to pushd into each directory as that's just ugly :) > > Is there a way to modify the behavior of the macro to not append "."? > You could possibly change %_vpath_builddir for each of them. You can do that for each %cmake, %cmake_build, and %cmake_install invocation without turning off out of source builds. -- 真実はいつも一つ！/ 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
[EPEL-devel] Re: EPEL whats version of RHEL will follow
Hi Ok that makes sense. Thank you Le Wed Feb 03 2021 17:48:32 GMT+0100 (CET), Troy Dawson a écrit : On Wed, Feb 3, 2021 at 3:16 AM john tatt wrote: > > Hi > So if I understand well, an EPEL package could have to be desinstalled just > because an update in Stream make it not compatible any more ? > Strange > Yes and no Yes - If you are running CentOS Stream, and don't have the epel-next repo enabled. No - If you are running RHEL, Rocky, Alma, or even CentOS Stream with epel-next enabled. > > Le Mon Feb 01 2021 17:49:41 GMT+0100 (CET), Stephen John Smoogen > a écrit : > > > > > On Mon, 1 Feb 2021 at 11:00, Filip Bartmann wrote: > > Hello, > what version of RedHat will EPEL now follow? Centos Stream or oficial RedHat > and Rocky based on stable RHEL? > > > > The main EPEL packages have always been compiled against the official Red Hat > Enterprise Linux current package set. There is an initiative to have a set of > packages built against CentOS Stream to deal with .next issues we see when > RHEL updates from say 8.3 to 8.4. > > > > > Thanks, > Filip Bartmann > ___ > 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 > > > > -- > Stephen J Smoogen. > > > ___ > 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 > ___ > 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 ___ 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 ___ 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
pyproject-rpm-macros-0-37: One less %generate_buildrequires round
Hello Pythonistas, We have just released pyproject-rpm-macros-0-37. It is available in Koji for all Fedora versions. The primary new thing is optimized %pyproject_buildrequires: The new version will save one round of installing BuildRequires. Previously, the macro generated BuildRequires in waves like this: Projects with pyproject.toml: 1. (python +) pip + packaging 2. [pyproject.toml detected by Python script] toml 3. parsed dependencies from pyproject.toml 4. ... Projects without pyproject.toml: 1. (python +) pip + packaging 2. [missing pyproject.toml detected by Python script] setuptools + wheel 3. ... Now, we check if pyproject.toml is present as soon as possible directly from Shell, so the rounds were reduced to: 1. (python +) pip + packaging + [ -f pyproject.toml ] toml 2. parsed dependencies from pyproject.toml 3. ... Or: 1. (python +) pip + packaging + [ ! -f pyproject.toml ] setuptools + wheel 2. ... This saves one round of `dnf builddep` in either case. One round that could take minutes with --enablerepo=local. The change should be 100% backwards compatible unless you enjoyed the extra round to read your emails https://xkcd.com/1172/ Enjoy and report problems as usual. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Jami (formerly Ring) P2P softphone packaging?
On 03.02.2021 18:57, Eike Rathke wrote: And I rather use a build from upstream repo with rpmfusion ffmpeg than I'd be using a crippled build that ripped out ffmpeg. Is it possible to build it from sources **without** Internet access? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Status update for the new AAA system
Hey folks! As you've probably heard before, we're upgrading our authentication system to something that is based on FreeIPA. Here's a quick status report on that initiative. We're currently in an integration phase, figuring out the smaller details of configuration and infrastructure setup before we switch production. - The infra team wants to do a couple things that FreeIPA does not support out of the box, like enforcing 2FA for specific services such as sudo, so we need to think about how we want to do it. - Also, using kinit with 2FA tokens proved to be more complex than we'd like it to be. - We're trying out a more continuous approach to importing accounts, because a full run takes 3 days and during the migration we'll want to run the import script without having a 3 days downtime. - We also have to do some FreeIPA performance tuning, because we have something like 120k accounts and the default configuration is not appropriate for that amount of data, especially when we want to list all groups or worse, all users. To sum it up, we're currently working on integration and migration preparation. We need to fix these issues before we go to prod, but it's a bit difficult to say how long it's going to take (especially with perf tuning, fix one perf issue and there can be another one right behind). One sure thing is that it's better to have these issues now rather than after the switch to prod. Cheers! Aurélien ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Modify %cmake_install behavior?
Currently if in source builds are set to true, %cmake_install appends a "." current directory. I'm working on building Avidemux on RPM Fusion and it requires multiple cmake builds and fakeroot installs which means I have to allow "in source builds" to stop the new behavior even though I'm manually performing multiple out-of-source builds. During %install I would much prefer to do something likes: %cmake_install %cmake_install %cmake_install ... But that's currently not possible because it assumes "." is appropriate. I'd really rather not have to pushd into each directory as that's just ugly :) Is there a way to modify the behavior of the macro to not append "."? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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 CoreOS Virtual Meetup this week
On Thu, Feb 04, 2021 at 02:34:58PM +0100, Clement Verna wrote: > On Thu, 4 Feb 2021 at 14:31, Zbigniew Jędrzejewski-Szmek > wrote: > > > On Mon, Feb 01, 2021 at 05:27:54PM +0100, Clement Verna wrote: > > > Hi all, > > > > > > We are going to hold a virtual meetup this Thursday (2021-02-04) . The > > > meetup will cover 2 topics > > > > > > * Growing Fedora CoreOS Community - from 15:00 to 15:50 UTC [0] > > > and > > > * Fedora CoreOS as an Official Edition - from 16:00 to 16:50 UTC [1] > > > > > > The goal is to have an open discussion and come up with a way forward for > > > both of these topics. If you are interested to listen or contribute > > please > > > join us here[2] > > > > > > [0] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9903 > > > [1] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9904 > > > [2] - meet.google.com/pqi-epwy-udg > > > > I'd like to join, especially the second part, but I have a > > conflict. Can you make a recording? > > > > Sure :-) Appreciated. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20210204.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 7 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 22/183 (x86_64), 29/124 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210203.n.0): ID: 769279 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/769279 ID: 769281 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/769281 ID: 769295 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/769295 ID: 769296 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/769296 ID: 769300 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/769300 ID: 769305 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/769305 ID: 769307 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/769307 ID: 769309 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/769309 ID: 769322 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/769322 ID: 769331 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/769331 ID: 769333 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/769333 ID: 769382 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/769382 ID: 769384 Test: aarch64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/769384 ID: 769385 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/769385 ID: 769386 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/769386 ID: 769388 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/769388 ID: 769397 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/769397 ID: 769404 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/769404 ID: 769413 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/769413 ID: 769417 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/769417 ID: 769418 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/769418 ID: 769487 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/769487 ID: 769547 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/769547 ID: 769564 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/769564 ID: 769677 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/769677 ID: 769708 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/769708 ID: 769709 Test: aarch64 universal install_serial_console@uefi URL: https://openqa.fedoraproject.org/tests/769709 ID: 769765 Test: aarch64 universal install_kickstart_user_creation@uefi URL: https://openqa.fedoraproject.org/tests/769765 ID: 769766 Test: aarch64 universal install_kickstart_firewall_configured@uefi URL: https://openqa.fedoraproject.org/tests/769766 ID: 769769 Test: aarch64 universal install_kickstart_nfs@uefi URL: https://openqa.fedoraproject.org/tests/769769 ID: 769770 Test: aarch64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/769770 ID: 769771 Test: aarch64 universal install_kickstart_hdd@uefi URL: https://openqa.fedoraproject.org/tests/769771 ID: 769772 Test: aarch64 universal install_rescue_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/769772 ID: 769804 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/769804 ID: 769805 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/769805 Old failures (same test failed in Fedora-Rawhide-20210203.n.0): ID: 769318 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/769318 ID: 769332 Test: x86_64 Workstation-live-iso
Re: Fedora CoreOS Virtual Meetup this week
On Thu, 4 Feb 2021 at 14:31, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Feb 01, 2021 at 05:27:54PM +0100, Clement Verna wrote: > > Hi all, > > > > We are going to hold a virtual meetup this Thursday (2021-02-04) . The > > meetup will cover 2 topics > > > > * Growing Fedora CoreOS Community - from 15:00 to 15:50 UTC [0] > > and > > * Fedora CoreOS as an Official Edition - from 16:00 to 16:50 UTC [1] > > > > The goal is to have an open discussion and come up with a way forward for > > both of these topics. If you are interested to listen or contribute > please > > join us here[2] > > > > [0] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9903 > > [1] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9904 > > [2] - meet.google.com/pqi-epwy-udg > > I'd like to join, especially the second part, but I have a > conflict. Can you make a recording? > Sure :-) > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-34-20210204.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 4/16 (x86_64), 6/15 (aarch64) New failures (same test not failed in Fedora-IoT-34-20210203.0): ID: 769781 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/769781 ID: 769796 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/769796 ID: 769799 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi URL: https://openqa.fedoraproject.org/tests/769799 Old failures (same test failed in Fedora-IoT-34-20210203.0): ID: 769775 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/769775 ID: 769784 Test: x86_64 IoT-dvd_ostree-iso podman URL: https://openqa.fedoraproject.org/tests/769784 ID: 769785 Test: x86_64 IoT-dvd_ostree-iso podman_client URL: https://openqa.fedoraproject.org/tests/769785 ID: 769791 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/769791 ID: 769794 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/769794 ID: 769801 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/769801 ID: 769802 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/769802 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-34-20210203.0): ID: 769776 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/769776 Passed openQA tests: 11/16 (x86_64), 9/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Mount /run contents changed to 73.35753176% of previous size Mount /boot contents changed to 128.6485291% of previous size Used mem changed from 157 MiB to 269 MiB System load changed from 0.11 to 0.68 Previous test data: https://openqa.fedoraproject.org/tests/768946#downloads Current test data: https://openqa.fedoraproject.org/tests/769773#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Mount /run contents changed to 73.39149400% of previous size Mount /boot contents changed to 130.5832349% of previous size Used mem changed from 158 MiB to 271 MiB System load changed from 0.22 to 0.52 Previous test data: https://openqa.fedoraproject.org/tests/768945#downloads Current test data: https://openqa.fedoraproject.org/tests/769779#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: Mount /run contents changed to 85.43046358% of previous size Mount /boot contents changed to 129.1640372% of previous size Used mem changed from 166 MiB to 310 MiB System load changed from 0.29 to 0.62 Previous test data: https://openqa.fedoraproject.org/tests/768961#downloads Current test data: https://openqa.fedoraproject.org/tests/769789#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora CoreOS Virtual Meetup this week
On Mon, Feb 01, 2021 at 05:27:54PM +0100, Clement Verna wrote: > Hi all, > > We are going to hold a virtual meetup this Thursday (2021-02-04) . The > meetup will cover 2 topics > > * Growing Fedora CoreOS Community - from 15:00 to 15:50 UTC [0] > and > * Fedora CoreOS as an Official Edition - from 16:00 to 16:50 UTC [1] > > The goal is to have an open discussion and come up with a way forward for > both of these topics. If you are interested to listen or contribute please > join us here[2] > > [0] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9903 > [1] - https://apps.fedoraproject.org/calendar/CoreOS/2021/2/4/#m9904 > [2] - meet.google.com/pqi-epwy-udg I'd like to join, especially the second part, but I have a conflict. Can you make a recording? 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: the-new-hotness is broken?
The fix is deployed to production. Michal On 04. 02. 21 10:23, Michal Konecny wrote: I will work on the fix today. Not happy about this useless change that just broke plenty of scripts. Michal On 04. 02. 21 0:23, Kevin Fenzi wrote: On Wed, Feb 03, 2021 at 05:41:27PM -0500, Elliott Sales de Andrade wrote: I just received 3 notifications that the-new-hotness saw an update for , but pkgdb says the maintainers are not interested in bugs being filed but all packages have monitoring enabled. Did something break with it? Maybe the branch name changes? Indeed it did. Filed: https://github.com/fedora-infra/the-new-hotness/issues/318 on it. Looks like it looks for a 'master' branch to tell if a package is retired or not. ;( kevin ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/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
perl-PDF-Builder-3.021 license change
perl-PDF-Builder-3.021 simplified a license from "LGPLv2+ and (GPL+ or Artistic) and (MIT or Artistic)" to "LGPLv2+ and (MIT or Artistic)". -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: src.fedoraproject.org branch conversion to rawhide/main tomorrow
I checked out https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main And in the section "Phase2" I wanted to check out the scripts in "Release engineering:" sub-section. Surprisingly (not surprisingly) the links are dead now. Will you also go through all https://fedoraproject.org/wiki links and fix them too ? -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, Feb 3, 2021 at 12:09 AM Kevin Fenzi wrote: > > Greetings everyone. > > We finally have everything in place and hopefully tested to make the > switch tomorrow from master to rawhide/main branches for > src.fedoraproject.org. > > At 13:30UTC we will adjust pagure to reject pushes to 'master' and then > will be moving all the branches over to rawhide/main. As soon as all > packages are done, we will be adjusting pdc/hooks/existing pr's. > > We will be sending an additional email once changes are complete and > hopefully any downtime will be limited. > > Once the change is completed you will want to checkout rawhide/main > instead of master and update/recreate any existing forks you have. > > See > https://fedoraproject.org/wiki/Changes/GitRepos-master-to-main > for more information. > > Thanks, > > kevin > ___ > 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
Fedora rawhide compose report: 20210204.n.0 changes
OLD: Fedora-Rawhide-20210203.n.0 NEW: Fedora-Rawhide-20210204.n.0 = SUMMARY = Added images:2 Dropped images: 4 Added packages: 6 Dropped packages:0 Upgraded packages: 189 Downgraded packages: 1 Size of added packages: 118.05 MiB Size of dropped packages:0 B Size of upgraded packages: 7.32 GiB Size of downgraded packages: 7.90 MiB Size change of upgraded packages: -647.37 MiB Size change of downgraded packages: -63.95 KiB = ADDED IMAGES = Image: Cloud_Base vagrant-virtualbox x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20210204.n.0.x86_64.vagrant-virtualbox.box Image: Cloud_Base vagrant-libvirt x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20210204.n.0.x86_64.vagrant-libvirt.box = DROPPED IMAGES = Image: Python_Classroom vagrant-virtualbox x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20210203.n.0.x86_64.vagrant-virtualbox.box Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20210203.n.0.x86_64.vagrant-libvirt.box Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20210203.n.0.iso Image: KDE_Appliance raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20210203.n.0-sda.raw.xz = ADDED PACKAGES = Package: golang-github-badoux-checkmail-1.2.1-1.fc34 Summary: Golang package for email validation RPMs:golang-github-badoux-checkmail-devel Size:11.63 KiB Package: libdatovka-0.1.1-1.fc34 Summary: Client library for accessing SOAP services of ISDS (Czech Data Boxes) RPMs:libdatovka libdatovka-devel libdatovka-doc Size:1.01 MiB Package: perl-PDF-Builder-3.019-2.fc34 Summary: Creation and modification of PDF files in Perl RPMs:perl-PDF-Builder Size:9.23 MiB Package: purple-mm-sms-0.1.7-2.fc34 Summary: A libpurple plugin for sending and receiving SMS via ModemManager RPMs:purple-mm-sms Size:202.86 KiB Package: rteval-3.1-4.fc34 Summary: Utility to evaluate system suitability for RT Linux RPMs:rteval Size:123.68 KiB Package: rteval-loads-1.4-12.fc34 Summary: Source files for rteval loads RPMs:rteval-loads Size:107.48 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 0ad-0.0.23b-24.fc34 Old package: 0ad-0.0.23b-23.fc34 Summary: Cross-Platform RTS Game of Ancient Warfare RPMs: 0ad Size: 19.65 MiB Size change: 8.99 KiB Changelog: * Wed Feb 03 2021 Kalev Lember - 0.0.23b-24 - Drop unused gamin-devel build dep Package: CubicSDR-0.2.5-12.20200824git4f1db55.fc34 Old package: CubicSDR-0.2.5-11.20200824git4f1db55.fc34 Summary: Cross-Platform Software-Defined Radio Panadapter RPMs: CubicSDR Size: 5.56 MiB Size change: 1.62 KiB Changelog: * Tue Feb 02 2021 Richard Shaw - 0.2.5-12.20200824git4f1db55 - Rebuild for hamlib 4.1. Package: R-4.0.3-3.fc34 Old package: R-4.0.3-2.fc34 Summary: A language for data analysis and graphics RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath libRmath-devel libRmath-static Size: 345.74 MiB Size change: 22.09 KiB Changelog: * Wed Feb 03 2021 Elliott Sales de Andrade - 4.0.3-3 - Always provide normalized versions of R submodules - Fixes rhbz#1924565 Package: R-AnnotationDbi-1.52.0-1.fc34 Old package: R-AnnotationDbi-1.50.0-4.fc34 Summary: Manipulation of SQLite-based annotations in Bioconductor RPMs: R-AnnotationDbi Size: 4.74 MiB Size change: -4.73 KiB Changelog: * Wed Feb 03 2021 Tom Callaway - 1.52.0-1 - update to 1.52.0 Package: R-BSgenome-1.58.0-1.fc34 Old package: R-BSgenome-1.56.0-3.fc34 Summary: Infrastructure for Biostrings-based genome data packages RPMs: R-BSgenome Size: 6.92 MiB Size change: 9.51 KiB Changelog: * Wed Feb 03 2021 Tom Callaway - 1.58.0-1 - update to 1.58.0 Package: R-Biobase-2.50.0-1.fc34 Old package: R-Biobase-2.48.0-3.fc34 Summary: Base functions for Bioconductor RPMs: R-Biobase Size: 11.00 MiB Size change: 563 B Changelog: * Wed Feb 03 2021 Tom Callaway - 2.50.0-1 - update to 2.50.0 Package: R-BiocFileCache-1.14.0-1.fc34 Old package: R-BiocFileCache-1.12.0-4.fc34 Summary: Manage Files Across Sessions RPMs: R-BiocFileCache Size: 491.00 KiB Size change: 278 B Changelog: * Wed Feb 03 2021 Tom Callaway - 1.14.0-1 - update to 1.14.0 Package: R-BiocGenerics-0.36.0-1.fc34 Old package: R-BiocGenerics-0.34.0-3.fc34 Summary: Generic functions for Bioconductor RPMs: R-BiocGenerics Size: 676.03 KiB Size change: 10.71 KiB Changelog: * Wed Feb 03 2021 Tom Callaway - 0.36.0-1 - update to 0.36.0 Package: R-BiocParallel-1.24.1-1.fc34 Old package: R-BiocParallel-1.22.0-3.fc34 Summary: Bioconductor facilities for parallel evaluation RPMs
[Bug 1919730] Please build perl-Net-XMPP for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1919730 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #4 from Fedora Update System --- FEDORA-EPEL-2021-1368e70972 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1368e70972 -- 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: Cfitsio soname bump
El mié, 3 feb 2021 a las 14:33, Alejandro Álvarez Ayllón (< aalva...@fedoraproject.org>) escribió: > Hi Sergio, > > Could you trigger a rebuild of ccfits, please? It seems it was rebuilt > against cfitsio 3.470, being uninstallable right now in rawhide. > > Hi Alejandro, it's done https://koji.fedoraproject.org/koji/buildinfo?buildID=1703454 > Best regards, > Alejandro > > El jue, 14 ene 2021 a las 1:17, Sergio Pascual () > escribió: > >> Hello, I'm going to build new cfitsio 3.490 in Rawhide in a week. This >> involves a soname bump. >> >> The affected packages are the following: >> >> CCfits >> LabPlot >> astrometry >> bes >> cpl >> elements-alexandria >> gdal >> healpix >> indi-gphoto >> kst >> kstars >> libindi >> luminance-hdr >> nightviewperl-Astro-FITS-CFITSIO >> phd2 >> python-astropy >> python-fitsio >> python-healpy >> root >> siril >> skyviewer >> sourcextractor++ >> ufraw >> vips >> wcslib >> >> Best regards, Sergio >> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1924943 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2021-2cd1ef7d50 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2cd1ef7d50 -- 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
Proposing Container Performance Monitoring Toolkit for Podman - Need Review
Hey folks, I write this to let you know that there has been this decoupled container performance monitoring toolkit that I have written for Docker, which you can find here https://github.com/t0xic0der/supervisor-driver-service (the API service) and here https://github.com/t0xic0der/supervisor-frontend-service (the web frontend). I am proposing a Podman counterpart of it with improvements and bug fixes to it as a project to be developed to complement Podman by providing a monitoring tool with easier learning curve and effective usage. You can find the links to the screenshots here https://github.com/t0xic0der/supervisor-driver-service/wiki/Screenshots (the API service) and here https://github.com/t0xic0der/supervisor-frontend-service/wiki/Screenshots (the web frontend) if you're all packed but you are requested to kindly review this idea on the basis of its need, efficacy and implementation. You can find the proposition ticket here https://pagure.io/mentored-projects/issue/95 if you wish to directly comment there. Thanks in advance! Looking forward to your responses. Regards, Akashdeep Dhar t0xic0der ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: lazarus broken dep?
Yes, I was gonna post a "Help wanted" message about this to the list, but as it
happens, procrastination got in the way.
The gist is: In lazarus.spec, we have a "%qt5pas_release" macro, and then
there's "Requires: qt5pas-devel = %{qt5pas_version}-%{qt5pas-release}", and the
qt5pas sub-package has "Release: %{qt5pas-release}". When the mass rebuild
occurs, releng scripts slap ".1" at the end of qt5-pas's Release, so then
there's a mismatch, because lazarus Requires "qt5pas = ver-rel", and qt5pas is
"ver-rel.1".
Having to undo this every time a Mass Rebuild comes around is getting tedious,
so I'm looking into finding a different way of handling this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: the-new-hotness is broken?
I will work on the fix today. Not happy about this useless change that just broke plenty of scripts. Michal On 04. 02. 21 0:23, Kevin Fenzi wrote: On Wed, Feb 03, 2021 at 05:41:27PM -0500, Elliott Sales de Andrade wrote: I just received 3 notifications that the-new-hotness saw an update for , but pkgdb says the maintainers are not interested in bugs being filed but all packages have monitoring enabled. Did something break with it? Maybe the branch name changes? Indeed it did. Filed: https://github.com/fedora-infra/the-new-hotness/issues/318 on it. Looks like it looks for a 'master' branch to tell if a package is retired or not. ;( 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
[Bug 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1924943 --- Comment #2 from Robert Scheck --- Thank you! -- 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 1924943] Please build perl-HTTP-ProxyAutoConfig for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1924943 Xavier Bachelot changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Xavier Bachelot --- I've seen that yesterday and requested a branch. I also gave you collaborator access to the epel* branches. The BuildRequires in perl-XML-Stream needs to be tweaked a bit to unconditionally BR: perl-HTTP-ProxyAutoConfig. -- 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
