Re: Should we retire the mailx package?
On Fri, 2023-12-08 at 13:18 -0500, Neal Gompa wrote:
> >
> > Can we retire the mailx package, and then update s-nail with:
> >
> > Provides: mailx = %{version}-%{release}
> >
> > (this would work fine because mailx is at 12.5 and s-nail forked
> > from
> > that and is now at 14.9, so upgrading would be straightforward)
> >
> > Should I submit a self-contained change proposal to do this?
>
> Yes, please!
I'm also +1 for this proposal. When I came back to Fedora after some
dalliance with Debian (a few years ago now), the difference in mailx
implementations caused me some heartburn. And then I found s-nail and
it was fine. But it was not clear (then) that they were compatible. I
was just looking for something simple to send something via SMTP from
the command line.
thanks,
--
Martin Jackson
--
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Packages in repo not signed: fedora-cisco-openh264 repository
On Thu, 2022-08-25 at 16:28 -0700, Kevin Fenzi wrote: > Everything should be back to working. Try a 'dnf --refresh...' or a > 'dnf clean all'. > Having just downloaded https://codecs.fedoraproject.org/openh264/36/x86_64/os/Packages/m/mozilla-openh264-2.3.0-1.fc36.x86_64.rpm I get: Name : mozilla-openh264 Version : 2.3.0 Release : 1.fc36 Architecture: x86_64 Install Date: (not installed) Group : Unspecified Size : 1153495 License : BSD Signature : (none) Source RPM : openh264-2.3.0-1.fc36.src.rpm Build Date : Mon 01 Aug 2022 10:47:57 AM CDT Build Host : buildvm-x86-06.iad2.fedoraproject.org Packager : Fedora Project Vendor : Fedora Project URL : https://www.openh264.org/ Bug URL : https://bugz.fedoraproject.org/openh264 Summary : H.264 codec support for Mozilla browsers Description : The mozilla-openh264 package contains a H.264 codec plugin for Mozilla browsers. Am I seeing something old on the CDN? Martin Jackson ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: go version unknown?
On Sun, 2022-06-19 at 00:02 +0300, Mark E. Fuller wrote: > Hi all, > > I have two Fedora machines that are essentially identically > configured > (to the best of my knowledge) - a daily use desktop and a laptop for > lugging around. > > Anyway, somehow the laptop is properly returning `go version` and > properly running a go debugger, etc. is VS Codium, but this is not > working on the desktop and I am instead getting `go version unknown > linux/amd64` instead of a proper version. > > I've tried reinstalling and and also completely removing and > reinstalling `golang`, but it's still the same. > > Any suggestions as to how to troubleshoot this? Check to see if you have gcc-go installed, which also provides a golang compiler (/usr/bin/go) but not equivalent to the regular golang toolset (golang-bin etc). vim-sytastic-go used to depend on that, I changed that in 34 or 35 (since I had a similar problem). Thanks, Marty ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
It happens that way in some places but not everywhere. I believe someone earlier mentioned how this whole discussion is security theater - some companies know this to be true and have fiscal policies that reflect that. I have direct experience working for a large organization where 3-5 years was more a guideline than a rule. Please be aware of that, is all I am asking here. 7 years is common and some assets I saw in use for well over 10. Hardware security is a factor but by no means the overriding one. Thanks, > On Apr 14, 2022, at 10:47 AM, Jóhann B. Guðmundsson > wrote: > > On 14.4.2022 14:07, Martin Jackson wrote: >> In many industrial and retail use cases, 10 years is the low end. 3-5 years >> is an accounting timeline (for depreciation) not necessarily the useful life >> of the asset. If the asset can be used after it’s done depreciating that is >> a bonus for the company using it. > > > HW security is one reason the companies are replacing their hw after 3-5 > years and in those cases the assets being deprecated are removed from the > premise. > > > JBG > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
In many industrial and retail use cases, 10 years is the low end. 3-5 years is an accounting timeline (for depreciation) not necessarily the useful life of the asset. If the asset can be used after it’s done depreciating that is a bonus for the company using it. Thanks, > On Apr 14, 2022, at 7:24 AM, Jóhann B. Guðmundsson wrote: > > On 14.4.2022 11:42, Kevin Kofler via devel wrote: >> Jóhann B. Guðmundsson wrote: >> >>> For example EU has regulation that requires vendors to have spare parts >>> available for 7–10 years after date of manufacturing so it makes sense >>> for the project to support hw no longer than a decade from the date of >>> it's manufacturing. ( which makes the oldest hw being support being >>> manufactured in 2012 ) and every process,workflows and decision being >>> bound by that. >> Lack of availability of original spare parts does not mean that the hardware >> suddenly magically stops working for everybody. >> > No but it does mean that they cant run indefinitely > > And there needs to be a number on this to adjust users expectation and 10 > years is a reasonable number from a business, parts and recycle/re-use > availability, > > What is unreasonable is to be expecting that it's supported indefinitely from > OS and or HW vendors. > > JBG > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Donate 1 minute of your time to test upgrades from F35 to F36
There is a workaround - I ran into this due to running the RPM version of steam. I removed the i686 lilv (which removed steam) and allowed me to complete the upgrade. After the upgrade completed I reinstalled steam. All my games etc were still there; the f36 version of the rpm does not require the 32 bit lilv and runs fine without it. Marty > On Apr 12, 2022, at 3:21 PM, Tom Seewald wrote: > > It's been ~1 month and I am still unable to upgrade to F36 due to the same > issue with lilv: > > Error: > Problem: lilv-0.24.10-4.fc35.i686 has inferior architecture > - lilv-0.24.10-4.fc35.x86_64 does not belong to a distupgrade repository > - problem with installed package lilv-0.24.10-4.fc35.i686 > > Are there plans to fix this and/or is there a known workaround? > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Java: The Death of Two SIGs
For what it's worth... I use the OpenJDK on Fedora and I'm very happy with it. I do not use or need eclipse, or as fast as I can tell, any of the other tooling (e.g. packaged gradle and other things). My main uses are playing games that depend on Java and are packaged and built outside the Fedora toolchain. (One is minecraft, the other is called Megamek, a simulator for the tabletop war game Classic BattleTech. minecraft...doesn't need to be built and megamek builds with gradle, which it knows how to download.) It hurts a bit to see posts like what were at the top of this thread - clearly Fabio and others have invested many hours into making a great experience for people, and I hate to see people feel that effort is wasted or that they're burning out. I would like to thank those who have contributed to the Fedora java stack. Maybe my case is unusual? It meets my needs and I expect it will continue to. Thanks, Marty On 9/27/21 09:03, PGNet Dev wrote: Many valid/interesting points being made. Most of them sound, reasonably, like developer-/maintainer-centric issues. Question: Is a primary goal of Fedora distro (JAVA sig, etc) to 'service' its (java app) users? If so, what's the current understanding of a user-driven ProductRequirements spec'n of JAVA apps 'round here? Who's included in "users"? Developers? End-users? etc. Perhaps I've missed it ... I know as a representative of my end-users I've got plenty of opinions about our JAVA env. Also as a representative of my org's JAVA devs. But as a developer/maintainer OF java/apps @ Fedora, not much at all; the "solid OpenJDK & Maven" approach is good enuf here. Mostly. And, if that^ is not a primary goal, then back to the discussion at hand. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Question on how to handle an upgrade case (vim-syntastic)
Thanks for the quick response! I've submitted a new build to rawhide that fixes this. Marty On 7/7/21 12:46 PM, Paweł Marciniak wrote: but do I also need to obsolete older versions of the vim-syntastic-rnc subpackage? Yes, you have to. See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Question on how to handle an upgrade case (vim-syntastic)
Hello, I use and like vim-syntastic, so I took it from the orphan list. There is an open bug on it that led to its retirement, that the rnc subpackage fails to install because rnv is no longer available. It's straightforward enough to stop building the -rnc subpackage for vim-syntastic, but do I also need to obsolete older versions of the vim-syntastic-rnc subpackage? Thanks, Marty ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: discord fedora .rpm and repo
As far as I know, there's no RPM. There is a flatpak on flathub that works really well. I have used the .deb download Discord provides and I actually find the flatpak a better experience, especially when Discord updates. Thanks, Marty On 6/11/21 12:54 PM, Cătălin George Feștilă wrote: Dear team Dear team. I would like to know if anyone took care of integrating the discord application in the Fedora distribution? Do we have a repo for this application? On the official website, I saw packet deb and tar. Thank you. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Use yescrypt as default hashing method for shadow passwords (System-Wide Change proposal)
Indeed you are not the only one. Even in large LDAP shops, there could be a local "break-glass" account, so managing hashes could still be a factor in those environments. One of the pain points of managing a large-scale Puppet infrastructure is supporting different hashes for different OS's. I've seen this done, and the result is...not always pretty. What does usage of yescrypt look like in the rest of the ecosystem? Are other major distros moving to it, or likely to? Marty On 6/8/21 9:13 AM, Ewoud Kohl van Wijngaarden wrote: On Tue, Jun 08, 2021 at 03:18:10PM +0200, Björn 'besser82' Esser wrote: Unfortunately there is no automatic way to update the hash from anything, but yescrypt, to yescrypt without knowing / entering the actual user password; in the future existing yescrypt hashes can be updated to new yescrypt hashes with stronger salts and/or cost parameters in-place without changing the password, and without user interaction. Has anyone some better idea? I'd advise against this. People can use a system like Puppet to sync password hashes between systems (as a cheap alternative to LDAP). If they use older distros that don't support it, it'll end up flapping where one system sets it to the older hashing and one to the newer. Or maybe I'm just the only person who does 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Ewoud Kohl van Wijngaarden
Welcome, ekohl and thanks for your contributions to Puppet and Foreman over the years! Marty On 6/6/21 11:11 AM, Ewoud Kohl van Wijngaarden wrote: Hello everyone, https://fedoraproject.org/wiki/Join_the_package_collection_maintainers recommended to introduce myself so here it is. My name is Ewoud Kohl van Wijngaarden (commonly known as ekohl) and I in my day job I work on the Foreman project[1]. Historically I've mostly been involved with the (Puppet-based) installer but over time I've also worked on most aspects of the project. Most notably I've also done quite a bit of the packaging[2]. Right now I want to become a Fedora maintainer to improve the state of the Puppet package and its dependencies. It's totally broken in Fedora 34 which is holding back my F33 -> F34 upgrade. I've also contributed patches upstream and have a good working relationship with Puppet (formerly Puppetlabs). As a start I've reviewed a PR to update Facter[3]. Something else I'd like to do is bring puppet-resource_api into Fedora. Right now it's only packaged for EPEL8[4] but we'd need it in Fedora too. Once that's all done, I'd like to update Puppet itself from 5.5.20 (incompatible with Ruby 3) to 7.7.0. I have a patch ready, but need to fix it to also package the bundled modules. So a concrete list of packages I'd be interested in keeping up to date: * https://src.fedoraproject.org/rpms/facter * https://src.fedoraproject.org/rpms/puppet * https://src.fedoraproject.org/rpms/rubygem-puppet-resource_api Regards, Ewoud Kohl van Wijngaarden [1]: https://theforeman.org/ [2]: https://github.com/theforeman/foreman-packaging [3]: https://src.fedoraproject.org/rpms/facter/pull-request/7 [4]: https://src.fedoraproject.org/rpms/rubygem-puppet-resource_api ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
So long for now...
Hello everyone, I've had some changes recently at my day job, and while I was hoping I would have more time to take care of my Fedora (and EPEL) packages, that seems to not be in the immediate future for me. I'm sorry to those who depend on these. I have orphaned: pipx git-up (git up may not really be needed, it's a leaf package and now that git can rebase and pull at the same it may be redundnant) nagios nrpe nagios-plugins I've also removed myself from dkms and nagios-plugins-check_updates. I am maintaining my FAS account, and I hope to return - but I'm kidding myself (and the users of these packages) if I represent that I'm really taking care of them. Thanks, Marty ___ 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: Giving away two of my package
pipsi: https://src.fedoraproject.org/rpms/pipsi A wrapper around virtualenv and pip which installs scripts provided by python packages into separate virtualenvs to shield them from your system and each other. The project https://github.com/mitsuhiko/pipsi/ is not maintained anymore upstream and a replacement is developed instead: https://github.com/pipxproject/pipx Nothing depends on it as well FYI, we have pipx in Fedora - I've been maintaining it since f32 was in development. Thanks, Marty ___ 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: Btrfs by default, the compression option
It feels to me like this might be a great area to slow down a bit and not try to do everything at once. Why don't we just make the simplest change for F33 - going to btrfs by default - and see how that goes, and consider the 'options' for F34 or later, rather than changing too much stuff at once Considering how controversial the change has been already,?? I think it would make a lot of sense to make one change at a time. If someone were to have a bad experience with the new default, it would be unclear whether that's because of the filesystem itself or because of the options we chose to deploy the filesystem with. If we make those changes separately, and the compression change goes badly, the changes would still be clearly independent. Changing one thing at a time is responsible change management in any case, especially when we're talking about defaults. Thanks, Marty ___ 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 future of legacy BIOS support in Fedora.
5-10 years? A better estimate would be 15-20 years. People aren't going to throw away perfectly fine systems and jump to new "cloud" platforms just because the OS they were using dropped BIOS support. They'll just stop updating, and likely move to something that is still supporting BIOS, if they don't write their own installer and just continue using Fedora, given that this is an entirely artificial limitation. While I completely hear you on the fact that people will often sweat assets for years longer than accounting schedules suggest they should, do you really think they're going to write custom installers??? I think it's far more likely that they would move to other distros more amenable to supporting the hardware they have. There are many distros that cater to this kind of market already, some by design and some by inclination.?? I don't think we want to drive them there. For what it's worth, I do not think that removing legacy BIOS support from Fedora is the right thing to do.?? I don't see significant benefit, and I see lots of potential harm. Thanks, Marty ___ 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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On 6/27/2020 7:32 PM, Gary Buhrmaster wrote: On Fri, Jun 26, 2020 at 2:46 PM Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/BtrfsByDefault A few claims (without justification): There is no "average" Fedora user. There is no "average" Fedora system. fedoraproject.org Indeed not. For what it's worth, I started with ZFS on Fedora, and got a little irritated that it wasn't ready for 32 when 32 was released. So on the advice of a friend, I migrated my ZFS volumes to BTRFS. They've been stable and reliable for me. I'm not doing anything crazy - just some subvolumes on single disks. ZFS was pretty heavy for that, and I didn't enjoy the complexity of managing dkms drivers and the odd edge cases it brings with it. Meanwhile, BTRFS does the things that I wanted to be able to do with ZFS. Nothing I couldn't do with LVM, but I wanted to try BTRFS since I'd heard good things about it and wanted to try it. It has worked well for me. Maybe in a perfect world, Oracle would change licensing for ZFS and it could be included in the kernel proper, but that seems unlikely at this point. We've got a bunch of people to support this proposal; it's straightforward to reverse if things go badly. It won't affect upgrades. It doesn't sound like the default layout is going to expose users to the known risks of BTRFS, and there will definitely be advantages. I'm in favor of making this change as well. Thanks, Marty ___ 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: RHEL 9 and modularity
On 6/19/20 7:46 AM, Daniel P. Berrangé wrote: On Fri, Jun 19, 2020 at 02:32:19PM +0200, Dominik 'Rathann' Mierzejewski wrote: On Friday, 19 June 2020 at 11:58, Daniel P. Berrangé wrote: [...] I can only see this being solvable if non-default modules streams are required to be built into a unique /opt prefix instead of /usr. Are you trying to re-invent the SCLs? I'm not trying to do anything myself, just pointing out that I believe modularity is broken by design because it leads to the need to have mutually incompatible versions of things installed at the same place at the same time. SCL was one concept that nicely avoided this problem, by giving users the ability to have multiple versions of a stream installed in parallel. Flatpaks and containers are alternative ways to let users deploy different versions of software without any clashing with the default package set provided by the distro. To be fair, while SCL's do solve this problem, they do so via subtle but really important changes to user behavior. In my $work environment we had lots of users that preferred to, for example, compile their own versions of Python rather than use the SCL version. While the restrictions SCL imposes make sense if you understand the underlying plumbing with linking and so on, many users (even power users) want /usr/bin/python in a shebang line. Modularity attempts to solve the user experience problem by effectively shifting this complexity to the admin side of the equation. So if the only thing you care about is getting /usr/bin/something (and you have other things that depend on conventional pathing for any of a host of reasons), you can get it. I agree in general that the problems that modularity solves haven't been worth the complexities in the ecosystem that they've generated. There are several other ways to install multiple pythons, and make them installable in parallel that are easier than SCL (python2 vs. python3 in /usr/bin). I use flatpaks on Fedora (Discord and okular), and I've really enjoyed the experience with them. I'm not sure how well that would translate to the server environment though, but that general approach seems to do a good job of preserving user experience while isolating potentially troublesome conflicts in a way that doesn't mess up the "base system". Marty ___ 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: Backports of fixes from F32 -> F31?
I've successfully moved from F31 to F32 = on 5 desktops (which I run KVM on), 2 laptops and another 11 VMs that run on the desktops (monitoring, mail IPA servers, firewalls). I run with rpmfusion and BTRFS a for my main storage machine nd f32 has been an absolute delight for me. But: I don't have any NVidia cards I run Fedora on. F31 was good; it had a few odd quirks in GNOME that f32 seems to have fixed. I usually get the itch to upgrade at least one canary machine around the beta time, once the add-on packages from places like rpmfusion and negativo17 get built. And then upgrade the rest between the lull between the GO announcement and actual publication. I don't mind dealing with occasional problems, but I haven't really had to do that this cycle at all. Very smooth, which is astounding considering the breadth of stuff that exists in Fedora and how fast it all moves. Marty On 4/30/20 8:30 AM, Alex Scheel wrote: - Original Message - From: "Josh Boyer" To: "Development discussions related to Fedora" Cc: "Florian Muellner" Sent: Wednesday, April 29, 2020 9:04:12 PM Subject: Re: Backports of fixes from F32 -> F31? Just a curious observation/question. Backports can often be time consuming and expensive. Is there something preventing you from upgrading to Fedora 32? I don't know about Alex, but in general, upgrading can also be time That's why I was asking Alex :) Sure :-) I have four systems in my house running Fedora. Two I've updated to F32 because I don't care if I lose personal time to messing around with F32 the day of the release. That's how I've been able to confirm it fixes this bug. A third is my router-desktop. Rarely used with a display and affects other people if I slow reboot it for upgrade + relabel. Bug isn't a problem there. But my work laptop on F31 is where I spend 80% of my time. Its the most... temperamental of the machines. F31 has been more stable than 29 or 30 before it. Until I know F32 is stable on the others, I'm not going to update it. I'll probably wait for the next company holiday or a weekend. --- And yeah, agreed. Backports are time consuming. But this is F31, not F30. There's at least another 6 months of support on this distro (technically...) and as referenced on that ticket, I'm not the only one that has hit it; there's about 10 people CC'd or replying saying they're affected. Plus -- all I'm looking for is a yes/no. Is that too much to ask a maintainer? :-) -- Alex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (anaconda also affected)
I would be happy to maintain it -and it looks like it needs an epel8 build. (FAS: mhjacks) Thanks, Marty On 4/27/20 2:13 PM, David Cantrell wrote: On Mon, Apr 27, 2020 at 12:39:38PM +0200, Miro Hrončok wrote: ckermit orphan 2 weeks ago I took ownership of this one and have fixed it in rawhide. If anyone really wants to own this one, just let me know. I have no problems turning it over to someone else, but if that's no one then I will just maintain it. I would like ckermit to still be available and usable in Fedora. Thanks, ___ 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: Looking for new maintainer: nagios, nagios-plugins, nrpe
I will take them - mhjacks in FAS. Any other potential comaintainers would also be welcome but I am a fan of the stack and would hate to see it disappear from the Fedora ecosystem. Thanks! > On Feb 24, 2020, at 4:21 PM, Stephen John Smoogen wrote: > > I have been maintaining nagios, nagios-plugins, and nrpe for a couple > of years but currently I do not have much time to put towards the > packages and won't until 2021 at my current rate. > > Last week, I emailed various people who have co-maintainer rights on > the package, but haven't had anyone reply. So I am asking on these > lists to see if another packager has time to maintain them and if not > I plan to orphan the packages in 2 weeks. > > -- > Stephen J Smoogen. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review Swap Request
Hello, I have two packages for a review swap - they should be fairly straightforward. python3-userpath is a python module for manipulating the $PATH variable for several shells; also it is a dependency of pipx : https://bugzilla.redhat.com/show_bug.cgi?id=1790232 pipx is a tool for installing various python scripts/commands (and their dependencies) in their own local virtualenvs. It is similar to pipsi (which is also in the archive; pipsi upstream recommends pipx instead - https://github.com/mitsuhiko/pipsi): https://bugzilla.redhat.com/show_bug.cgi?id=1790241 Thanks! Marty ___ 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
Does anyone know how to contact piotrp?
https://bugzilla.redhat.com/show_bug.cgi?id=1792440 Hello piotrp, I see that you maintain a lot of packages and I am looking for some new ones to start with. I have a PR in for nagios-plugins-check-updates and will happily adopt it or comaintain it if you’re still interested in it. Thanks! Sent from my iPhone___ 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: Let's talk about Fedora in the '20s!
On 1/14/20 10:20 AM, Matthew Miller wrote: On Sat, Jan 11, 2020 at 11:19:49AM -0600, Martin Jackson wrote: In this vein (as other people have commented on this thread), I think it would be great to give Fedora more visibility. Its absence as a supported image in Azure, for instance, is particularly noticeable, and the whole situation with WSL was regrettable. One of the reasons I've used Ubuntu/Debian in some of those situations is that they're there and relatively easy to consume. I've come to prefer Fedora because it has much better leading-edge stuff, and I think that's a huge benefit to the community that definitely serves a particular segment. For what it's worth, we do continue to work on these things. It's difficult because we really do need to make sure we have solid legal protection. I definitely understand the need to button down the legal stuff. But dang. What about WSL2 makes it easier, if that's something you can address here? Having a few people who talk about Fedora in the ecosystem publicly and often might be helpful too. There are a bunch of people who are directly and visibly connected with Ubuntu/Canonical that appear all the time on the Jupiter Broadcasting podcasts (I know Matt is also frequently interviewed but that's not quite the same thing). Having people talking about doing things with Fedora makes it "cool" and "buzzworthy", and I think that's of value. I'd love to have more people from across the project on all of these shows, definitely! Any suggestions on how we could make this easier for people who are not me? :) [...] One thing I would like to point out, as a sort of editorial comment - let's not let the areas we can improve in detract from the things Fedora is great at. We have a small-ish, but relatively vocal Fedora community where I work, among the sysadmins. I don't think Fedora users are quite as vocal, but the engineering in Fedora is solid. Sure there are problems occasionally, but the rate of change and the usability of Fedora as a daily driver and for some server workloads is pretty impressive. Thanks -- I appreciate the input! You're very welcome! Thanks, Marty ___ 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: Let's talk about Fedora in the '20s!
On 1/13/20 9:30 AM, Randy Barlow wrote: On Sat, 2020-01-11 at 11:19 -0600, Martin Jackson wrote: I don't know if things like pipx exist for other scripting languages, but do other people think that's worth exploring? (Currently pipx uses tox in what seems like a weird way, and we'd need to package userpath and tox-venv to make them work - I'm working on those and hope to submit the specs for review soon). This doesn't directly answer your question, but you can use virtualenvs for pretty much any language, not just Python. At my previous employer, before containers were so hot right now, we built virtualenvs for deployment on all our production systems. Our build system's output was a virtualenv that contained all the dependencies needed to run the application, our CI system tested that virtualenv, and if it passed, it was deployed into production. Many of our tools were Python, but we also used this for C++ and Java successfully. virtualenv is a great tool and gives you many of the packaging benefits of containers (but not the runtime benefits, though you could achieve that with other tools). Yes! Pipx is a mechanism that uses virtualenvs. I didn't realize that the concept generalized to Java and C++, but there's no reason it wouldn't. Interesting... Thanks, Marty ___ 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: Let's talk about Fedora in the '20s!
First, I'd like to see Fedora become more of an "operating system factory". There are a few things that seem a bit out of place, in terms of RH's messaging/endorsing of Fedora, and Fedora's role as an upstream for RHEL and an engine of moving the entire Linux community forward. I think this would be great. I think the ability to make it clear how to make customized fedora images would be very helpful. In this vein (as other people have commented on this thread), I think it would be great to give Fedora more visibility. Its absence as a supported image in Azure, for instance, is particularly noticeable, and the whole situation with WSL was regrettable. One of the reasons I've used Ubuntu/Debian in some of those situations is that they're there and relatively easy to consume. I've come to prefer Fedora because it has much better leading-edge stuff, and I think that's a huge benefit to the community that definitely serves a particular segment. The addition of the virtualbox guest additions to the installer was a great step, too - the big question, I think is to find ways to make it easy to consume fedora, and in some cases that means making images for Virtualbox, for cloud providers, maybe for CI providers too. Having a few people who talk about Fedora in the ecosystem publicly and often might be helpful too. There are a bunch of people who are directly and visibly connected with Ubuntu/Canonical that appear all the time on the Jupiter Broadcasting podcasts (I know Matt is also frequently interviewed but that's not quite the same thing). Having people talking about doing things with Fedora makes it "cool" and "buzzworthy", and I think that's of value. Second, we need to figure out how to work with language-native packaging formats and more directly with code that's distributed in git repos rather than as tarball releases. Some languages make this a lot easier than others. The curation that we do is valuable, and a lot of my interests involve curations of some of the really neat things I've found in the Python ecosystem. Python makes it *relatively* easy but it seems there will always be edge cases. That said, I love Fedora as a platform to explore the latest/greatest in curated scripting platforms and development. I'm working on packaging pipx for Fedora, which is a python tool to install venvs for applications; maybe including some meta-tooling like this in the distribution might help bridge some of the gaps (that is, it's infeasible to package all of pypi/CPAN/rubygems), in making it easy to consume those environments in Fedora, but giving up some of the advantages of packaging and curation. I understand people might find that unsuitable on both sides. I don't know if things like pipx exist for other scripting languages, but do other people think that's worth exploring? (Currently pipx uses tox in what seems like a weird way, and we'd need to package userpath and tox-venv to make them work - I'm working on those and hope to submit the specs for review soon). Third, we really need to continue to grow the project as more than coding and packaging. Maybe some of this falls into the publicity point that's part of the first point. I think there's a lot of value to having howto's, project documentation, guides and so on. I do think it's remarkable that with the pace that Fedora moves that techniques for approaching certain problems are still valid and useful. (I built a fault-tolerant firewall system with Fedora using a conntrackd, iptables, and keepalived with a guide from...f20 or so? I forget. Still works pretty well.) One thing I would like to point out, as a sort of editorial comment - let's not let the areas we can improve in detract from the things Fedora is great at. We have a small-ish, but relatively vocal Fedora community where I work, among the sysadmins. I don't think Fedora users are quite as vocal, but the engineering in Fedora is solid. Sure there are problems occasionally, but the rate of change and the usability of Fedora as a daily driver and for some server workloads is pretty impressive. Thanks, Marty ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Self Introduction
Hello! My name is Martin (or Marty) Jackson, and I've been a Fedora user for a few years.?? I've been to a couple of Red Hat Summits, and I've been very impressed with the Fedora people I've met there. I've been involved in Linux for over 20 years now, and I'm excited to be able to give something back to something that's given me so much over the years. I'm interested in packaging, getting started with a few small python utilities.?? I'll be submitting the review requests soon. Thanks, Marty ___ 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 Lifecycles: imagine longer-term possibilities
I think different people want different things from an LTS though. CentOS makes it hard to do e.g. Postgres 10 and Python3 which Ubuntu ships out of the box in 1804. Modularity seems like it will help in this regard. > On Nov 14, 2018, at 11:39 AM, Kevin Kofler wrote: > > Ralf Corsepius wrote: >> This would be my proposal, also. I would simply extend the release >> cycles to 1 year and to return to the roots. I.e. make a distro, and >> drop "rings" "modules" and "spins". > > Rings and modules should go away indeed, but spins should not! We have had > spins since Fedora 7! They are part of the success story of Fedora. > > What should be dropped, though, is the artificial distinction between > "editions" and "spins". Everything should be an equally-featured spin, and > the GNOME spin should be called GNOME spin. > >Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://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
Better fonts by default?
Hello everyone, and thanks to one and all for a remarkable distribution! With the coverage of the freeworld fontconfig enhancements, I wonder if some of the configuration settings currently implemented in https://github.com/silenc3r/fedora-better-fonts will be considered as defaults? Thanks, Marty ___ 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
[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC
I agree that it makes sense to associate EPIC releases with EL "point" or "y" releases. Some orgs (like us) download new content on timers, and while it's not wrong to say that people should read release notes and updates, there is currently a *lot* of content in EPEL etc to keep track of, and I think people find it really valuable to have a repo that makes the "don't overwrite/upgrade core" promise. I like the differentiation that is starting to develop in the CentOS ecosystem where there are some more "experimental" repos (like YUM4) that *do* overwrite, and say so explicitly. The ecosystem also has good tools to mix and match these repositories with core content (pulp/Satellite). Generally, we sync all of EPEL but only use the command-line bits; I'm unaware of any user reporting problems due to a GTK rebase in an EL minor release. IUS used to talk a bit about repo safety on their web page, does this need to be something more explicit for repos in general? Or something that might be reflected in metadata somehow? Thanks, Marty On 5/17/2018 10:01 PM, heelsl...@163.com wrote: good idea, EPIC release --> rhel release, centOS release keep the old RPMS when EPIC package upgrade. no compatibility issue any more. ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/QVRJ4RLWDSNZ3AQJMKJ2SIMNLEYSQPAR/ ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/TP7JWI3CRGDI6WPKGBENU5MOWDWTD445/
