Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
* Zbigniew Jędrzejewski-Szmek [05/11/2018 23:24] : > > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. [snip ] > perl-libintl-perleseyman This package had a test in its test suite that only worked if LANG=en_US was set. Upstream released a new version with this test disabled so I've updated the package in rawhide and removed the locale setting. You can ignore this package. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora testing-20181107.0 compose check report
No missing expected images. Failed openQA tests: 2/2 (x86_64) ID: 305825 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/305825 ID: 305826 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/305826 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora updates-20181107.0 compose check report
No missing expected images. Failed openQA tests: 2/2 (x86_64) Old failures (same test failed in updates-20181106.1): ID: 305823 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/305823 ID: 305824 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/305824 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Intention to orphan vulkan stack
Thanks, transfer of main-admin rights should be complete. > On Wed, Nov 7, 2018 at 9:13 AM Leigh Scott wrote: > > Hi Leigh, > > Please give them all to me. > > Thanks, > Dave. > > > > glslang > > spirv-headers > > spirv-tools > > vulkan-headers > > vulkan-loader > > vulkan-tools > > vulkan-validation-layers > > ___ > > devel mailing list -- devel(a)lists.fedoraproject.org > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Intention to orphan vulkan stack
> Hi Leigh, > > Please give them all to me. > > Thanks, Oh and thanks for all the work you've done on packaging them up until now! Dave. > Dave. > > > > glslang > > spirv-headers > > spirv-tools > > vulkan-headers > > vulkan-loader > > vulkan-tools > > vulkan-validation-layers > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Intention to orphan vulkan stack
On Wed, Nov 7, 2018 at 9:13 AM Leigh Scott wrote: > > I haven't got the time or energy to maintain these packages any more, any > takers? Hi Leigh, Please give them all to me. Thanks, Dave. > > glslang > spirv-headers > spirv-tools > vulkan-headers > vulkan-loader > vulkan-tools > vulkan-validation-layers > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intention to orphan vulkan stack
I haven't got the time or energy to maintain these packages any more, any takers? glslang spirv-headers spirv-tools vulkan-headers vulkan-loader vulkan-tools vulkan-validation-layers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Intention to orphan vulkan stack
I haven't got the time or energy to maintain these packages any more, any takers? glslang spirv-headers spirv-tools vulkan-headers vulkan-loader vulkan-tools vulkan-validation-layers ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 30 System-Wide Change proposal: The GNU C Library version 2.29
https://fedoraproject.org/wiki/Changes/GLIBC229 == Summary == Switch glibc in Fedora 30 to glibc version 2.29. == Owner == * Name: [[User:Codonell|Carlos O'Donell]] * Email: car...@redhat.com * Release notes owner: car...@redhat.com == Detailed Description == The GNU C Library version 2.29 will be released at the beginning of February 2019; we have started closely tracking the glibc 2.29 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 30 will branch after the GLIBC 2.29 upstream release. However, the mass rebuild schedule means Fedora 30 will mass rebuild (if required) after GLIBC 2.29 upstream freezes ABI for release, so careful attention must be paid to any last minute ABI changes. == Benefit to Fedora == Stays up to date with latests security and bug fixes from glibc upstream. == Scope == * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 30 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated. * Release engineering: https://pagure.io/releng/issue/7907 * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: Not needed for this change == Upgrade/compatibility impact == The library is backwards compatible with the version of glibc that was shipped in Fedora 29. Some packaging changes required, see: https://sourceware.org/glibc/wiki/Release/2.29#Packaging_Changes We fully expect to fix all packaging changes in Fedora Rawhide given that glibc in Rawhide is tracking what will become glibc 2.29. == How To Test == The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has 5900+ tests that run to verify the correct operation of the library. In the future we'll also be running the microbenchmark to look for performance regressions as well as behavioural ones. == User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc. The glibc 2.29 NEWS update will include more details. == Dependencies == All packages do not need to be rebuilt. == Contingency Plan == * Contingency mechanism: Given that Rawhide has started tracking glibc 2.29, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.28 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency deadline: Upstream ABI freeze deadline of 2019-01-01. == Documentation == The glibc manual contains the documentation for the release and doesn't need any more additional work. == Release Notes == * Release Notes tracking: The GNU C Library version 2.29 will be released at the beginning of February 2019. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tue, Nov 06, 2018 at 10:14:58PM +0100, Rafal Luzynski wrote: > 6.11.2018 00:24 Zbigniew Jędrzejewski-Szmek wrote: > > > > Dear maintainers, > > > > I'm working again on implementing > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > > [...] > > > > Once that's done, I'll file the PRs to actually replace > > glibc-langpacks-all > > with glibc-minimal-langpacks in mock and koji. > > Sorry if it's been discussed already before but one thing makes me wonder. > If glibc requires glibc-langpack and then we create glibc-minimal-langpack > which is empty and its only purpose is to provide glibc-langpack and thus > satisfy the dependency, then maybe we should just drop glibc-langpack > dependency from glibc and it would solve the problem? glibc-all-langpacks > could be removed rather than replaced with glibc-minimal-langpack. > The existence of glibc-minimal-langpack proves that glibc is able to work > without any external locale data. > > Otherwise your change looks correct to me (although I am aware of the > objections expressed in this thread). Things are the way they are so that without the additional step of specifying glibc-minimal-langpack, one get's all the locales by default. This design was chosen for maximum backwards compatibility when the langpack split was being made. Installing no locales by default would probably be the default if we were starting from scratch today, but when the split was made, a different choice was made. I don't see enough benefit to revisit this. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora testing-20181106.1 compose check report
No missing expected images. Failed openQA tests: 2/2 (x86_64) ID: 305773 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/305773 ID: 305774 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/305774 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
On Tue, Nov 6, 2018 at 6:06 PM Stephen Gallagher wrote: > > > I find myself repeating this reply over and over again in various places... Sorry about that. > The feedback that we (Red Hat) got about SCLs that was filtered down > to Engineering was this: > > 1) Customers really like having the option to install the version of > software that their applications needs from a trusted source (the OS > vendor/distributor) Not surprising, especially when it comes to RHEL and its quite long life cycle. > 2) Customers really *dislike* needing to modify their software to > understand the SCL enablement process. Really not surprising. Not that I find SCLs dis-likeable, but they require active involvement (like virtualenv and other similar things) while the trend is to make things JustWork(tm) (off the top of my head, "vagrant up", "docker run"...) > 3) Customers very rarely need to install different versions of the > same software on the same system. They use containers or VMs for > separate applications. > > So with Modularity, we opted to drop the parallel-installability > requirement in favor of parallel-*availability* and the ability to > keep the packages installing in the standard locations (/usr/bin, > /usr/lib64, etc.) I missed that change, so that's one less peeve for me. > This *is* a net improvement for the vast majority of deployments. I sort-of put Fedora modules, Snaps and Flatpaks in the same bags and at least for Snaps and Flatpaks it has always been a disaster for me (only AppImage ever worked for me with that flavor of packaging). Granted, it's not often that I need them so I haven't tested for a while now, but it never ever worked for me. Regarding modules, I superficially followed the early discussions (things like the modulemd format, initial goals etc) but as soon as the SIG was set up I lost track. I'm actually happy that the DNF plugin materialized as a "dnf module [...]" sub-command, and I only hope it won't break Fedora as I love it: First (and then stable for 13 months every 6 months). Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora updates-20181106.1 compose check report
No missing expected images. Failed openQA tests: 2/2 (x86_64) Old failures (same test failed in updates-20181105.0): ID: 305771 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/305771 ID: 305772 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/305772 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Heads up: F30 nautilus-python requires Python 3 compatibility
Further, I hereby announce to remove myself from this package as a co-maintainer. Please feel free to step into and request ACL. I added kalev as the new maintainer. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Heads up: F30 nautilus-python requires Python 3 compatibility
Hi Kalev, thanks again for the fix. Really appreciated for this critical package with its obviously important dependencies and their cases for our users. Regards, Raphael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
6.11.2018 00:24 Zbigniew Jędrzejewski-Szmek wrote: > > Dear maintainers, > > I'm working again on implementing > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > [...] > > Once that's done, I'll file the PRs to actually replace > glibc-langpacks-all > with glibc-minimal-langpacks in mock and koji. Sorry if it's been discussed already before but one thing makes me wonder. If glibc requires glibc-langpack and then we create glibc-minimal-langpack which is empty and its only purpose is to provide glibc-langpack and thus satisfy the dependency, then maybe we should just drop glibc-langpack dependency from glibc and it would solve the problem? glibc-all-langpacks could be removed rather than replaced with glibc-minimal-langpack. The existence of glibc-minimal-langpack proves that glibc is able to work without any external locale data. Otherwise your change looks correct to me (although I am aware of the objections expressed in this thread). Regards, Rafal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 29 release retrospective
Hi everyone, We released Fedora 29 last week. That's great! Now let's take a little bit of time and look back at the past. I've scheduled a Very Special Edition of the weekly FPgM office hours on Wednesday 14 November[1]. From 1330 to 1500 UTC, you can join the Jit.si meeting[2] or #fedora-meeting in IRC to discuss what went well with our process this time and opportunities to improve. I don't have a set agenda at this time, but I'd appreciate your input on topics to cover. I'll collect them off-list and set the agenda on Tuesday of next week. [1] https://apps.fedoraproject.org/calendar/meeting/9396/ [2] https://meet.jit.si/GuiltyCherriesSearchLoyally -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unretire recordmydesktop
On 11/6/18 6:21 AM, Jiri Eischmann wrote: Samuel Sieb píše v Po 05. 11. 2018 v 17:07 -0800: On 11/5/18 12:47 PM, Adam Williamson wrote: On Sun, 2018-11-04 at 16:42 -0800, Samuel Sieb wrote: I don't know about the other bugs, but not working on Wayland can't be held against it. Nothing works to record the desktop on Wayland since that isn't supported yet. GNOME's inbuilt screen recorder does it fine. Does that use a Gnome shell-specific API or does Wayland have support for that now? You can either use Mutter API (several utilities can do that, not only the built-in tool) or newly PipeWire. Works both on Wayland and Xorg. Screen recording (or more precisely providing apps with screen frames) is not something Wayland as a protocol covers and plans to cover. Then it's time to port vino to PipeWire, so I don't have to disable Wayland on all the systems I install. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
On Tue, Nov 6, 2018 at 12:26 PM Stephen Gallagher wrote: > > As a hypothetical example, maybe python-sphinx has a major > backwards-incompatible update that becomes the default in Fedora 30. > The package you maintain will only build its docs with the older Sphinx. > Without Ursa Major, you basically have two choices: 1) Stop building > the docs until upstream catches up to Sphinx, or 2) Try to write a patch > to support the new version of Sphinx. With Ursa Major, you potentially > gain 3) BuildRequires the previous version of Sphinx for your package. So, this statement is the core of what I don't like about modularity. Pitching it as a means of allowing people to "keep back" even in packages for the distribution is bad for a distribution that pushes forward. One of the major reasons I prefer Fedora to other distributions is that we contribute to the advancement of FOSS through our developers and packagers. This goes to the extent of helping upstreams port forward and leverage new versions and new functionality. Now, I don't hate modularity as a concept, but I have personally felt that the design and approach to modules in Fedora is horribly misguided. From my perspective, it seems to be pitched as a way for Fedora to move slower, and that's not what I want from a distribution like Fedora. Moreover, as it stands, I don't think modularity provides any quality of life improvements for packagers within Fedora (it adds extra steps and makes it confusing to figure out what is maintained), and currently is a huge impairment for packagers outside of Fedora. I've brought up the issues I have with the "modularization" of things within Fedora from the context of a third-party packager, and I haven't yet seen a solution outlined with my concerns fully handled. And as I've also pointed out privately and publicly in other instances, the extra "foreign" metadata is difficult or impossible for most tools today to handle. There is some hope that those issues will be addressed, but I'm unsure if anyone cares enough to prioritize these issues. It's very clear that modules as they currently stand aren't designed for Fedora. They're designed for Red Hat Enterprise Linux. And that's not good, because we're trying to use it in Fedora. Personally, I see the value proposition for modules as such in the context of Fedora: * Providing non-default, older version packages for backwards compatibility and supporting stepped upgrade processes. Common examples of this are ownCloud/Nextcloud, OpenShift/Kubernetes, and so on. * Offering alternative variants of language runtime stacks from the system version. The tooling around modules automates the chain building process and could actually be used to generate alternate versions of language stacks very easily. This can be something like having Python 2 being managed as a module that can be built on demand for people who need it, or supporting PHP 5 when PHP 7 won't work, or something like that. What I am annoyed about is that there's been almost zero interest in actually improving the quality of life of packagers who handle the bulk of packages in Fedora, the so-called "ursine" packages (which I'm not terribly pleased about the name...). I've outlined for a couple of years now some improvements we could make here. I also continue to wonder why we aren't pushing for a merger of Koji, Koschei, and COPR to provide better workflows across the board. One of our biggest problems is that it's _impossible_ to stage any change in a suitably useful way and do things like install checks, media creation, OpenQA runs, and so on. This is the critical difference between our development process and openSUSE's, as an example. We also seem to have some kind of fear about having extra optional repositories for people to enable for non-default stuff, which is why modules are wired up the way they are (modules look like repos to the solver, and enabling and disabling them triggers that base logic). I also feel that some of the tooling we developed for modules actually would equally apply well for regular packages. For example, MBS implements a giant hack for Koji so that it's actually possible to generate a side-tag, build all the packages and their incorporated dependencies, and then export it to be included in a module. But why not adapt that model for everything else? Why not allow someone to trigger a build of something, check for reverse dependencies, include them automatically, and then build it in a side tag in the exactly correct order (as determined by the solver)? The reverse dependencies could get a normal rebuild spec bump and then have that committed to dist-git (or not, depending on how we do it!), and then merge it back into the distro after it all succeeds. The advantage of this is that if something does fail, it can be independently handled and merged into the side tag, and once all the builds in a tag are green, it could auto-merge into the main distribution tag (rawhide, updates-can
Planned Outage - System Updates/reboots - 2018-11-07 21:00 UTC
Planned Outage - System Updates/reboots - 2018-11-07 21:00 UTC There will be an outage starting at 2018-11-07 21:00 UTC, which will last approximately 6 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2018-11-07 21:00UTC' Reason for outage: We will be applying updates and rebooting servers as well as doing some hardware maint tasks (disk replacement, etc). Affected Services: Most fedoraproject.org services will be affected some in the outage window. Most services should only be down for a short time during the outage window. Ticket Link: https://pagure.io/fedora-infrastructure/issue/7357 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: OpenPGP digital signature ___ 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://getfedora.org/code-of-conduct.html 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
On Tue, Nov 6, 2018 at 11:21 AM Jason L Tibbitts III wrote: > > > "FW" == Florian Weimer writes: > > FW> Modules do not support parallel installations of different module > FW> versions. Many SCLs are constructed in such a way that this is > FW> possible. So I'm not sure if modules are a clear improvement over > FW> SCLs. > > And the really fun thing is that once the different versions are > installable in parallel you could just have them in different > packages. So SCLs aren't really an improvement over plain old packages, > either. > > So it seems to me that modules are useful specifically in the "not > parallel installable" case; they seem to be to simply be a framework for > handling sets of mutually exclusive packages (and the combinatorial > dependency explosion which results). Which I guess is reasonable, > though I always thought they would be the last resort when > you can't make two versions able to be installed in parallel. Instead > it seems like they're being pushed as the default, which just seems > backwards to me. I think it only seems that way because there's a non-trivial number of useful packages (e.g. Node.js) that can't be trivially installed in parallel like Python can and which have regular, backwards-incompatible jumps and multiple supported upstream versions. This has always been a problem for Fedora; either users would hold their systems back on unsupported Fedora releases to maintain older versions, or else they'd stop using our packaged versions at all, which devalues us. Modules gives us the ability to allow us to ship whatever versions the maintainer is willing to maintain. Now, one thing that I think hasn't been made clear in this thread is this: Ursa Major is net-new functionality. With or without modules today, you can only have in the buildroot the set of things that you could get from DNF without being aware of module-specific commands. Modules with a default stream Just Work for buildroots. The improvement with Ursa Major is the ability to have a non-default version of software available *only at build-time*. As a hypothetical example, maybe python-sphinx has a major backwards-incompatible update that becomes the default in Fedora 30. The package you maintain will only build its docs with the older Sphinx. Without Ursa Major, you basically have two choices: 1) Stop building the docs until upstream catches up to Sphinx, or 2) Try to write a patch to support the new version of Sphinx. With Ursa Major, you potentially gain 3) BuildRequires the previous version of Sphinx for your package. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
> "FW" == Florian Weimer writes: FW> Modules do not support parallel installations of different module FW> versions. Many SCLs are constructed in such a way that this is FW> possible. So I'm not sure if modules are a clear improvement over FW> SCLs. And the really fun thing is that once the different versions are installable in parallel you could just have them in different packages. So SCLs aren't really an improvement over plain old packages, either. So it seems to me that modules are useful specifically in the "not parallel installable" case; they seem to be to simply be a framework for handling sets of mutually exclusive packages (and the combinatorial dependency explosion which results). Which I guess is reasonable, though I always thought they would be the last resort when you can't make two versions able to be installed in parallel. Instead it seems like they're being pushed as the default, which just seems backwards to me. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
On Tue, Nov 6, 2018 at 10:47 AM Florian Weimer wrote: > > * Nicolas Mailhot: > > > My current understanding of modules benefits is that they’re just > > improved SCLs. ie something EL oriented that the average Fedora packager > > has little interest or use for. > > > > Practically, being improved SCLs just means: > > > > 1. rawhide has the latest version of each module enabled by default, > > 2. stable has the same version enabled by default if the module version > > is completely baked, and the previous one otherwise > > 3. epel has the same module version as stable enabled by default > > Modules do not support parallel installations of different module > versions. Many SCLs are constructed in such a way that this is > possible. So I'm not sure if modules are a clear improvement over SCLs. > I find myself repeating this reply over and over again in various places... The feedback that we (Red Hat) got about SCLs that was filtered down to Engineering was this: 1) Customers really like having the option to install the version of software that their applications needs from a trusted source (the OS vendor/distributor) 2) Customers really *dislike* needing to modify their software to understand the SCL enablement process. 3) Customers very rarely need to install different versions of the same software on the same system. They use containers or VMs for separate applications. So with Modularity, we opted to drop the parallel-installability requirement in favor of parallel-*availability* and the ability to keep the packages installing in the standard locations (/usr/bin, /usr/lib64, etc.) This *is* a net improvement for the vast majority of deployments. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tue, Nov 06, 2018 at 09:21:09AM -0600, Dennis Gilmore wrote: > What is the change you are planning to put into mock and koji? In both cases, we know that bash and other utilities will pull in glibc, which Requires glibc-langpack, and pulls in glibc-all-langpacks by default. My plan is to add glibc-minimal-langpack to those lists. It also provides glibc-langpack, and will prevent glibc-all-langpacks from being pulled in automatically. Zbyszek > the build group in koji is defined as > > > build > build > None > false > true > > bash > bzip2 > coreutils > cpio > diffutils > fedora-release > findutils > gawk > grep > gzip > info > make > patch > redhat-rpm-config > rpm-build > sed > shadow-utils > tar > unzip > util-linux > which > xz > > > and in f30 comps the buildsys-build group is > > buildsys-build > <_name>Buildsystem building group > <_description/> > false > false > > bash > bzip2 > coreutils > cpio > diffutils > fedora-release > findutils > gawk > grep > gzip > info > make > patch > redhat-rpm-config > rpm-build > sed > shadow-utils > tar > unzip > util-linux > which > xz > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
* Nicolas Mailhot: > My current understanding of modules benefits is that they’re just > improved SCLs. ie something EL oriented that the average Fedora packager > has little interest or use for. > > Practically, being improved SCLs just means: > > 1. rawhide has the latest version of each module enabled by default, > 2. stable has the same version enabled by default if the module version > is completely baked, and the previous one otherwise > 3. epel has the same module version as stable enabled by default Modules do not support parallel installations of different module versions. Many SCLs are constructed in such a way that this is possible. So I'm not sure if modules are a clear improvement over SCLs. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
El lun, 05-11-2018 a las 23:24 +, Zbigniew Jędrzejewski-Szmek escribió: > Dear maintainers, > > I'm working again on implementing > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > will be backwards and forwards compatible, in the sense that packages > that use C.UTF-8 should build OK on older and newer Fedoras. > > Once that's done, I'll file the PRs to actually replace glibc- > langpacks-all > with glibc-minimal-langpacks in mock and koji. What is the change you are planning to put into mock and koji? the build group in koji is defined as build build None false true bash bzip2 coreutils cpio diffutils fedora-release findutils gawk grep gzip info make patch redhat-rpm-config rpm-build sed shadow-utils tar unzip util-linux which xz and in f30 comps the buildsys-build group is buildsys-build <_name>Buildsystem building group <_description/> false false bash bzip2 coreutils cpio diffutils fedora-release findutils gawk grep gzip info make patch redhat-rpm-config rpm-build sed shadow-utils tar unzip util-linux which xz These are what mock uses to create the minimal buildroot in both cases, neither includes anything with glibc, greping through the mock code for glibc turns up nothing. I mention all of this because glibc-all- langpacks is pulled into the buildroot entirely by dependencies, the only change needed is to whatever package is pulling in glibc-all- langpacks to no longer pull it in. Dennis signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: please help retire libocrdma
On Tue, Nov 06, 2018 at 03:49:30PM +0100, Michael Schwendt wrote: > On Tue, 6 Nov 2018 21:48:16 +0800, Honggang LI wrote: > > > hi, > > > > libocrdma had been merged into rdma-core in upstream, so libocrdma is > > obsoleted by rdma-core. > > > > The package owner Selvin tried to retire this package, but failed > > with authentication. > > > > We need someone who manages/maintains fedora package repos to retire > > libocrdam for us. > > It has been retired 8 hours ago: > > https://src.fedoraproject.org/rpms/libocrdma/commits/master > and > https://src.fedoraproject.org/rpms/libocrdma/blob/master/f/dead.package ok, it looks good. thanks > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tue, Nov 06, 2018 at 03:53:56PM +0100, David Woodhouse wrote: > On Mon, 2018-11-05 at 23:24 +, Zbigniew Jędrzejewski-Szmek wrote: > > Dear maintainers, > > > > I'm working again on implementing > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > > will be backwards and forwards compatible, in the sense that packages > > that use C.UTF-8 should build OK on older and newer Fedoras. > > > > Once that's done, I'll file the PRs to actually replace glibc-langpacks-all > > with glibc-minimal-langpacks in mock and koji. > > > > I'll do a mass update to use C.UTF-8 for the packages in the list that > > follows, next week. I'll do test builds locally, and I'll only push to > > dist-git if the local builds succeed. Let me know if you want your > > package to be excluded. > > The self-tests for OpenConnect explicitly use cs_CZ.ISO8859-2 for > pathological password handling — using a password of "ĂŻ" (U+0102 > U+017B) in the local charset and making sure it works correctly. > > Do I just need to BuildRequire glibc-langpacks-all manually to make > that work again? That, or glibc-langpack-cs. (cs is 0.5 MB, glibc-all-langpacks is 25 MB). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
* David Woodhouse: > The self-tests for OpenConnect explicitly use cs_CZ.ISO8859-2 for > pathological password handling — using a password of "ĂŻ" (U+0102 > U+017B) in the local charset and making sure it works correctly. > > Do I just need to BuildRequire glibc-langpacks-all manually to make > that work again? Yes, or depend on the cs langpack. Similar for any test that needs a non-UTF-8 locale. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
* Panu Matilainen: > On 11/06/2018 02:13 PM, Mike FABIAN wrote: >> Panu Matilainen さんはかきました: >> >>> On 11/06/2018 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 06, 2018 at 12:10:04PM +0200, Panu Matilainen wrote: > On 11/06/2018 03:05 AM, Kevin Kofler wrote: >> Zbigniew Jędrzejewski-Szmek wrote: >>> The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 >>> (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. >> >> But there are probably many more packages where the setting is hidden in >> upstream build scripts. > > Build- and various other scripts. > > Is C.UTF-8 glibc upstream now, or is it still Fedora-specific? It was never Fedora-specific. The original justification in 2013 or so was "other distros already do it". It's just glibc upstream that doesn't have it. We still carry https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc-c-utf8-locale.patch, so it seems this hasn't been upstream. >>> >>> Ugh, this is a rather cumbersome situation for other projects: >>> supporting and using C.UTF-8 isn't going to happen large scale until >>> it's upstreamed. And it does make one wonder what exactly is >>> preventing it from being upstreamed in glibc. >> >> The current C.UTF-8 locale doesn’t sort correctly. It should sort >> according to code point order, but it does that only partly. It is sort >> of a quick hack. The glibc developers are working on a better solution >> but this takes more time. >> > > Hmm. Not sorting correctly doesn't sound so good when LANG=C (and now > C.UTF-8) is quite commonly used exactly for that purpose. Not all looks fixable to me in the current setting. We expose the table layout via nl_langinfo, so that's part of the ABI, and the tables just cannot express the sorting order with less than three to four bytes per codepoint. That's a lot of data even if we restrict ourselves to the modern UTF-8 range (those codepoints addressable using UTF-16 surrogate pairs). I think we could generate the tables on the fly if they are ever requested using nl_langinfo. Not many applications seem to do that. Internally within glibc, we could use a different interface to avoid the table generation. The table layout also has significant problems with expressing proper collation tables. We need to investigate this more deeply, but my impression is that the collation and collation sequence tables constitute a significant fraction of the locale data on disk. Changing the table layout again has ABI implications there, similar to those for C.UTF-8, except that the on-the-fly conversation code will be more difficult to write. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Mon, 2018-11-05 at 23:24 +, Zbigniew Jędrzejewski-Szmek wrote: > Dear maintainers, > > I'm working again on implementing > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > will be backwards and forwards compatible, in the sense that packages > that use C.UTF-8 should build OK on older and newer Fedoras. > > Once that's done, I'll file the PRs to actually replace glibc-langpacks-all > with glibc-minimal-langpacks in mock and koji. > > I'll do a mass update to use C.UTF-8 for the packages in the list that > follows, next week. I'll do test builds locally, and I'll only push to > dist-git if the local builds succeed. Let me know if you want your > package to be excluded. The self-tests for OpenConnect explicitly use cs_CZ.ISO8859-2 for pathological password handling — using a password of "ĂŻ" (U+0102 U+017B) in the local charset and making sure it works correctly. Do I just need to BuildRequire glibc-langpacks-all manually to make that work again? smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: please help retire libocrdma
On Tue, 6 Nov 2018 21:48:16 +0800, Honggang LI wrote: > hi, > > libocrdma had been merged into rdma-core in upstream, so libocrdma is > obsoleted by rdma-core. > > The package owner Selvin tried to retire this package, but failed > with authentication. > > We need someone who manages/maintains fedora package repos to retire > libocrdam for us. It has been retired 8 hours ago: https://src.fedoraproject.org/rpms/libocrdma/commits/master and https://src.fedoraproject.org/rpms/libocrdma/blob/master/f/dead.package ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On 11/06/2018 02:13 PM, Mike FABIAN wrote: Panu Matilainen さんはかきました: On 11/06/2018 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 06, 2018 at 12:10:04PM +0200, Panu Matilainen wrote: On 11/06/2018 03:05 AM, Kevin Kofler wrote: Zbigniew Jędrzejewski-Szmek wrote: The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. But there are probably many more packages where the setting is hidden in upstream build scripts. Build- and various other scripts. Is C.UTF-8 glibc upstream now, or is it still Fedora-specific? It was never Fedora-specific. The original justification in 2013 or so was "other distros already do it". It's just glibc upstream that doesn't have it. We still carry https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc-c-utf8-locale.patch, so it seems this hasn't been upstream. Ugh, this is a rather cumbersome situation for other projects: supporting and using C.UTF-8 isn't going to happen large scale until it's upstreamed. And it does make one wonder what exactly is preventing it from being upstreamed in glibc. The current C.UTF-8 locale doesn’t sort correctly. It should sort according to code point order, but it does that only partly. It is sort of a quick hack. The glibc developers are working on a better solution but this takes more time. Hmm. Not sorting correctly doesn't sound so good when LANG=C (and now C.UTF-8) is quite commonly used exactly for that purpose. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unretire recordmydesktop
Samuel Sieb píše v Po 05. 11. 2018 v 17:07 -0800: > On 11/5/18 12:47 PM, Adam Williamson wrote: > > On Sun, 2018-11-04 at 16:42 -0800, Samuel Sieb wrote: > > > I don't know about the other bugs, but not working on Wayland > > > can't be > > > held against it. Nothing works to record the desktop on Wayland > > > since > > > that isn't supported yet. > > > > GNOME's inbuilt screen recorder does it fine. > > Does that use a Gnome shell-specific API or does Wayland have > support > for that now? You can either use Mutter API (several utilities can do that, not only the built-in tool) or newly PipeWire. Works both on Wayland and Xorg. Screen recording (or more precisely providing apps with screen frames) is not something Wayland as a protocol covers and plans to cover. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tue, Nov 6, 2018 at 8:58 AM Dominik 'Rathann' Mierzejewski wrote: > > On Tuesday, 06 November 2018 at 00:24, Zbigniew Jędrzejewski-Szmek wrote: > > Dear maintainers, > > > > I'm working again on implementing > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > > will be backwards and forwards compatible, in the sense that packages > > that use C.UTF-8 should build OK on older and newer Fedoras. > > > > Once that's done, I'll file the PRs to actually replace glibc-langpacks-all > > with glibc-minimal-langpacks in mock and koji. > > > > I'll do a mass update to use C.UTF-8 for the packages in the list that > > follows, next week. I'll do test builds locally, and I'll only push to > > dist-git if the local builds succeed. Let me know if you want your > > package to be excluded. > > > > Zbyszek > [...] > > Packages by maintainer: > [...] > > rathannlazygal libmp4v2 > > Please add BR: glibc-langpack-en instead of changing locale for these. > > Regards, > Dominik From pain with other packages that require language settings, such as Chef, I'd really encourage enabling the existing defaults rather than trying to modify all the packages. That way lies a lot of work for our friends doing EPEL backports. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
please help retire libocrdma
hi, libocrdma had been merged into rdma-core in upstream, so libocrdma is obsoleted by rdma-core. The package owner Selvin tried to retire this package, but failed with authentication. We need someone who manages/maintains fedora package repos to retire libocrdam for us. thanks ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages [MORE PACKAGES]
On Tue, Nov 06, 2018 at 12:05:03PM +, Paul Howarth wrote: > On Tue, 6 Nov 2018 10:25:58 + > Zbigniew Jędrzejewski-Szmek wrote: > > > pghmcfcperl-Perl-Critic perl-Perl-OSType perl-Text-Hunspell > > perl-Text-SpellChecker > > These packages all set either LANG or LC_ALL to en_US for the purposes > of setting the correct language for the spell check in their test > suites. They all build-require hunspell-en to provide the required > dictionary. Are they also going to need glibc-langpack-en? They are going to need to declare BR:glibc-langpack-en. (The dependency was already there, just implicit.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tue, Nov 06, 2018 at 02:05:06PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 06 November 2018 at 13:13, Florian Weimer wrote: > > * Zbigniew Jędrzejewski-Szmek: > > > > > Dear maintainers, > > > > > > I'm working again on implementing > > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > > > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > > > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > > > will be backwards and forwards compatible, in the sense that packages > > > that use C.UTF-8 should build OK on older and newer Fedoras. > > > > I think this is a very bad idea. The C.UTF-8 locale is Fedora-specific. > > It is not upstream, and it is known to be broken in many ways. It may > > or may not match what other distributions use. > > > > I have argued for some time that the locale must be upstreamed, but > > unfortunately, I'm notglibc-langpack-minimal getting anywhere. > > Can we use glibc-langpack-en instead of glibc-langpack-minimal and keep > en_US.UTF-8 locale as default? glibc-langpack-en is 6MB, glibc-langpack-minimal is ~0. Pretty much all packages don't need an actual language. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Heads up: F30 nautilus-python requires Python 3 compatibility
Hi all, If you are maintaining a nautilus extension package written in Python, please check that it supports Python 3 in rawhide/F30 (and fix it up if it doesn't). Up until F29, nautilus-python used Python 2, but in rawhide it's now switched to use Python 3. More info: https://bugzilla.redhat.com/show_bug.cgi?id=1636626 Thanks! -- Kalev ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tue, Nov 06, 2018 at 02:07:06PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 06 November 2018 at 00:24, Zbigniew Jędrzejewski-Szmek wrote: > > Dear maintainers, > > > > I'm working again on implementing > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > > will be backwards and forwards compatible, in the sense that packages > > that use C.UTF-8 should build OK on older and newer Fedoras. > > > > Once that's done, I'll file the PRs to actually replace glibc-langpacks-all > > with glibc-minimal-langpacks in mock and koji. > > > > I'll do a mass update to use C.UTF-8 for the packages in the list that > > follows, next week. I'll do test builds locally, and I'll only push to > > dist-git if the local builds succeed. Let me know if you want your > > package to be excluded. > > > > Zbyszek > [...] > > Packages by maintainer: > [...] > > rathannlazygal libmp4v2 > > Please add BR: glibc-langpack-en instead of changing locale for these. OK. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tuesday, 06 November 2018 at 00:24, Zbigniew Jędrzejewski-Szmek wrote: > Dear maintainers, > > I'm working again on implementing > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > will be backwards and forwards compatible, in the sense that packages > that use C.UTF-8 should build OK on older and newer Fedoras. > > Once that's done, I'll file the PRs to actually replace glibc-langpacks-all > with glibc-minimal-langpacks in mock and koji. > > I'll do a mass update to use C.UTF-8 for the packages in the list that > follows, next week. I'll do test builds locally, and I'll only push to > dist-git if the local builds succeed. Let me know if you want your > package to be excluded. > > Zbyszek [...] > Packages by maintainer: [...] > rathannlazygal libmp4v2 Please add BR: glibc-langpack-en instead of changing locale for these. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tuesday, 06 November 2018 at 13:13, Florian Weimer wrote: > * Zbigniew Jędrzejewski-Szmek: > > > Dear maintainers, > > > > I'm working again on implementing > > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > > will be backwards and forwards compatible, in the sense that packages > > that use C.UTF-8 should build OK on older and newer Fedoras. > > I think this is a very bad idea. The C.UTF-8 locale is Fedora-specific. > It is not upstream, and it is known to be broken in many ways. It may > or may not match what other distributions use. > > I have argued for some time that the locale must be upstreamed, but > unfortunately, I'm not getting anywhere. Can we use glibc-langpack-en instead of glibc-langpack-minimal and keep en_US.UTF-8 locale as default? Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
Le mardi 06 novembre 2018 à 11:05 +0100, Dridi Boukelmoune a écrit : > > I'm with you in the sense that I too fail to see practical benefits > > of > > modules so far. But e.g. the java-sig says it makes their life > > easier, > > and it is their choice. The decision was made to proceed with > > modularity in Fedora. Once that decision was made, we cannot forbid > > packagers from making use of the new functionality. This further > > step > > is only a natural consequence. > > Besides not seeing benefits of modules, while I do understand the > rationale it's also something I disagree with. I feel like modules go > against the First principle, I get a sense of bundling there too. My current understanding of modules benefits is that they’re just improved SCLs. ie something EL oriented that the average Fedora packager has little interest or use for. Practically, being improved SCLs just means: 1. rawhide has the latest version of each module enabled by default, 2. stable has the same version enabled by default if the module version is completely baked, and the previous one otherwise 3. epel has the same module version as stable enabled by default So the average Fedora packager ends up maintaining at most two streams of packages in parallel. That actually cut downs the number of version a Fedora packager needs to maintain from 3 (devel + 2 × stable) to 2. I suppose one could up it to 3 to get the same QA levels as the current systems. Realistically, one could even use Fedora release versions as module versions. And every other combination is an explicit user choice, for the same people that use or maintain SCLs today, with about the same level of popularity or uptake. And everyone who hopes to see a flourishing of module versions will hit the “no one’s interested in packaging and QA- ing a miriad versions of the same software” wall. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
* Zbigniew Jędrzejewski-Szmek: > Dear maintainers, > > I'm working again on implementing > https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This > will be backwards and forwards compatible, in the sense that packages > that use C.UTF-8 should build OK on older and newer Fedoras. I think this is a very bad idea. The C.UTF-8 locale is Fedora-specific. It is not upstream, and it is known to be broken in many ways. It may or may not match what other distributions use. I have argued for some time that the locale must be upstreamed, but unfortunately, I'm not getting anywhere. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
Panu Matilainen さんはかきました: > On 11/06/2018 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote: >> On Tue, Nov 06, 2018 at 12:10:04PM +0200, Panu Matilainen wrote: >>> On 11/06/2018 03:05 AM, Kevin Kofler wrote: Zbigniew Jędrzejewski-Szmek wrote: > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. But there are probably many more packages where the setting is hidden in upstream build scripts. >>> >>> Build- and various other scripts. >>> >>> Is C.UTF-8 glibc upstream now, or is it still Fedora-specific? >> >> It was never Fedora-specific. The original justification in 2013 or so >> was "other distros already do it". It's just glibc upstream that doesn't >> have it. >> >> We still carry >> https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc-c-utf8-locale.patch, >> so it seems this hasn't been upstream. > > Ugh, this is a rather cumbersome situation for other projects: > supporting and using C.UTF-8 isn't going to happen large scale until > it's upstreamed. And it does make one wonder what exactly is > preventing it from being upstreamed in glibc. The current C.UTF-8 locale doesn’t sort correctly. It should sort according to code point order, but it does that only partly. It is sort of a quick hack. The glibc developers are working on a better solution but this takes more time. > - Panu - > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Mike FABIAN 睡眠不足はいい仕事の敵だ。 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages [MORE PACKAGES]
On Tue, 6 Nov 2018 10:25:58 + Zbigniew Jędrzejewski-Szmek wrote: > pghmcfcperl-Perl-Critic perl-Perl-OSType perl-Text-Hunspell > perl-Text-SpellChecker These packages all set either LANG or LC_ALL to en_US for the purposes of setting the correct language for the spell check in their test suites. They all build-require hunspell-en to provide the required dictionary. Are they also going to need glibc-langpack-en? Paul. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Safe to remove yum?
Dne 06. 11. 18 v 9:49 Miroslav Suchý napsal(a): > Dne 04. 11. 18 v 14:08 Dominik 'Rathann' Mierzejewski napsal(a): >> Unless you're building packages for EPEL locally using mock, >> but then you can use mock --dnf. > Or `mock --bootstrap-chroot`, which build in two stages. First install small > root with DNF from e.g. F29 and then will > use this DNF to install the final chroot. The scenario should be actually "First install small root with YUM from e.g. F29 (and it should says EPEL actually) and then will use this YUM to install the final chroot." and as far as I remember, this have newer really worked: https://bugzilla.redhat.com/show_bug.cgi?id=1467314 V. > > Miroslav > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On 11/06/2018 12:15 PM, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 06, 2018 at 12:10:04PM +0200, Panu Matilainen wrote: On 11/06/2018 03:05 AM, Kevin Kofler wrote: Zbigniew Jędrzejewski-Szmek wrote: The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. But there are probably many more packages where the setting is hidden in upstream build scripts. Build- and various other scripts. Is C.UTF-8 glibc upstream now, or is it still Fedora-specific? It was never Fedora-specific. The original justification in 2013 or so was "other distros already do it". It's just glibc upstream that doesn't have it. We still carry https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc-c-utf8-locale.patch, so it seems this hasn't been upstream. Ugh, this is a rather cumbersome situation for other projects: supporting and using C.UTF-8 isn't going to happen large scale until it's upstreamed. And it does make one wonder what exactly is preventing it from being upstreamed in glibc. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages [MORE PACKAGES]
On Tue, Nov 06, 2018 at 10:08:04AM +, Tom Hughes wrote: > On 05/11/2018 23:24, Zbigniew Jędrzejewski-Szmek wrote: > > >I'll do a mass update to use C.UTF-8 for the packages in the list that > >follows, next week. I'll do test builds locally, and I'll only push to > >dist-git if the local builds succeed. Let me know if you want your > >package to be excluded. > > I've done mapnik (which seems to be missing from your list for > some reason) and python-mapnik. Arghhh! regexp failure on my part. I missed a bunch of packages. Maintainers by package: ant akurtakov jcapik kdaniel mizdebsk msrb aspectjweavergil rfenkhuber autoarchive fab c++-gtk-utilsairwave echevemaster espeak-ngolysonek hyphen-grc caolanm kgb-bot averi mecab-java mtasaka perl-App-PFT dacav perl-Glib-Object-Introspection berrange ddick perl-PFT dacav perl-Perl-Critic jplesnik pghmcfc ppisar perl-Perl-OSType pghmcfc perl-Text-Hunspell pghmcfc perl-Text-SpellChecker pghmcfc perl-libintl-perleseyman pl bagnara mef ppisar po4a athimm sergiomb sharkcz python-argh cstratak python-autopep8 mrunge ndipanov python-cairocffi brouhaha jdulaney python-congressclient mflobo python-cotyledon apevec pkilambi python-enchant cstratak mmraka python-evic besser82 python-httpbin adamwill python-httpretty jamielennox python-jsonpatch apevec dprince skottler python-jsonpointer apevec dprince skottler python-muranoclient mflobo python-netaddr jcholast jeckersb jhrozek python-pankoclient pkilambi python-pifpafhguemar pkilambi python-ptyprocessignatenkobrain orion tomspur python-pymrunge thm python-rospkgcottsay rmattes python-scandir aviso salimma python-sphinxaviso cstratak salimma toshio python-tenacity pkilambi python-webtest bkabrda lmacken ricky python-yaql mflobo pywebdav sharkcz rubygem-asciidoctor fale ktdreyer mojavelinux rubygem-charlock_holmes axilleas ktdreyer rubygem-coderay jaruga rubygem-em-http-request jackorp rubygem-fast_gettext vondruch rubygem-gettext-setup domcleal rubygem-highline jamielinux stahnma tdawson rubygem-hpricot kanarip mtasaka rubygem-i18n humaton jstribny stahnma vondruch rubygem-jekyll-feed decathorpe rubygem-kramdown mtasaka rubygem-marc mtasaka rubygem-minitest humaton jstribny mkent mmorsi skottler smoitra stahnma vondruch rubygem-mustache vondruch rubygem-nokogiri kanarip mtasaka tdawson tremble rubygem-pangomtasaka rubygem-power_assert mtasaka rubygem-rack jaruga jstribny mmorsi smoitra stevetraylen vondruch rubygem-redisaxilleas rubygem-rspec-core bkearney mtasaka skottler tdawson vondruch rubygem-rspec-expectations bkearney mtasaka skottler tdawson vondruch rubygem-rspec-mocks bkearney mtasaka skottler tdawson vondruch rubygem-rspec-support mtasaka rubygem-rspec2-core mtasaka rubygem-rspec2-expectations mtasaka rubygem-taskjuggler orphan rubygem-tilt ktdreyer valtri vondruch udiskie jstanek Packages by maintainer: adamwill python-httpbin airwavec++-gtk-utils akurtakov ant apevec python-cotyledon python-jsonpatch python-jsonpointer athimm po4a averi kgb-bot aviso python-scandir python-sphinx axilleas rubygem-charlock_holmes rubygem-redis bagnarapl berrange perl-Glib-Object-Introspection besser82 python-evic bkabrdapython-webtest bkearney rubygem-rspec-core rubygem-rspec-expectations rubygem-rspec-mocks brouhaha python-cairocffi caolanmhyphen-grc cottsaypython-rospkg cstratak python-argh python-enchant python-sphinx dacav perl-App-PFT perl-PFT ddick perl-Glib-Object-Introspection decathorpe rubygem-jekyll-feed domcleal rubygem-gettext-setup dprincepython-jsonpatch python-jsonpointer echevemaster c++-gtk-utils eseymanperl-libintl-perl fabautoarchive fale rubygem-asciidoctor gilaspectjweaver hguemarpython-pifpaf humatonrubygem-i18n rubygem-minitest ignatenkobrain python-ptyprocess jackorprubygem-em-http-request jamielennox python-httpretty jamielinux rubygem-highline jaruga rubygem-coderay rubygem-rack jcapik ant jcholast python-netaddr jdulaney python-cairocffi jeckersb python-netaddr jhrozekpython-netaddr jplesnik perl-Perl-Critic jstanekudiskie jstribny rubygem-i18n rubygem-minitest rubygem-rack kanariprubygem-hpricot rubygem-nokogiri kdanielant ktdreyer rubygem-asciidoctor rubygem-charlock_holmes rubygem-tilt lmackenpython-webtest mefpl mflobo python-congressclient python-muranoclient python-yaql mizdebsk ant mkent rubygem-minitest mmorsi rubygem-minitest rubygem-rack mmraka python-enchant mojavelinux rubygem-asciidoctor mrunge python-autopep8 python-py msrb
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tue, Nov 06, 2018 at 12:10:04PM +0200, Panu Matilainen wrote: > On 11/06/2018 03:05 AM, Kevin Kofler wrote: > >Zbigniew Jędrzejewski-Szmek wrote: > >>The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > >>(and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. > > > >But there are probably many more packages where the setting is hidden in > >upstream build scripts. > > Build- and various other scripts. > > Is C.UTF-8 glibc upstream now, or is it still Fedora-specific? It was never Fedora-specific. The original justification in 2013 or so was "other distros already do it". It's just glibc upstream that doesn't have it. We still carry https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc-c-utf8-locale.patch, so it seems this hasn't been upstream. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On 11/06/2018 03:05 AM, Kevin Kofler wrote: Zbigniew Jędrzejewski-Szmek wrote: The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. But there are probably many more packages where the setting is hidden in upstream build scripts. Build- and various other scripts. Is C.UTF-8 glibc upstream now, or is it still Fedora-specific? - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
> I'm with you in the sense that I too fail to see practical benefits of > modules so far. But e.g. the java-sig says it makes their life easier, > and it is their choice. The decision was made to proceed with > modularity in Fedora. Once that decision was made, we cannot forbid > packagers from making use of the new functionality. This further step > is only a natural consequence. Besides not seeing benefits of modules, while I do understand the rationale it's also something I disagree with. I feel like modules go against the First principle, I get a sense of bundling there too. But if anything, it feels like we are going full circle again with Snaps and Flatpaks and being pushed into an "innovation" corner by Canonical's agenda just because they have enough momentum to make everyone believe there is something wrong with the current packaging model. Snaps made sense for Ubuntu phones to deliver arbitrary apps from a store, not something suited to a general-purpose OS like Fedora. Shipping Snap and Flatpak as packages, sure, but shipping Snaps or Flatpaks, I don't see the point besides throwing away the progress made since the years of the so called RPM hell. We're already seeing examples of "portable packages" not keeping up with upstream releases (the last I heard of was nextcloud) and either a package is stable because upstream projects know how not to break carelessly or they really need to live at head because $REASONS (web browsers, probably things like nextcloud, etc). We have the same problem with lagging updates for "traditional" packaging so I have yet to be convinced that modules, Snaps or Flatpaks will solve that. I'm not knowledgeable enough about how Fedora manages parallel installation of streams but at the end of the day if I run "node" from the command line only one executable will be picked up from my $PATH. How can I run multiple streams then? Are the packages tweaked so that I run node8 or node10? How is that different from compat packages? I guess the answer is the bundling of dependencies inside both modules, I don't know for sure, I do not wish to dig further because I only have so much time to dedicate to Fedora. I'd rather go for OmniOS-like packaging guidelines for parallel installations and module switching basically be an update-alternatives to put things on the default $PATH or let users tweak their $*PATH when they need to target a given stream. (And yes, I know it doesn't sound friendly to non-tech-savvy users but how often do they need parallel installations of GUI apps?) I just hope modularity won't break mock as I know it. My $DAYJOB kindly allows me to work on Fedora and that makes me very productive when I target RHEL, otherwise I need to spin up VMs whenever I need to work on other platforms packaging (mostly because we ship apt-rpm as /usr/bin/apt). I happen to work on both an upstream of Fedora and many other systems, and on Fedora, so I know how hard it is to DoTheRightThing(tm) on both sides of the fence. To me this sounds like something that should be built on top of mock and made transparently available via fedpkg but I have neither the will nor the resources to look further than what I superficially read on the devel list (and when I rarely manage to catch up with all important threads). Dridi PS. examples taken off the top of my head, not pointing fingers here ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On 06. 11. 18 0:24, Zbigniew Jędrzejewski-Szmek wrote: Dear maintainers, I'm working again on implementing https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot. The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. This will be backwards and forwards compatible, in the sense that packages that use C.UTF-8 should build OK on older and newer Fedoras. Once that's done, I'll file the PRs to actually replace glibc-langpacks-all with glibc-minimal-langpacks in mock and koji. I'll do a mass update to use C.UTF-8 for the packages in the list that follows, next week. I'll do test builds locally, and I'll only push to dist-git if the local builds succeed. Let me know if you want your package to be excluded. Note for Python package owners: Since Python 3.7 upstream (and 3.6 in Fedora 26+ [0]) the locale is automatically coerced from C to C.utf-8 [1]. If you set LANG=en_US.utf-8 (or similar) for your Python 3 tests/docs/..., consider trying to remove the statement entirely before converting it to LANG=C.utf-8. The same applies if you already use LANG=C.utf-8. Zbyszek: I'm going to do this in ipython and python-django. [0] https://fedoraproject.org/wiki/Changes/python3_c.utf-8_locale [1] https://www.python.org/dev/peps/pep-0538/ -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Safe to remove yum?
Dne 04. 11. 18 v 14:08 Dominik 'Rathann' Mierzejewski napsal(a): > Unless you're building packages for EPEL locally using mock, > but then you can use mock --dnf. Or `mock --bootstrap-chroot`, which build in two stages. First install small root with DNF from e.g. F29 and then will use this DNF to install the final chroot. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Unretire recordmydesktop
Je lun, 2018-11-05 je 17:07 -0800, Samuel Sieb skribis: > > GNOME's inbuilt screen recorder does it fine. > > Does that use a Gnome shell-specific API or does Wayland have support > for that now? I believe the recording happens in the same process as the Wayland compositor. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Ursa Major (modules in buildroot) enablement
On Tue, Nov 06, 2018 at 01:54:54AM +0100, Kevin Kofler wrote: > Fabio Valentini wrote: > > I have to say, making core, non-leaf packages available as modules > > only sounds like a *terrible* idea to me. > > I don't want to have to deal with this uncooked mess if I just want to > > do standard packaging. > > +1. And, for that matter, that goes even for standard USING, as you implied > in the previous paragraph: > > > Because I don't even have the "-modular" repositories enabled on my > > f29 system, and I'll keep it that way. > > As you explained pretty well, it does not make sense to FORCE modules onto > users. Even less so if those packages are dependencies of other packages > outside of the module walled garden. Ursa Major is a crude hack to make that > broken setup work. This is not about forcing modules unto people. The drive comes from the other direction: packages want to be available only as modules, and this is a work-around to allow them to be used as build dependencies. So this change is driven by packagers who want to use modules for *their own packages*. I'm with you in the sense that I too fail to see practical benefits of modules so far. But e.g. the java-sig says it makes their life easier, and it is their choice. The decision was made to proceed with modularity in Fedora. Once that decision was made, we cannot forbid packagers from making use of the new functionality. This further step is only a natural consequence. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: mass-removal of LANG=anything-not-C.UTF-8 in packages
On Tue, Nov 06, 2018 at 02:05:27AM +0100, Kevin Kofler wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > The first step is to replace LC_ALL=en_US.UTF-8 with LC_ALL=C.UTF-8 > > (and similarly for LANG=, LC_CTYPE=, etc.) in all spec files. > > But there are probably many more packages where the setting is hidden in > upstream build scripts. That is possible, but I don't think it'll be that widespread. Gnarly upstream build scripts tend to be old, and not all systems always had en_US.UTF-8, so those script should do some autodetection of the available encodings. Anyway, we'll see. > > This will be backwards and forwards compatible, in the sense that packages > > that use C.UTF-8 should build OK on older and newer Fedoras. > > Older Fedoras only since F22 updates / F24 GA, see: > https://bugzilla.redhat.com/show_bug.cgi?id=902094 > > And what about EL? Neither version of EPEL seems to support C.UTF-8. So if somebody wants to support F30+ and EPEL (or F21-) from the same branch, they should probably add additional BR and use one of the more heavyweight locales. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
