Re: [HEADS-UP] GStreamer 1.24 landing in Fedora 40 soon
Fabio Valentini wrote: > We requested an exception to the Updates Policy, which was granted by > FESCo: https://pagure.io/fesco/issue/3204 Quoting from there: > Now the Multimedia SIG has been approached by GStreamer upstream > developers - why Fedora 40 is shipping without the latest version of > GStreamer (missing out on new features, big performance improvements for > GTK4-based video players, etc.). Uh, the last time an upstream has complained about "Fedora 40 is shipping without the latest version of" their software and "missing out on new features", it turned out that said "new features" mainly consisted of a dangerous backdoor (xz CVE-2024-3094)… Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FAS login not possible
On Mon, May 27, 2024 at 06:07:10PM GMT, Björn Persson wrote: > Kevin Fenzi wrote: > > I am unaware of any recent auth issues aside this kernel app one. > > Everything has been working great since we moved the ipsilon servers to > > f39 on march 27th. If there are, please let us know. > > Logging in to src.fedoraproject.org or pagure.io has been flaky to me in > recent weeks. I got Gateway Timeout a few minutes ago when logging in to > src.fedoraproject.org. I tried again and then it worked. Other times > I've gotten errors when logging in, but when I tried again I was logged > in without submitting the login form a second time. It sounds like perhaps a proxy is misbehaving... if there's any way you could enable debug console next time you login and see what proxy you were hitting when the timeout or issue happened that might be good info for us. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FAS login not possible
On Mon, May 27, 2024 at 10:45:34AM GMT, Marius Schwarz wrote: > Hi, > > ATM FAS Login is not possible. For you, to what? anything? > The ironic part is: you need to login to take part in the infrastructure > ticket about not able to login ;) > > https://pagure.io/fedora-infrastructure/issue/11949 > > You get this message: > > "400 - Bad Request - Invalid transaction id" > > when you try to login via the website or api. So, that ticket is about the kernel test app: https://kerneltest.fedoraproject.org/ It was changed a while back to use a new auth mode and the script for submitting authenticated results is not currently working. This is tracked in: https://pagure.io/kernel-tests/issue/50 The workarounds include just anonymous submitting, or logging into the web app with a browser and uploading the tests. Hopefully someone will look into this after the long weekend/holiday. So, is it just that you cannot submit kernel test results? Or can you not login to anything else? > Direct messages to "infrastruct...@lists.fedoraproject.org" are also not > possible, you need to be on the list to do that. Yes. If you cannot auth to update/file a ticket: https://docs.fedoraproject.org/en-US/infra/day_to_day_fedora/#_emergencyauthentication_issues I am unaware of any recent auth issues aside this kernel app one. Everything has been working great since we moved the ipsilon servers to f39 on march 27th. If there are, please let us know. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intention to unretire and rename pyftpdlib
Sandro wrote: > I was probably overthinking this. In practice it will turn out to be a > new package submission indeed. Moreover, the last remaining active > branch of the retired package (F38) is now EOL. > > I've submitted the review [1] without any Obsoletes. Since we support upgrades from Fedora n to n+2, there SHOULD be Obsoletes in place until at least the F40 EOL. I would recommend just keeping the Obsoletes forever. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changing desktop file name in a stable release
Julian Sikorski wrote: > are there guidelines advising how to handle upstream desktop filename > change in a stable fedora release? For gnumeric I just followed upstream > [1], which led to a bug report [2]. Now I am facing similar situation > with pavucontrol [3]. Should I rename the desktop file to what it used > to be, or just forgo the updates altogether? Thanks in advance. The gnumeric bug report was about the icon .png getting renamed, not the .desktop file. I think it is OK if the .desktop file gets renamed during a release, but some people are probably going to complain there too. I guess that is what we have CLOSED NOTABUG for. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Monday's FESCo Meeting (2024-05-20)
On Tue, May 21, 2024 at 10:59:12PM GMT, Miro Hrončok wrote: > On 20. 05. 24 22:59, Stephen Gallagher wrote: > > * AGREED: FESCo will permit the inclusion of binaries provided by > > upstream Python and FFI exclusively for the purposes of loading the > > installer on MacOS since we have no reasonable way to cross-compile > > for that platform at this time. (+5, 0, -4) (@sgallagh:fedora.im, > > 20:01:08) > > I am a tad sad that this was approved by FESCo without being first discussed > with the wider community. yeah. :( kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Monday's FESCo Meeting (2024-05-20)
On Tue, May 21, 2024 at 06:44:43PM GMT, Ian McInerney via devel wrote: > Is there a full log somewhere? I don't see it on > https://meetbot.fedoraproject.org/, and the usual links at the top of the > summary email aren't there this time. Yes, this meeting fell prey to the 'multi line' bug in meetings. ie, if you pass it a bunch of commands in one message, it treats it as one command with everything else as the argument. ;( In this case the meeting 'name' surpassed the allowed length for a file, so when it tried to write them it... couldn't. I put the logs into place now, but meetbot app hasn't picked up on them yet. ;( In the mean time: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-20/fesco.2024-05-20-19.00.log.html https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-20/fesco.2024-05-20-19.00.html https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-20/fesco.2024-05-20-19.00.log.txt https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-05-20/fesco.2024-05-20-19.00.txt kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: New Fedora Planet
On Fri, May 17, 2024 at 08:42:12AM GMT, Daniel P. Berrangé wrote: > On Thu, May 16, 2024 at 05:16:17PM -0300, Pedro Moura wrote: > > Hi everyone, > > > > We are moving Fedora Planet from the old (python2) software running on > > fedorapeople.org to a new application that is running in OpenShift. > > This new application uses information from the Fedora Account System to > > find blogs, so please make sure your account is updated. > > > > You can see the new planet at: https://planet.apps.ocp.fedoraproject.org/ > > > > To add blog posts in Fedora Planet you basically need to update RSS URL > > field at https://accounts.fedoraproject.org/ > > IIUC, you're indicating that the existing planet feed addresses will not > be automatically migrated, and thus everyone has to update their profile, > even if already on the Fedora Planet today ? Yes. We considered trying to migrate .planet files but: * There's a ton of invalid ones that don't resolve or are 404, or have 0 entries in them, or go to things that aren't rss feeds. * There's a ton of them that were setup by people years ago that are no longer active in the fedora community, so there's no fedora tagged posts, but who knows if they intend to add some, or never will. * There's a ton of them that are http and a simple http/https substitution doesn't work, so we don't know where the https version is or if it exists. Perhaps we could look at posters for the last say 6months and mail them directly to check and update? That would at least get somewhat active folks... On Fri, May 17, 2024 at 11:53:34AM GMT, Miroslav Suchý wrote: > Dne 16. 05. 24 v 10:16 odp. Pedro Moura napsal(a): > > To add blog posts in Fedora Planet you basically need to update RSS URL > > field at https://accounts.fedoraproject.org/ > > How can I add more feeds? Under my account I had feeds to two Packit blogs, > one ABRT and my personal. Hum, good question. I'll ask Pedro about this. On Fri, May 17, 2024 at 12:49:12PM GMT, Kamil Paral wrote: > > On this new URL, the sub-planets are currently broken. Also, how can I add > an RSS feed to a particular sub-planet? (note that that RSS feed is > different from the RSS feed for the main planet). Yes, and we should have noted this in the announcement, but we were going to sunset the 'sub-planets'. They didn't seem to be very active/used. Is that not the case? On Fri, May 17, 2024 at 02:51:35PM GMT, Kevin Kofler via devel wrote: > > Which means that basically all blogs are going to vanish from Fedora Planet > unless people re-add them manually. Yes. > There are 809 blogs on the old Planet Fedora, the new one currently has 30 > (should be at least 31 soon when it picks up my RSS URL that I have just > added to accounts.fedoraproject.org). That is less than 4%. More than 96% of > the blogs will be gone. But of those 809, a very large majority are invalid, inactive or broken in some way. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Debugging fun (wrt C modernization change)
Michael J Gruber wrote: >> %patchlist and %auto* should just go away, or at least banned from Fedora >> by a git hook rejecting such specfiles. > > We also have unnumbered patch source definition lines, don't we? IIRC, unnumbered Source: or Patch: just defaults to Source0: resp. Patch0:. But it should not be used. Use Source0/Patch0 instead. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: New Fedora Planet
Pedro Moura wrote:
> To add blog posts in Fedora Planet you basically need to update RSS URL
> field at https://accounts.fedoraproject.org/
Which means that basically all blogs are going to vanish from Fedora Planet
unless people re-add them manually.
There are 809 blogs on the old Planet Fedora, the new one currently has 30
(should be at least 31 soon when it picks up my RSS URL that I have just
added to accounts.fedoraproject.org). That is less than 4%. More than 96% of
the blogs will be gone.
This is not helpful.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers removed from the packager group
On Thu, May 16, 2024 at 05:27:31PM GMT, Tim Orling wrote: > On Thu, May 16, 2024 at 5:02 PM Kevin Fenzi wrote: > > > Hi all, > > > > Today, 2024-05-16, we have removed inactive packagers > > from the packager group. > > > > This is in accordance with the FESCo policy on inactive packagers: > > https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ > > > I suspect I am not alone in asking “What is the list of inactive packagers > that this impacted?” > > The list of affected packages is helpful; the list of inactive packagers > would have been extra helpful. I suppose it was earlier in the thread? Its in the ticket: ...snip... > > > > More details available in > > https://pagure.io/fedora-infrastructure/issue/11901 kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Inactive packagers removed from the packager group
Hi all, Today, 2024-05-16, we have removed inactive packagers from the packager group. This is in accordance with the FESCo policy on inactive packagers: https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ If the removed user is 'main admin' for a package, this package will be orphaned. If there are co-maintainers for the package, one of them should take the role of 'main admin', by clicking "✋ Take" on `https://src.fedoraproject.org/rpms/`". Otherwise any packager may take the package while it's orphaned. After 6 weeks, the package will be retired. After another 8 weeks, a new review is needed to unretire it. see https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/ for more details. Note that removed packagers will currently still appear in packager groups on src.fedoraproject.org. We are working on a way to refresh that information. More details available in https://pagure.io/fedora-infrastructure/issue/11901 Packages that have been orphaned are: flatpaks/ardour5 flatpaks/dosbox flatpaks/filezilla flatpaks/gnome-books flatpaks/gnome-calendar flatpaks/gnome-maps flatpaks/gnome-music flatpaks/gnome-photos flatpaks/hydrapaper flatpaks/hydrogen flatpaks/jumpnbump flatpaks/prusa-slicer flatpaks/qtractor flatpaks/supertux flatpaks/xonotic modules/fleet-commander modules/pg-semver rpms/3Depict rpms/ansible-collection-community-rabbitmq rpms/apache-commons-net rpms/balsa rpms/BitchX rpms/bolt rpms/brightnessctl rpms/cgdb rpms/collectd rpms/connect-proxy rpms/container-exception-logger rpms/cutecw rpms/daggy rpms/dia-gnomeDIAicons rpms/dmidecode rpms/dnssec-nodes rpms/dnssec-system-tray rpms/dnssec-tools rpms/feedbackd rpms/fleet-commander-admin rpms/fleet-commander-client rpms/freeipa-desktop-profile rpms/gamemode rpms/gedit-latex rpms/gedit-plugins rpms/git-crypt rpms/gitg rpms/givaro rpms/gmrun rpms/gnome-shell-extension-gamemode rpms/gofer rpms/golang-github-client9-gospell rpms/golang-github-mitchellh-ps rpms/golang-github-remeh-sizedwaitgroup rpms/golang-github-xrash-smetrics rpms/gtranslator rpms/gtypist rpms/icewm rpms/inih rpms/kanotf-fonts rpms/koji-osbuild rpms/laf-plugin rpms/levien-museum-fonts rpms/libesmtp rpms/libgit2-glib rpms/libinjection rpms/libitl rpms/libvarlink rpms/linux-system-roles rpms/logserial rpms/lookup rpms/mathgl rpms/mmv rpms/mobile-broadband-provider-info rpms/mysql-mmm rpms/mythes-eo rpms/nik4 rpms/nodejs-sprintf rpms/nodejs-strip-json-comments rpms/numactl rpms/nuntius rpms/oc-inject rpms/oomd rpms/osbuild rpms/pcmciautils rpms/pdns-recursor rpms/perl-Crypt-OpenSSL-AES rpms/perl-Crypt-OpenSSL-Bignum rpms/perl-Crypt-OpenSSL-DSA rpms/perl-Crypt-OpenSSL-PKCS10 rpms/perl-Crypt-OpenSSL-Random rpms/perl-Crypt-OpenSSL-RSA rpms/perl-Crypt-OpenSSL-X509 rpms/perl-Flickr-API rpms/perl-Flickr-Upload rpms/perl-Getopt-GUI-Long rpms/perl-Net-DNS-SEC rpms/perl-QWizard rpms/pidgin-guifications rpms/pisg rpms/Pound rpms/ppl rpms/pure-ftpd rpms/python-astor rpms/python-boolean.py rpms/python-ephyviewer rpms/python-fadvise rpms/python-flask-cache rpms/python-git-changelog rpms/python-glue rpms/python-glymur rpms/python-license-expression rpms/python-neatdend rpms/python-pooch rpms/python-pretend rpms/python-pyABF rpms/python-pyzabbix rpms/python-requre rpms/python-rfc3987 rpms/python-satyr rpms/python-suds rpms/python-tzlocal rpms/python-varlink rpms/python-waitress rpms/python-whitenoise rpms/python-zbase32 rpms/ren rpms/reportd rpms/reuse rpms/rubygem-daemons rpms/rust-xkbcommon rpms/sat4j rpms/satyr rpms/secvarctl rpms/shybrid rpms/spice-html5 rpms/springlobby rpms/squeekboard rpms/ssmtp rpms/statsd rpms/sugar-colordeducto rpms/sugar-story rpms/sugar-xoeditor rpms/tcpxtract rpms/termy-server rpms/will-crash rpms/wofi rpms/wp-cli rpms/xarchiver rpms/xfburn rpms/xmlcopyeditor rpms/yank signature.asc Description: PGP 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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
Inactive packagers removed from the packager group
Hi all, Today, 2024-05-16, we have removed inactive packagers from the packager group. This is in accordance with the FESCo policy on inactive packagers: https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ If the removed user is 'main admin' for a package, this package will be orphaned. If there are co-maintainers for the package, one of them should take the role of 'main admin', by clicking "✋ Take" on `https://src.fedoraproject.org/rpms/`". Otherwise any packager may take the package while it's orphaned. After 6 weeks, the package will be retired. After another 8 weeks, a new review is needed to unretire it. see https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/ for more details. Note that removed packagers will currently still appear in packager groups on src.fedoraproject.org. We are working on a way to refresh that information. More details available in https://pagure.io/fedora-infrastructure/issue/11901 Packages that have been orphaned are: flatpaks/ardour5 flatpaks/dosbox flatpaks/filezilla flatpaks/gnome-books flatpaks/gnome-calendar flatpaks/gnome-maps flatpaks/gnome-music flatpaks/gnome-photos flatpaks/hydrapaper flatpaks/hydrogen flatpaks/jumpnbump flatpaks/prusa-slicer flatpaks/qtractor flatpaks/supertux flatpaks/xonotic modules/fleet-commander modules/pg-semver rpms/3Depict rpms/ansible-collection-community-rabbitmq rpms/apache-commons-net rpms/balsa rpms/BitchX rpms/bolt rpms/brightnessctl rpms/cgdb rpms/collectd rpms/connect-proxy rpms/container-exception-logger rpms/cutecw rpms/daggy rpms/dia-gnomeDIAicons rpms/dmidecode rpms/dnssec-nodes rpms/dnssec-system-tray rpms/dnssec-tools rpms/feedbackd rpms/fleet-commander-admin rpms/fleet-commander-client rpms/freeipa-desktop-profile rpms/gamemode rpms/gedit-latex rpms/gedit-plugins rpms/git-crypt rpms/gitg rpms/givaro rpms/gmrun rpms/gnome-shell-extension-gamemode rpms/gofer rpms/golang-github-client9-gospell rpms/golang-github-mitchellh-ps rpms/golang-github-remeh-sizedwaitgroup rpms/golang-github-xrash-smetrics rpms/gtranslator rpms/gtypist rpms/icewm rpms/inih rpms/kanotf-fonts rpms/koji-osbuild rpms/laf-plugin rpms/levien-museum-fonts rpms/libesmtp rpms/libgit2-glib rpms/libinjection rpms/libitl rpms/libvarlink rpms/linux-system-roles rpms/logserial rpms/lookup rpms/mathgl rpms/mmv rpms/mobile-broadband-provider-info rpms/mysql-mmm rpms/mythes-eo rpms/nik4 rpms/nodejs-sprintf rpms/nodejs-strip-json-comments rpms/numactl rpms/nuntius rpms/oc-inject rpms/oomd rpms/osbuild rpms/pcmciautils rpms/pdns-recursor rpms/perl-Crypt-OpenSSL-AES rpms/perl-Crypt-OpenSSL-Bignum rpms/perl-Crypt-OpenSSL-DSA rpms/perl-Crypt-OpenSSL-PKCS10 rpms/perl-Crypt-OpenSSL-Random rpms/perl-Crypt-OpenSSL-RSA rpms/perl-Crypt-OpenSSL-X509 rpms/perl-Flickr-API rpms/perl-Flickr-Upload rpms/perl-Getopt-GUI-Long rpms/perl-Net-DNS-SEC rpms/perl-QWizard rpms/pidgin-guifications rpms/pisg rpms/Pound rpms/ppl rpms/pure-ftpd rpms/python-astor rpms/python-boolean.py rpms/python-ephyviewer rpms/python-fadvise rpms/python-flask-cache rpms/python-git-changelog rpms/python-glue rpms/python-glymur rpms/python-license-expression rpms/python-neatdend rpms/python-pooch rpms/python-pretend rpms/python-pyABF rpms/python-pyzabbix rpms/python-requre rpms/python-rfc3987 rpms/python-satyr rpms/python-suds rpms/python-tzlocal rpms/python-varlink rpms/python-waitress rpms/python-whitenoise rpms/python-zbase32 rpms/ren rpms/reportd rpms/reuse rpms/rubygem-daemons rpms/rust-xkbcommon rpms/sat4j rpms/satyr rpms/secvarctl rpms/shybrid rpms/spice-html5 rpms/springlobby rpms/squeekboard rpms/ssmtp rpms/statsd rpms/sugar-colordeducto rpms/sugar-story rpms/sugar-xoeditor rpms/tcpxtract rpms/termy-server rpms/will-crash rpms/wofi rpms/wp-cli rpms/xarchiver rpms/xfburn rpms/xmlcopyeditor rpms/yank signature.asc Description: PGP signature -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Missing util-linux-core in fedora:40 container image
On Thu, May 16, 2024 at 12:43:42PM GMT, Manabu Ori wrote: > Hi, > > I found fedora:40 container image does not contain util-linux-core. > Is it intentional? I don't think so... > I'd like some commands (findmnt in my case) included in the base image... > > > ## fedora:39 container image has findmnt > > $ podman run --rm quay.io/fedora/fedora:39 sh -c 'type findmnt; rpm -q > util-linux-core' > findmnt is /usr/bin/findmnt > util-linux-core-2.39.4-1.fc39.x86_64 > > > ## fedora:40 container image does not have findmnt > > $ podman run --rm quay.io/fedora/fedora:40 sh -c 'type findmnt; rpm -q > util-linux-core' > sh: line 1: type: findmnt: not found > package util-linux-core is not installed It crept in when we converted from kickstarts to kiwi definitions, we then fixed it in rawhide, but not f40 (because it was so close to release? or we forgot?). Anyhow, I have cherry picked the commit and pushed it to f40, so it should be active in the next one that syncs out. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rich deps result in packages being uninstalled from buildroot
Neal Gompa wrote: > I have the question of why is dnf5 running as if "--allow-erasing" is > always passed to it? Older versions of DNF explicitly didn't do that > because we get weird behaviors like this. Without --allow-erasing (which was actually passed explicitly, as Petr Pisar pointed out), the intended resolution: > a) install cargo-rpm-macros, python3, python3-libs, add-determinism, and > remove add-determinism-nopython could also not possibly work because: > remove add-determinism-nopython Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Debugging fun (wrt C modernization change)
Panu Matilainen wrote: > Patch and source numbers start from zero, that goes for automatically > numbered patches too. So there's an off by one in the application, and > the latter %autopatch which is supposed to apply patches >= 2 simply has > nothing to do, and falls through silently. That's a bug of course in > itself, filed now: > https://github.com/rpm-software-management/rpm/issues/3093 And then they say the automagic is a good idea because it prevents people from accidentally forgetting to apply a patch, LOL. %patchlist and %auto* should just go away, or at least banned from Fedora by a git hook rejecting such specfiles. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When is Fedora 38 going EOL?
On Tue, May 14, 2024 at 06:11:15PM GMT, Sérgio Basto wrote: > On Tue, 2024-05-14 at 14:53 +0200, Miro Hrončok wrote: > > Hi, > > > > When is Fedora 38 going EOL? > > > > https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html say > > s today > > https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html say > > next week > > > > Which one is correct? > > Bodhi says: > > The following releases are appoaching End-Of-Life: > > Fedora 38 Containers will go EOL on 2024-05-21 > Fedora 38 Flatpaks will go EOL on 2024-05-21 > Fedora 38 Modular will go EOL on 2024-05-21 > Fedora 38 will go EOL on 2024-05-21 > > Consider that before submitting any update for those release Yes, it should be next week, IMHO. At least release engineering have been planning for it being next week. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: soname bump for hiredis
On Wed, May 01, 2024 at 02:15:20PM GMT, Kevin Fenzi wrote: > Hey folks. > > hiredis 1.2.0 has been out a long while now, and with some prodding I am > finally looking at updating rawhide to it. > > A interested user ran a mass prebuild: > https://copr.fedorainfracloud.org/coprs/v02460/hiredis-1.2.0/packages/ > > Everything rebuilt fine. > > ccache > collectd > coturn > gawk-redis > gearmand > gloo > hiredis > jimtcl > minetest > minetestmapper > opensips > php-phpiredis > python-hiredis > rsyslog > rubygem-hiredis > suricata > syslog-ng > yaz > > I've created f41-build-side-88835 with the new build. > Anything not rebuild by next week I'll rebuild and submit the update > then barring problems. > > Let me know if I missed anything. Sorry for the delay here. ;( I rebuilt all the remaining packages and submitted: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d3fa7fe328 kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Adam Williamson wrote:
> The shortest syntax is just to use Patch: foo.patch , and %autosetup .
That is not a syntax to apply a patch, it is an automagic that blindly
applies all patches in numeric order. Cannot reorder patches, cannot apply
them conditionally (e.g., based on the 0%{?fedora} version), cannot specify
a -b backup file extension for each patch. So it is not a fair comparison.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Florian Festi wrote: > We have an even easier solution for you: You can just run the script at > [3] with -n on your own spec files to get them changed to the %patch N > variant. If you do that right now they will not break nor will they be > touched during the mass change. > > As I said the %patch -PN syntax is the one with the best compatibility - > reaching back into the dark ages. I am not advocating for people to use > it. Anyone is free and encouraged to move to something more modern - > before or after the change. We are using this variant so spec files > continue to work on older distributions and the chance of breakage is > minimized. This way packagers that don't care don't have to. What I do not understand is why RPM is discontinuing the most commonly used syntax and breaking hundreds of specfiles. This also leaves us with only the choice between a backwards-incompatible syntax (added only in RPM 4.18) and an ugly and redundantly verbose syntax (the -P syntax). And even the modern syntax is 1 character (space) longer for every patch. The shortest syntax was the one being dropped. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
3 outages next week (2024-05-13,14,15)
We have 3 outages scheduled next week for Monday, Tuesday and wed: OpenShift upgrade We will be upgrading our production OpenShift cluster that runs many of our applications. Normally, this would just be a 0 downtime event, but in this case we are switching networking models, so we need to completely reboot all the nodes, causing some applications to be unavailable for short time periods. For more information and updates on the progress of this outage, see ticket #11912 https://pagure.io/fedora-infrastructure/issue/11912 Anticipated Start: May 13 2024, 08:00 UTC Anticipated End: May 13 2024, 10:00 UTC Database Migrations We will be migrating a number of our database servers to RHEL9, newer versions of database software and more resources. During the migration services that use these databases may be offline completely. The small servers ( db-fas01 and db03 ) should move and have service restored sooner than the two larger hosts. For more information and updates on the progress of this outage, see ticket #11913 https://pagure.io/fedora-infrastructure/issue/11913 Anticipated Start: May 14 2024, 20:00 UTC Anticipated End: May 15 2024, 00:00 UTC Server Updates/Reboots We will be applying updates to all our servers and rebooting into newer kernels. Services will be up or down during the outage window. For more information and updates on the progress of this outage, see ticket #11914 https://pagure.io/fedora-infrastructure/issue/11914 Anticipated Start: May 15 2024, 21:00 UTC Anticipated End: May 16 2024, 02:00 UTC As always, follow https://www.fedorastatus.org and/or the above tickets for up to date outage information. kevin signature.asc Description: PGP 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ 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
3 outages next week (2024-05-13,14,15)
We have 3 outages scheduled next week for Monday, Tuesday and wed: OpenShift upgrade We will be upgrading our production OpenShift cluster that runs many of our applications. Normally, this would just be a 0 downtime event, but in this case we are switching networking models, so we need to completely reboot all the nodes, causing some applications to be unavailable for short time periods. For more information and updates on the progress of this outage, see ticket #11912 https://pagure.io/fedora-infrastructure/issue/11912 Anticipated Start: May 13 2024, 08:00 UTC Anticipated End: May 13 2024, 10:00 UTC Database Migrations We will be migrating a number of our database servers to RHEL9, newer versions of database software and more resources. During the migration services that use these databases may be offline completely. The small servers ( db-fas01 and db03 ) should move and have service restored sooner than the two larger hosts. For more information and updates on the progress of this outage, see ticket #11913 https://pagure.io/fedora-infrastructure/issue/11913 Anticipated Start: May 14 2024, 20:00 UTC Anticipated End: May 15 2024, 00:00 UTC Server Updates/Reboots We will be applying updates to all our servers and rebooting into newer kernels. Services will be up or down during the outage window. For more information and updates on the progress of this outage, see ticket #11914 https://pagure.io/fedora-infrastructure/issue/11914 Anticipated Start: May 15 2024, 21:00 UTC Anticipated End: May 16 2024, 02:00 UTC As always, follow https://www.fedorastatus.org and/or the above tickets for up to date outage information. kevin signature.asc Description: PGP signature -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN
Neal Gompa wrote: > On Mon, May 6, 2024 at 8:17 AM Leon Fauster via devel > wrote: >> >> Am 06.05.24 um 13:56 schrieb Florian Festi: >> > Hi everyone, >> > >> > RPM has deprecated the %patchN syntax in favor of %patch -PN where N is >> > the patch number for a year now. See the RPM documentation for more >> > information [1]. In current RPM versions, this syntax only emits a >> > deprecation warning, but support for this syntax has been removed >> > completely in the upcoming RPM 4.20 release. As it will be added in >> > Fedora soon [2] it is time to switch over to the new syntax now. >> > >> > There are around 1800 packages that still use the old syntax. Later >> > this week/next week, we will run this script [3] over the affected >> > packages >> > [4][5] to update them to the modern patch syntax. For example, the >> > script will change: >> > >> > %patch0 -p1 → %patch -P0 -p1 >> > %patch0005 -p2 → %patch -P0005 -p2 >> > >> >> >> Is this supported by rpm in RHEL8/9 (EPEL8/9 builds)? >> > > Yes. It's been supported for a very long time. %patch -P is already documented in the 1997 First Edition of Maximum RPM. Here is the link in the 2000 online edition: https://ftp.osuosl.org/pub/rpm/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-WHICH-PATCH-TAG Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Ownership request for retired packages libtsm and kmscon
On Tue, May 07, 2024 at 08:59:26AM GMT, José Relvas via devel wrote: > Hey folks, > > `libtsm` was retired because it was orphaned. `kmscon` was retired because it > relied on this package. > > I'm currently not in the "packagers" group, but I'm interested in taking > ownership of these packages and re-adding them to Fedora if I get sponsored. > > Upstream has ceased development for both `libtsm` and `kmscon`, however, > they've been forked and continue to be well maintained: > > - `libtsm`: https://github.com/Aetf/libtsm > - `kmscon`: https://github.com/Aetf/kmscon > > Among other improvements, the build system has been modernized (meson instead > of GNU autotools!) and dependencies have been cleaned up. Packaging these > forks should be significantly easier compared to the abandoned upstream. > > I've done some testing locally and ran into no major issues, so I believe I'm > capable of handling packaging. I've experimented with sending a few PRs to > Fedora packages and I feel comfortable with RPM packaging now. > > Please let me know if this is possible :) I'd suggest submitting them for review. Since they are using a different upstream and the buildsystem and other things have changed anyhow, a review is probibly a good idea. Then, as part of that you can find a sponsor... https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Unresponsive packagers: suanand and vponcova
On Tue, May 07, 2024 at 02:15:15PM GMT, Jens-Ulrik Petersen wrote: > I think for ex-redhatters it may be more appropriate to make a new bz > account for their new email address? Yes. I don't think the system will allow you to change emails for a @redhat.com account. Just making the new account with the same email as your fas account (or your bugzilla account field setting) should do the trick. kevin -- > > Jens > > On Tue, May 7, 2024 at 2:11 PM Emmanuel Seyman wrote: > > > * Sundeep Anand [07/05/2024 05:50] : > > > > > > (not sure how to update email at bugzilla.redhat.com) > > > > Go to https://bugzilla.redhat.com/userprefs.cgi?tab=account and fill in > > the 'New email address' field. > -- > ___ > 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 signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
On Thu, May 02, 2024 at 01:28:19PM GMT, Adam Williamson wrote: > On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel wrote: > > On 5/2/24 14:34, Gary Buhrmaster wrote: > > > While I follow the philosophy of updating > > > regularly, there are likely some who install Fnn, and > > > never update, and then would expect an update to > > > Fnn+2 to work without issue(s). > > > -- > > > > The CLI update strongly suggests doing 'dnf update --refresh' before > > system-upgrade. It doesn't require it though. > > > > I always thought it's an odd workflow; why doesn't it just force it? > > While it might take a long while to complete on a stale system, it's > > recommended anyway, isn't it? > > I would actually hugely prefer we amend that to say `dnf --refresh > offline-upgrade download; dnf offline-upgrade reboot` or so. It's a > footgun as it stands. Perhaps the dnf5 version could be just: dnf offline-upgrade (and it automatically does --refresh and it downloads and then says "packages downloaded, ok to reboot into the upgrade now? y/n)" ? And if you pass it 'download' or 'reboot' it only does those steps? kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: calendar.fp.o pointing to obsolete IRC for meetings
On Sat, May 04, 2024 at 11:32:21AM GMT, Dominik Wombacher wrote: > On 5/3/24 8:00 PM, Kevin Fenzi wrote: > > > > So, help would definitely be welcome fixing the matrix/irc issues in the > > code, and then we could look at mass updating it. > > > > I briefly looked into it, can be an easy fix. I put a comment into the > open issue for matrix support in fedocal: > https://pagure.io/fedocal/issue/213 > I suggest to label it as easyfix/good-first-issue and maybe someone is > interested and has the time to work on it :) ok. I don't know if anyone is really watching things there, but I will try and find someone to do so. ;) > > Or perhaps we should be looking at retiring fedocal, but would probibly > > want an open source alternative we could use or deploy. > > Are there other use-cases that are not covered by fedocal but urgently > required? Not that I know of. > If the main pain points are minor issue like the matrix url support in > the meeting location, I would suggest to fix the current code. > That's then still much less time consuming compared to replacing it with > something else. Agreed. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: calendar.fp.o pointing to obsolete IRC for meetings
On Fri, May 03, 2024 at 12:24:57PM GMT, Stephen Gallagher wrote: > On Fri, May 3, 2024 at 5:18 AM Daniel P. Berrangé wrote: > > > > Somehow the news that various (some ? all? ) Fedora meetings have > > moved off IRC, to Matrix passed me by. This is not helped by the > > official project meeting calendar: > > > >https://calendar.fedoraproject.org/ > > > > which continues to mislead people who want to attend, by publishing > > libera.chat IRC as the venue for meetings which have definitely > > moved to Matrix. > > > > Who's responsible for updating this, and is there somewhere issues > > should be reported ? Presumably whomever owns each meeting is > > responsible for updating it to point to the new Matrix locations, > > but do we need a bulk update ? > > > > It gets worse; the calendar can't handle Matrix locations currently. > It expects all locations to be of the form ircroom@irc.server and > doesn't have any way to address Matrix channels. Right. So, I guess fedora infrastructure is 'responsible'? But its not been at the top of any of our lists due to all the other more important things we have going on. :( So, help would definitely be welcome fixing the matrix/irc issues in the code, and then we could look at mass updating it. Or perhaps we should be looking at retiring fedocal, but would probibly want an open source alternative we could use or deploy. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Carlos Rodriguez-Fernandez wrote: > How could that be expressed so that those are caught quickly at build > time? Someone wants to depend on a java lib that has been tested only in > JRE 8 to 11, but wants to build the package with JRE 17+, or vice-versa, > for example. Perhaps, the only feasible way to detect that case is with > CI. IMHO, the library should have a: Requires: (java-devel >= 1:8 with java-devel < 1:11) Sure, this will not per se prevent you from attempting to use the library with the Java 17 compiler, but if you do not have Java 8 or 11 installed, installing the library attempting to install it as a dependency should raise a red flag. As a quick check, you could write a specfile for your application with: BuildRequires: java-devel >= 1:17 BuildConflicts: java-devel < 1:17 and then run mock on that. The latter line should prevent the old version from being installed in parallel. One annoyance is that older OpenJDK packages currently drop that virtual Provides, presumably in an attempt to get all Java packages systematically built with a newer JDK. That is something that ought to get fixed. (If we switch to building with the oldest possible Java as I suggest, it will have to get fixed anyway.) As is, you may need to explicitly: BuildConflicts: java-1.8.0-devel BuildConflicts: java-11-devel Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Christopher wrote: > So, I actually think that building with the *latest* JDK that we ship, > and using the `--release` flag during compilation is actually safer > than building against the lowest that we support, because it is most > likely to strictly enforce correct byte code generation for the target > JRE. The problem is, without ALSO installing the JDK for the targeted version AND explicitly pointing -bootclasspath to that JDK, this does NOT catch code trying to use class library features (as opposed to language or bytecode features) from the newer JDK, and worse, in rare occasions, even if the source code is in principle compatible with the targeted older Java, when compiled with a newer compiler and older target release, it will fail to actually run (!) with the latter (because the compiler picks up a subclass override of a method added in the newer Java instead of the baseclass method that was always available and, for performance reasons, tries calling the override explicitly rather than going through the virtual method lookup). One example of that latter issue is NetBeans, where versions 12.5 and 12.6 were supposed to be compatible with Java 8, but some upstream-published binaries of 12.5 and all of 12.6 do not actually work properly on it because they were built with Java 11 in "-release 8" mode: some editor features fail with runtime exceptions. See https://issues.apache.org/jira/browse/NETBEANS-6349 for details. (They "fixed" it by just requiring Java 11 in NetBeans 13 and newer. No fixed 12.x release was ever issued.) So I am AGAINST systematically using "-release" without "-bootclasspath", even though that works in most cases and is often successfully used in production (me and my employer use it, too, but on projects we control where we will fix the source code or add a workaround to it if any issues come up from that, not systematically on repackaging third-party projects). The compiler even warns about the missing "-bootclasspath". And the potential to cause subtle misbehavior that is a pain to debug is just too high, especially if we have the actual older JDK available and could just BuildRequire the correct version. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)
Carlos Rodriguez-Fernandez wrote: > Regarding the proposal as a whole, I think the proposal idea makes a lot > of sense, but for apps depending on system jar libraries, there should > be a way to specify that the app depends on a specific java bytecode > version range. System libraries packages could provide compatibility > packages, so couldn't those apps just depend on those compatibility > packages instead? That can become a maintenance burden for those libs, > though. The safest approach for library JARs would be to always build them against the lowest possible Java version (the oldest JDK branch that we still ship if the library supports that, otherwise the oldest the library supports). And IMHO, if the library is built against a higher version than the lowest we ship, it needs a versioned Requires on the JRE. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
soname bump for hiredis
Hey folks. hiredis 1.2.0 has been out a long while now, and with some prodding I am finally looking at updating rawhide to it. A interested user ran a mass prebuild: https://copr.fedorainfracloud.org/coprs/v02460/hiredis-1.2.0/packages/ Everything rebuilt fine. ccache collectd coturn gawk-redis gearmand gloo hiredis jimtcl minetest minetestmapper opensips php-phpiredis python-hiredis rsyslog rubygem-hiredis suricata syslog-ng yaz I've created f41-build-side-88835 with the new build. Anything not rebuild by next week I'll rebuild and submit the update then barring problems. Let me know if I missed anything. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: pipenv removal in F40
Miro Hrončok wrote:
> If you wish to help, I guess you can send a pull request to the release
> notes...
Or Mattia could simply unretire and adopt the package.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: isomd5sum 1.2.4-1 checksum bug
On Mon, Apr 29, 2024 at 12:20:37PM GMT, Brian C. Lane wrote: > I screwed up the isomd5sum checksums in the 1.2.4 release while trying > to fix support for small isos. I've reverted the change and 1.2.4-2 is > building for rawhide and Fedora 40. Thanks to Jonathan Billings for the > bug report (https://bugzilla.redhat.com/show_bug.cgi?id=2277398). Thanks Billings! > The bad version made it into Fedora 40 and Rawhide. > > With the bad version it will implant a checksum that is too short by 3 > characters, but checking it will pass if you use 1.2.4-1 -- but not if > you use any of the previous versions. You can check for the bad checksum > by running checkisomd5sum --verbose and look for ';FR' at the end of the > reported checksum. :( > > Spot checking the Fedora 40 netinst and workstation isos I don't see the > bad checksums so it looks like the build system was using a previous > version of implantisomd5 for the released isos. Thats good. > Currently in rawhide the isos have the bad checksums, so the builders > will need to be updated to isomd5sum-1.2.4-2 to fix this. Well, livemedia creation is done in a chroot in koji, so it should pick that up in tomorrow's rawhide automatically. I don't think anything needs manually updating, but if I am missing something let me know. kevin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
Fabio Valentini wrote: > No, that's just wrong. > The "upgrade path" (wrt/ NVRs) is no longer enforced across release > boundaries. AFAIK, all supported release-upgrade methods now use > distro-sync or something equivalent, so NVR-based "upgrade path" is just > not important any more. That just does not make sense: We enforce upgrade paths from Rawhide to Rawhide (!) requiring lots of unnecessary Epoch bumps when things need to be reverted (which is normal for a development running release), but we happily allow the ones that actually matter to end users to break? All this just so that lazy packagers do not have to increment a number (in most cases a single-character change, in some cases (such as a minor bump or every 10 major bumps) a two-character change, rarely more) when doing a new build. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
Michael J Gruber wrote:
> A minor bump (as in %{?dist}[.]) only comes into play
> if a "lower" branch needs to move forward without creating a version
> ahead of a "higher" branch. And (independent of autorelease) you cannot
> do that unless you use divergent git branches and cherry-picks in
> dist-git, in which case "version" makes sense per branch only anyways.
But Release MUST maintain the upgrade path from one release to the next.
Also, no, you do not necessarily need to allow the branches to diverge. If
you keep your branches fast-forwarded, you can just fast-forward the
"rebuild for libfoo in Fn" commit with the minor bump to all branches, but
build it only in the fn branch where it is relevant. The minor bump ensures
that doing that maintains the correct upgrade path, so you do not have to
push unnecessary rebuilds to releases where it is not relevant.
> In a dist-git where you work with release branches "contained" in
> rawhide - and use macros extensively - you automatically have commits
> which you merge down but which don't affect all branches, e.g. rebuild
> commits for dependencies or mass rebuilds. I'm not saying this is the best
> way of doing things (we should do it differently), but it's a common
> pattern. So you can have the "f40 mass rebuild" commit in an f39 branch.
> And in a world where you have and accept that, you can also push a
> "rebuild for libfoo" to rawhide and merge down to f40 if that is what
> you need to have f40 versions <= rawhide versions.
Sure, but as I explained above, this only works properly if you do a minor
bump rather than a full bump to Release. Otherwise you have to rebuild
everywhere or you break the upgrade path.
> But as others have pointed out, in the light of distrosync and
> macro-determined differences etc. we may just as well give up the
> illusion that "-5" means the same in different branches, and
> consequently lift the sorting policy between different branches.
But that breaks the upgrade path, so it is a no go.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: how to do minor bump using %autorelease?
Julian Sikorski wrote: > I need to rebuild mame on F40 only for qt-6.7. On rawhide, > mame-0.265-1.fc41 is already built against it so I only need to build > mame-0.265-1.fc40.1. Can it be done using %autorelease? No, which is why you should not be using %autorelease. I would just replace %autorelease with a correctly manually bumped Release in the specfile as part of doing the rebuild. Just letting %autorelease do its thing and ending up with a full bump would be incorrect, so it should not even be considered as an option. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: systemd 256~rc1 in rawhide
Adam Williamson wrote:
> Well, it really wants to write to /lib , not to /usr. But of course, on
> Fedora, /lib is /usr/lib .
Sigh… Time for a UsrUnmerge? :-)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Is there a policy for branches being merged or not
Julian Sikorski wrote:
> In this case defaulting to cherry-picking would be a safer bet. Branches
> unintentionally separated can be merged, but branches unintentionally
> merged cannot be unmerged.
This is only true if you are talking about merge-commit merges. Not if we
are keeping the branches fast-forwarded (and using %{?fedora} conditionals
in the rare event something really needs to differ between the releases). A
linear history cannot be remade truly linear once it was diverged by a
cherry-pick (or simply a separate bump from running rpmdev-bumpspec
separately on each branch, as scripted rebuilds often do). The best we can
do to restore fast-forwardability is to merge one way and then "merge back",
which will fast-forward the other branch to the same merge commit. This
still leaves an ugly knot in the history, but at least the branches can then
be fast-forwarded again. But a clean linear history is no longer possible
after someone did an unwanted cherry pick instead of a fast-forward merge.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
On Fri, Apr 26, 2024 at 11:16:28AM GMT, Adam Williamson wrote: > On Fri, 2024-04-26 at 08:56 +0200, Jan Kolarik wrote: > > Hi Kevin, > > > > Personally, I think this is a beta requirement. > > > > > > > IIUC the Fedora 41 Beta requirement is to successfully upgrade the system > > from Fedora 40, as mentioned here: > > https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation. > > So this still relates to the dnf4 package, which is used in Fedora 40. I > > expect this will become relevant for dnf5 at the Fedora 42 Beta. > > Yup, that makes sense to me. The upgrade is all run by the previous > release's DNF, not the new release's DNF. Yeah, sorry... I agree, I was confused. :) kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide
On Thu, Apr 25, 2024 at 11:42:57AM GMT, Jan Kolarik wrote: > Hello Michael, > > Does this mean that distro-upgrade from F41 to F42 is supposed to work > > at F41 release time (ideally at beta time)? > > > > Yes, the system-upgrade functionality should be available before the Fedora > 41 > release date. We're planning extensive testing for this, including a Fedora > Testing Day. Personally, I think this is a beta requirement. Lots of people upgrade around then to get on the new release, and also having it available to test then is pretty important. Thats just my opinon... QE might have different opinions. > While our goal is to deliver the final system-upgrade functionality before > the stable release, > some adjustments may be made during the Fedora 41 lifecycle to ensure > smoother > upgrades from F41 to F42. Before executing the system-upgrade, users are > anyway > advised to ensure that all installed packages are fully updated. So, how do you rate the chances of having something ready by beta freeze? kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Fedora Miracle Spin (self-contained)
On Thu, Apr 25, 2024 at 05:48:46AM GMT, Zbigniew Jędrzejewski-Szmek wrote: > > There's also the effort of distribuiting and archiving a few > additional gigabytes, putting up the links on the website and browsing > through them, some additional time and and additional step that can > fail during builds… It's actually a lot more than a few GB. We do rawhide builds of everything every night. We keep a bunch of those until they age out... ie, % du -sh /mnt/koji/packages/Fedora-Sway-Live/Rawhide 62G /mnt/koji/packages/Fedora-Sway-Live/Rawhide or all releases/beta/rcs: % du -sh /mnt/koji/packages/Fedora-Sway-Live/ 118G/mnt/koji/packages/Fedora-Sway-Live/ Anyhow, I think if there's an interested community around something making a spin is reasonable. I do think we are also bad about not retiring things that not many people are interested in anymore, and I wish there was a better way to avoid duplication between all the spins. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d
David Abdurachmanov wrote: > We currently use a symlink (as Richard) mentioned, but it's not ideal > and causes problems (e.g. meson generates wrong paths breaking some > packages [one example: libplacebo]). Which I would say is a bug in Meson and should be fixed there. I do not think having /usr/lib64/lp64d be a symlink to /usr/lib64 is in violation of any standard. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
On Fri, Apr 19, 2024 at 09:37:38AM GMT, Igor Kerstges wrote: > Those questions regarding privacy are asked and answered to my satisfaction. > I'd like to understand more implications about this change.. There are none. This proposal was withdrawn. It may be adjusted and submitted for consideration again, but that has not yet happened. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Replace Redis with Valkey (system-wide)
Nathan Scott wrote: > - it could be advantageous if the new compat sub-package contained > the redis binary symlinks & not the primary valkey package (this could > allow valkey and redict packages to coexist, for example). Long-term > we may want to drop those entirely (along with the compat package, to > complete the transition away from Redis). I do not see why we need a separate compat subpackage at all. Valkey should just Obsolete/Provide redis and include all the compat symlinks in the main package. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Kilian Hanich via devel wrote: > The fact that you can share the keys is actually part of the design and > wanted. Apple for exmaple has (or wants to) implement easy sharing of > passkeys via AirDrop. So the Apple Cloud can see your private key, but you cannot? Sounds like GREAT "security", LOL… Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Gary Buhrmaster wrote: > [2] As I understand it, the issue is the > lack of the required trusted environment > in generic Linux. There are software > implementations that do not have the > hardware enclave protections, And to be honest, I do not see the problem there. I will use whatever will let me pass the Fedora security theater checks without investing in extra hardware. (This also means that if I am offered the choice, I will pick TOTP over FIDO2 any day, because TOTP does not require me to emulate a fake hardware crypto device like FIDO2 does.) And in my view, the fact that, in those implementations, there is no Treacherous Computing hardware preventing me from doing what I want with my own private key (e.g., just copying the same key to all my devices, as I can also do with TOTP) is actually a feature, even if it goes against the "security" model. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
Richard W.M. Jones wrote: > As gcc -Os was mentioned too, that is -O2 with the following > optimizations disabled: > > -falign-functions -falign-jumps > -falign-labels -falign-loops > -fprefetch-loop-arrays -freorder-blocks-algorithm=stc Last I checked, there were also some hardcoded if (optimize_size) peppered throughout various GCC optimizations and even target files (to choose between faster or smaller instructions). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Fri, Apr 12, 2024 at 03:45:40PM -0400, Steve Cossette wrote: > What about simply blocking access to the git repos/koji/bodhi for those > without 2fa? Well, git I suppose could be a hook that checks the status of the user, but koji and bodhi don't really have any place to hook that in directly. They would have to add something in their permissions models to check for specific actions. Denying access to koji and bodhi entirely for people without 2fa is... way too wide. bodhi updates would never get karma from users who didn't bother to set it up, people just doing scratch builds would be affected, etc. So, sure, it's possible, but would be a lot of new code needing written. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal - Python Built with gcc -03 (self-contained)
Neal Gompa wrote: > I would like for us to consider evaluating a global change to -O3. I > am not convinced that there's a good reason anymore to remain at -O2. > > If we get this kind of benefit from Python, I would be interested in > seeing what we'd get elsewhere. How much larger is Python at -O3 compared to -O2? And other packages? I would like to see -Os as the default. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Adam Williamson wrote:
> Also, these days, most authenticator apps support some kind of backup
> mechanism. FreeOTP lets you back up to a file (which you should, of
> course, keep somewhere safe and ideally encrypted). Google
> Authenticator can backup To The Cloud.
If you use Keysmith, you can just SFTP your
~/.config/org.kde.keysmith/Keysmith.conf from/to all your GNU/Linux
computers including the PinePhone or equivalent, and they will all be able
to generate the same TOTP keys with the same master key.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson wrote: > On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote: > > I was hesitant to have MFA for a while. Imagine losing a phone with tons > > of tokens. What a hassle to recover from that. I found it less than > > ideal for practical reasons. > > This is one reason most systems provide a sheet of one-time backup > codes that you're meant to print out and keep in a safe place, for > recovery from exactly that scenario. > > Alternatively, if you have an old phone or tablet lying around, just > install an MFA app on that and enrol it too, lock it in a cabinet, then > if you ever lose your primary phone, use it to recover. > > Also, these days, most authenticator apps support some kind of backup > mechanism. FreeOTP lets you back up to a file (which you should, of > course, keep somewhere safe and ideally encrypted). Google > Authenticator can backup To The Cloud. yeah, I'll put in a plug for the one I use: https://github.com/beemdevelopment/Aegis It's open source, available on f-droid and play store, can to encrypted backups, pretty active upstream, highly rated in reviews. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: RFC: Django latest vs LTS maintenance plan
On Thu, Apr 11, 2024 at 03:41:02PM -0500, Michel Lind wrote: > Hi all, > > With the recent EOL of the Django 3.2 LTS series[^1], and Django being a > key component of our mailing list infra for both Fedora and CentOS, I > would like to propose the following plan to maintain Django in both > Fedora and EPEL: > > - Fedora: `python-django` maintained as currently, not tracking any LTS > series > - **but** also fork off `python-django` each time it hits an LTS > series to make a new `python-djangoX.Y` (e.g. > https://bugzilla.redhat.com/show_bug.cgi?id=2274198) > - LTS packages are introduced in Fedora first, until they either reach > EOL or no longer build, at which point they are retired in Rawhide. > See below for the EOL case. > - EPEL: we will only branch LTS packages (as is the case now, with > `python-django3` - though under the new naming scheme it should have > been `python-django3.2`) > - Handling EOL > - not an issue for `python-django` - we just keep rebasing it To be clear, in fedora right? There wouldn't be a bare python-django in EPEL? > - for LTS releases in Fedora, retire in Rawhide if the series will > EOL before the EOL of the upcoming Fedora release > - for LTS releases in EPEL, once it is EOL (like `python-django3`) > we mark it as `Provides: deprecated()` and retire it if there is a > replacement that works with add-on packages, *and* there is a CVE > that is not fixed > - Package ACL: cc-ing the current maintainers of python-django here. > Please let me know if > - you want to be added to the LTS packages as well > - you want to be removed from python-django > - you're not currently involved but want to help out > - I'll also add infra-sig to the ACL for the LTS packages, as in > practice they might need access to fix any issue affecting Mailman > > The different Django stacks are in the process of being updated so they > can be swapped without affecting dependents, by providing and > conflicting with the virtual `python-django-impl`; not only will this > allow us to swap one Django LTS for another in EPEL when the older one > EOLs, but it also allows those with dependencies that are not qualified > for the latest Django to swap to the LTS in Fedora > > Let me know if this makes sense, or if you have ideas of how to handle > some of these better. I think it does make a lot of sense. ;) On the epel side, it would be good to make some noise/announce when a LTS one is marked deprecated and when it's retired, since 3rd parties might be using it for the external stuff even if everything in EPEL moves to the new one. Would a EPEL package moving to a new LTS release need exceptions/announcements also? I mean, ideally it doesn't matter, but it would be a large version jump, even if the dependent package didn't change otherwise. Also, there might be cases where the dependent package does have to change... ie, foo-1.0 works with django-3.2, but when 4.2 lands you have to upgrade to foo-2.0 to work with it? Anyhow, I think this is a pretty reasonable process, but we should make sure and communicate it very well, document it and make sure epel steering comittee is happy with it. kevin signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Thu, Apr 11, 2024 at 05:49:27PM -0700, Adam Williamson wrote:
> On Fri, 2024-04-12 at 00:09 +, Gary Buhrmaster wrote:
> >
> > What is the best way to formally propose
> > that 2FA is required for packagers after
> > some date
>
> There is already a FESCo ticket. https://pagure.io/fesco/issue/3186 /
> Please don't discuss there, discuss here; FESCo will vote in that
> ticket or a meeting when they feel it appropriate.
I was wanting to circle back and add some more info to this thread too.
So, right now as far as I know, IPA doesn't have a way to easily say
'require a otp to be enrolled if you want to be added to this group'.
We do have a script that can check current members of a group(s) for otp
and nag them. This is what we do for sysadmin groups, although we
haven't done it in a while.
So, if FESCo decided we wanted to enforce 2fa for provenpackagers or
whatever, right now that would require some work on some scripting,
which I guess would remove people without otp? But then there would
still be a window when the user was added and before the script removed
them. Or some way for sponsors to check otp status before sponsoring
someone, but if thats manually it could be missed.
I think in any case it might be good to find all the {proven}packager
members without otp and perhaps email them a note about how to set
things up, etc.
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Looking for people to be stewards of rpminspect-data-fedora
On Tue, Apr 09, 2024 at 01:55:41PM -0400, David Cantrell wrote: > Hello all, > > I am looking for multiple people to help be upstream stewards of the > rpminspect-data-fedora project. This is a project that contains config files > and rules for running rpminspect on Fedora builds. It is a package > containing distribution policy. It needs people to look over it and review > and merge contributions from other developers, do occassional releases, and > ensure that it is updated as new releases of Fedora are started (and we get > new dist tags). > > The project currently lives here: > > https://github.com/rpminspect/rpminspect-data-fedora > > But absolutely can move depending on the desires of the individuals who take > over maintenance. I created these rules files in the data package for > rpminspect so that different vendors can customize how rpminspect runs and > reacts to findings. Maintenance of the rules is independent of the software > maintenance. > > If you are interested, please email me directly and we can get going on the > logistics. If you have general questions, feel free to ask here. I wonder if this isn't something we should have the QE or releng teams manage... ie, adding new branch info (releng), adjusting tests (qe)? kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Zbigniew Jędrzejewski-Szmek wrote: > So… this is what I'm talking about: there is no obvious way to > figure out what to set. Looking at the logs and trying to figure out > some variables from that is not very attractive. The comments at the top of the relevant Find*.cmake module are the best source for which variables you are supposed to set directly. But there is also cmake-gui that can show you all the available options in a pretty Qt GUI. > Nevertheless, for me, CMake and autotools are outdated technologies > that shouldn't be used in new projects. And for me, Meson is just a poor Not Invented Here imitation of CMake, with fewer features and in a slower programming language. :-) And the kind of automagic you complain about is something all 3 major build systems do (and plenty of obscure ones, too). Maybe not for the specific case of the Python executable, but there are plenty of other cases where autotools and Meson also do automagic, which is why building outside of a chroot is such a bad idea. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
Zbigniew Jędrzejewski-Szmek wrote: > And sorry, but saying to "process pull requests quickly" is just naive. > Busy packages often have many different pull requests concurrently, and > some of them need discussion and fixes and work in other places before > they can be merged. Generally, there should be no room for discussion there. Either the pull request is good, then merge it immediately, or it is not, then reject it immediately. People who want to contribute to Fedora packaging ought to know what they are doing, if not, just reject and let them submit a new pull request when they have done their homework. > I guess we'll just have to agree to disagree. In the other part of the > thread, a proposal that was floated to allow opt-out. I hope that's > acceptable. You have received a lot of all-negative feedback and one single message of support. So for me there is a clear consensus to NOT implement your proposal at all, not even with an opt-out option. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Monday's FESCo Meeting (2024-04-08)
On Mon, Apr 08, 2024 at 06:19:31PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Apr 06, 2024 at 10:45:52AM -0700, Kevin Fenzi wrote: > > = Discussed and Voted in the Ticket = > > > > Change: GNU Toolchain F41 > > https://pagure.io/fesco/issue/3181 > > APPROVED (+6, 3, -0) > > Not that it matters for anything, but it's actually (+6, 0, 0), > i.e. there were no abstaining votes. (I was surprised by the three, > so I went to check the ticket.) Sorry, my brain somehow decided that was 'didn't vote' instead of 'actually abstained'. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
Zbigniew Jędrzejewski-Szmek wrote: > I'm revisting the topic of rpmautospec because I was doing some work > on various packages, and it's annoying that some packages are using > rpmautospec and others are not. The fix for that inconsistency would be to ban rpmautospec. It just makes everything more complicated. > All my packages have been converted, so in day-to-day work, I don't > even think about %changelog. When working with other packages, I'll > forget to update the Relase and/or %changelog. Today I was rebasing > some pull requests in pagure, and the _only_ conflicts that I had were > about Release and %changelog. Generally, it helps to keep all your branches in sync (and with that, I mean, fast-forwarded to the exact same commit hash – no, it is not a problem if the changelog for a Fedora release includes an entry for a Rawhide mass rebuild made after that Fedora release branched, it explains why the Release number has increased and is otherwise harmless) if you are building the same versions for all releases (which is typically the one case where you bother backporting specfile updates across releases at all), and to process pull requests quickly, before you or rel-eng or another pull request bump the specfile in Rawhide. Then you rarely have conflicts in %changelog to begin with. > I think it's time to switch to rpmautospec completely. > Thus, the proposal: > - new packages MUST use rpmautospec > - packagers SHOULD convert their packages > - provenpackagers MAY convert existing packages > (e.g. when they want to push some fix or separately from other >work) > - people submitting pull requests against src.fp.o MAY also > include a conversion in the pull request and packagers SHOULD > merge it. I am opposed to every part of this proposal. Allowing provenpackagers to convert existing packages (that they do not explicitly comaintain) would be particularly rude. I do NOT want any of this automagic (also the various %auto* macros such as %autosetup) in my specfiles, it just makes my life harder for no benefit whatsoever. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: convert everything to rpmautospec?
Emmanuel Seyman wrote: > I've noticed a trend in proposed changes in the way Fedora works. I am fed up of this salami tactic as well. When we complain about the new stuff, we invariably get told "don't worry, you don't have to use it, it's all optional", but the plan is always to make it mandatory later. See also 2FA that they are now trying to force on us, taking as an excuse an incident that was demonstrably NOT stopped by 2FA. > They start off as as things packagers will not have to use if they do > not want to and, over time, become default/forced (Matrix vs IRC, To be fair, part of the blame there is to be put on Libera.Chat that unilaterally turned off their Matrix bridge. (Yes, they did give Matrix some time to address the demands they had, but when Matrix told them it was not feasible in such a short time frame, they just first suspended, then permanently blocked the Matrix bridge.) But, and here is where I blame Fedora, instead of just letting the chans on Libera.Chat die and moving everything to Matrix, they should have moved the IRC chans to a network with a working Matrix bridge, such as OFTC (or pretty much anything other than Libera.Chat – I guess even Freenode under its new owners might be an option), then we could still be happily using both technologies interoperably. Instead, we get told to just use Matrix and shut up, which I do not consider acceptable. > Discourse, ...). There too, I do not see why some discussions are now being directed to Discourse instead of the mailing list. And it is not even working. Most of the pertinent feedback for new Changes still comes on this list, not on Discourse. The developers use this list, Discourse is only for users who do not know how to use a mailing list. > Perhaps it's time to discuss imposing financial and/or legal penalties > when the opt-in nature of the change goes away. Who would impose those? And from whom to whom would the money flow? I do not think this can work. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
I wrote:
> On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
> wrote:
>> Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
>> detection of python, and it found /usr/bin/python3.13t that I have
>> installed, and subsequently it got all the paths wrong.
>
> That's why you should never build packages outside of mock.
PS: Autotools also loves to autodetect random libraries that happen to be
installed on the system. It is in no way specific to CMake.
>> How do I override this?
>> ('cmake -LAH' doesn't yield anything useful.)
Usually -DSOME_VARIABLE=/some/path is the way, look in FindPython.cmake for
the variables it uses. (First, try to figure out whether RPM is using a
system-installed FindPython or its own custom version, so you look at the
correct version.) But the safest (for all build systems) is to always build
in a mock chroot with only the expected BuildRequires installed, as I have
written.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: EPEL9 updates obsoleted
On Sun, Apr 07, 2024 at 10:11:56PM +0200, Fabio Valentini wrote: > On Sun, Apr 7, 2024 at 10:10 PM Fabio Valentini wrote: > > > > On Sun, Apr 7, 2024 at 7:06 PM Antonio T. sagitter > > wrote: > > > > > > Hi all. > > > > > > Can this update be re-activated or i have to rebuild everything? > > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c154b725ab > > > > I'm not sure how the update got into the "obsoleted" state without > > being obsoleted by ... *something*? > > It should have been "unpushed", which should allow you to to un-unpush > > it, but de-obsoleting doesn't seem to be possible. It looks like it hit the -3 karma limit and it got obsoleted. It does seem like that should have just unpushed it... > > Since the update was created from a side tag, you can't just remove > > all builds from the update and add them to another one ... > > But tagging the builds into a fresh side tags won't work either (IIUC) > > because there already exists and update for these builds :( > > > > Not sure how this update got into this weird state, but I don't think > > there's a way around rebuilding things in a fresh side-tag. > > (People who know better than me, please correct me if that is incorrect.) > > Oh! One thing you *could* try is to untag the builds from the side-tag > for the obsoleted update, edit the update to refresh the list of > builds, and save an "empty" update. Not sure if that will work though > ... Then it would be possible to tag the builds into a fresh side-tag. You cannot remove the last build from an update, so you would have to rebuild the one thing anyhow. ;( So, probibly best to just bump and rebuild em all? kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
That's why you should never build packages outside of mock.
Kevin Kofler
On Sun, Apr 7 2024 at 13:52:26 +00:00:00, Zbigniew Jędrzejewski-Szmek
wrote:
On Sat, Mar 30, 2024 at 10:15:47PM +, Zbigniew
Jędrzejewski-Szmek wrote:
One particular issue I have with CMake as a downstream maintainer is
it's often very hard to override linking or compilation options
or when the project is using one of the cmake find scripts that gets
something wrong… It's possible that those projects are "doing
cmake wrong",
but it seems that CMake makes it easy to do things wrong.
I just had to interact with CMake, so let's use that as example:
I'm rebuilding rpm.rpm with some local patches using 'fedpkg local'
in F40.
The build fails with:
Directory not found:
/home/zbyszek/rpmbuild/BUILDROOT/rpm-4.19.1.1-2.fc41.x86_64/usr/lib64/python3.12/site-packages/rpm
Hmm, why? Oh, rpm uses cmake, and cmake has it's own special
detection of
python, and it found /usr/bin/python3.13t that I have installed, and
subsequently
it got all the paths wrong. How do I override this?
('cmake -LAH' doesn't yield anything useful.)
(When compiling a python module, any other alternative would be
better.
The build uses %python3, i.e. /usr/bin/python3.12, so there's no need
to detect anything, the location of python is known and all this
binary
can be called to print all paths. Otherwise, either call
'python3-config' or 'pkgconf python', don't do you own
reimplementation.)
Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Schedule for Monday's FESCo Meeting (2024-04-08)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:30 UTC in #meeting:fedoraproject.org on Matrix. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2024-04-08 19:30 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Change: GNU Toolchain F41 https://pagure.io/fesco/issue/3181 APPROVED (+6, 3, -0) = Followups = None = New business = #3183 Change: PHP No 32-bit https://pagure.io/fesco/issue/3183 #3191 Change: Switch to DNF5 https://pagure.io/fesco/issue/3191 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Introduction and Application for Sponsorship
On Fri, Apr 05, 2024 at 03:07:39PM +, seanmott...@posteo.net wrote: > Hi devel! > > I'm Sean (FAS: seaninspace). I've been working professionally in Linux > Sysadmin/Engineering positions for over a decade now, and would like to help > out more :) > > I've spent most of my Fedora time in QA with the installer, specifically the > XFCE Live ISO. Additionally, I have maintained small/personal packages > outside of the official repositories in the past, and have previously > maintained an RPM mirror with a decent amount of traffic. I'm hoping to > learn more and give back by adopting this package. > > I've submitted a sponsorship ticket here: > https://pagure.io/packager-sponsors/issue/643 Welcome Sean! Feel free to ask here or in the #devel:fedoraproject.org matrix channel if you run into any problems/questions. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Peter Boy wrote: > Well, a switch from Gnome to KDE would require a lot of changes in > everyday applications, e.g. Mail. That is not required when you update > from Gnome 2 to Gnome 3. Well, in principle, GNOME applications will usually work under Plasma and the other way round. But in practice of course most default applications on the Edition would change along with the desktop environment. So if you are one of those users who never upgrades, but always reinstalls from scratch, or at least installs everything in the Edition's group on upgrades, you will be in for a few surprises indeed. > Provide a reliable solution which includes a non breaking evolvement of > the Edition. I would argue that people upgrading to a newer Fedora should just upgrade in place with the packages they have installed, ignoring the new defaults of the Edition, so they would remain on GNOME and GNOME applications if that is what the release they had initially installed was shipping. Though of course then there will be some people complaining that an upgraded Workstation is completely different from a freshly installed Workstation. But IMHO, that would be a feature, not a bug. > Too bad, an explicit scientific desktop edition might have helped me > propagate a Linux desktop in our University research cluster of excellence > a good decade ago. Scientific Linux for Servers was a great success. We tried, but it was deemed not distinctive enough to warrant an Edition, our application was rejected on those grounds. After all, it was still a desktop spin, just with some scientific applications preinstalled on top of it. So it was accepted just as yet another Spin (next to the regular KDE Spin), and eventually the Labs category was created for this and other use- case-specific (former) Spins. So a Scientific Spin (now Scientific Lab) did in fact exist around a decade ago, but maybe "a good decade ago" was slightly too early, just before it was created. In addition, there was also pushback against this suggested compromise (having the Plasma Edition be a Scientific Edition) from non-scientific KDE users who understandably did not want to have to install a Scientific Edition and then uninstall lots of niche apps they will never use from it. But that discussion became moot because the Edition application was rejected anyway. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leslie Satenstein via devel wrote: > The Cellphone user is very comfortable with Gnome. So much so, that I > believe that if he was given KDE as the interface, two things would > happen. a) The user will switch to Gnome, or b) The user will find a way > to add his favourite applications to the desktop. b) is actually very easy on modern Plasma (I tried it on Plasma 5), just right-click on the application in the menu and click "Add to desktop" in the context menu. KDE upstream has long given up trying to deprecate desktop icons (as they tried to do in early Plasma 4 releases, though even those allowed you to put a folder view widget displaying the Desktop folder (and hence, icons) on the desktop). In Plasma 6, the desktop is always a folder view. Or the user can just switch the menu type to something icon-based and very similar to the menu in GNOME Shell with right-click on the menu button, "Show Alternatives…" and "Application Dashboard". And if the user really wants a smartphone UI with a smartphone-style menu, always-maximized windows, etc., they should use Plasma Mobile, not Plasma Desktop. But a customized Plasma Desktop as described above is probably a better fit for traditional desktop/notebook computers. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Tomasz Torcz wrote:
> GNOME (Mutter) maximizes windows if they initially take 80% of more
> screen space.
And I believe that that, too, was a refinement added in later releases.
IIRC, GNOME 3.0 just maximized everything.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
ing is inherent to what atomic systems are and what the Everything ISO is, and should be obvious to anyone who actually understands what they want to install. > Basically, we have one domain *now*: fedoraproject.org But that domain has subdomains such as spins.fedoraproject.org, labs.fedoraproject.org, etc. distinct from the main fedoraproject.org domain (though technically the subdomains redirect to pages on the main domain these days). > If you have a look on the statistics Matthew reported on Flock last year, > you would know that the numbers for Workstation were declining, whereas > the numbers for Server raised steeply and for CoreOS and IoT steadily up. The numbers for Workstation might be declining because people are installing other desktop Spins, or a custom selection from Everything, instead. :-) None of those will have fedora-release-workstation installed. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
I wrote:
> That is exactly the problem with autotools code, almost nobody understands
> what the heck it does, almost everybody just copies and pastes somebody
> else's snippet hoping it does not do bad things. And gnulib is a
> particularly ugly piece of the puzzle.
PS: Here is a pretty good post summarizing the issues with autotools, both
generally and in the context of the xz vulnerability:
https://felipec.wordpress.com/2024/04/04/xz-backdoor-and-autotools-insanity/
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Switching XZ for ZSTD?
On Thu, Apr 04, 2024 at 08:11:42PM +0200, Leon Fauster via devel wrote: > > One approach that would be at least bring some light into "weak" > (non technical layer) components (albeit not sure how feasible it is), > could be: > > - Checking the resources of a packaged project. >Resources in terms of man or firm power that backup the project > > - Contribution activity of people > > - General activity of the project > > - Transparency of the workflow / tools > > and that for all projects that the distribution includes. > > Why? This would allow to plan internal review activities > (or processes) more effectively. They would be directed > to the "weak" components with higher priority (recurrent, actions). > > > Like the current process for checking the license (SPDX) of a project, > it could also collect such metrics right away. Well, as others have noted there is already OpenSSF scorecards. I agree it's good to know this info, and for maintainers that have a ton of packages they maintain, it might be good to be able to look at this to remind them. For maintainers with fewer packages, they likely already just know this from interacting with the upstream project already. I don't think we can or should use that for things like deciding if we allow packages into the collection or the like, there's a lot of ways a low score there could not matter or be non represenative of what the project is like. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Switch to DNF5 (system-wide)
On Thu, Apr 04, 2024 at 07:00:13AM +0200, Jan Kolarik wrote: > Hi guys, > > the dnf-automatic command will be obsoleted. > > > > Oh, sorry about that. This portion of the text was inadvertently altered > during the review process. I've already corrected the text on the wiki. > > The dnf-automatic command will still be available, now provided as a plugin > and functionally compatible with dnf4. Although the configuration files' > location has changed, it will be documented in the dnf4 vs. dnf5 changes > documentation <https://dnf5.readthedocs.io/en/latest/changes.html>. Yeah, on digging more into the docs it looks like this should be fine. Just needs adjustment of the config and enabling the timer you want. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Switching XZ for ZSTD?
On Thu, Apr 04, 2024 at 05:04:20PM +, Arnie T via devel wrote: > Hi Stephen, > > Thanks for the explanation. > > I just caught up with the article at the New York Times, > > Did One Guy Just Stop a Huge Cyberattack? > https://www.nytimes.com/2024/04/03/technology/prevent-cyberattack-linux.html > > And the comic that looks like it fits the problem I'm most noticing here! > > https://xkcd.com/2347/ > > I have to admit that I still don't know what the best or most official "At > least do this" instruction page is for a Fedora user. > I don't see anything at the main https://fedoraproject.org/ website or its > "News & Announcements" page. The magazine article should cover this. If you are using Fedora 38 or Fedora 39, nothing to do. The versions affected were never in there. If you are using Fedora 40 (prerelease) or Rawhide you should urgently update. This will get you the clean version. If you wish to be extra cautious, you could reinstall from current nightly media. > In this thread its becoming about the details of the process. But not yet > about a solution. All of which I get. > And in private emails people are insisting on sending to me about how I'm > unreasonable for asking the questions, and "should have" understood this or > that. > So, with your discussion the best guess I can some up with is to make sure XZ > is downgraded and just hope that one of this Jia Tan's 6000+ commits are > still hidden in some other project with not enough eyes. Or that the XKCD > coming true doesn't happen again. Lots of folks are scrutinizing those commits. There were some minor things discovered, but nothing (at least that I know of right now) that affects Fedora. There are changes coming in systemd, openssh and other places that would make this particular vector harder/impossible also. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Switching XZ for ZSTD?
On Thu, Apr 04, 2024 at 01:26:14PM +, Arnie T via devel wrote: > Hi, > > I just installed Fedora on 2 of my PCs a couple of weeks ago. One version of > Fedora 39 release and one of Fedora 40 to see where things are going. > > I learned about this XZ-hack from Ars Technica & The Economist. > > I got to the Fedora Magazine article and wasn't really clear on that. > > So I followed the discussion to this thread in this Development mailing list. > > I read a lot of it but _still_ can't 100% figure out what the final solution > is going to be. There's no 'solution' really... there's a lot of discussion around what we can improve at the distro level, what we can urge upstreams to do, how we can help out more, etc. I'm hopeful some things will come out of this as it's a chance for us to look at our processes and improve them. > I have a question about that. > > I'm for sure OK that a responsibly developed FOSS project can contribute > value and should be welcomed. > > ISTM that if a package is used on critical-path or security-path by default > in a Distro it needs a higher bar. > > IIUC from this thread and online discussions about XZ & alternatives that > > 1] Lack of committer 'Real' identity confidence and verification is a problem. IMHO this isn't a problem. We don't have a right to demand anything from open source projects. We can ask, we can urge, we can contribute and change things, we can choose to not use something, or fork something. > 2] Undetected differences source + packaging in repo vs tarballs are > unchecked. Yeah, a lot of the discussion has been in this area. I'm wondering if perhaps we shouldn't revisit source-git, or at least a variant of it where we keep the upstream sources in a branch always and apply packaging on top of that and build from there. > 3] Under-resourced development creates risk; 'Many eyes' bench depth in > development is needed. Yep. I think also visibility of changes can be improved. So, maintainers know more about whats in a new version and how it works. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Neal Gompa wrote: > By default, GNOME only presents the close window button. The other > buttons are missing, and there isn't really an intuitive way to > discover the other window management actions. In the version I tried, and judging from end user reports, for several years, it did not even present that, leading to fun issues such as some KDE dialogs that could not be closed at all (because they were missing a "Close" button and relying on the window decoration exclusively). >> "the shut down options in the mouse menu hidden behind a keyboard dead >> key, etc.)" this is also not the case for ages, or at least not in its >> completeness. > > Yes, this did change a few GNOME releases ago. Of course, having only tried GNOME 3 once, I could not know this. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leon Fauster via devel wrote: > 10 minutes is not enough to do a remodeling of the "familiar" > experience, so that you reaches the so called realm of intuition. > The latter is something that we learn over time and the desktop > environment does not offer this on its own. It provides only a > framework where this can happen. But that is exactly the issue with the GNOME design: It is really arrogant to expect me to unlearn decades of learned familiar experience and retrain to something completely different that in the end has at most minor advantages, it is not significantly better, just different. I want the software to ideally behave the way I am used to (i.e., the way Windows 95 worked, see below) out of the box, or if not, at least have an "old-school mode" toggle in the preferences that makes it work that way (and I will almost certainly use that toggle). > PS: Imagine the first CLI steps and the corresponding bad > experience, but we have not given up :-)! Oh, my first computer was actually an XT clone running IBM PC-DOS 3.3. So I actually started with a CLI. :-) Then Windows 95 on a Pentium 120 (MHz). And on that Pentium, I also got started with versions of Red Hat Linux of the time (not sure what the first one was), first from CD-ROMs bundled with computer magazines, then the downloadable FTP edition. And I also tried one magazine CD-ROM with an edition of Caldera "OpenLinux" (which was actually much less open than RHL, and Caldera eventually became the infamous SCO) with the at the time brand new KDE 1 (version 1.1.1). Having used DOS, the bash CLI was not that bad to work with, but the distros at the time already came with GUI environments (FVWM95, then came KDE 1 and GNOME 1). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kilian Hanich via devel wrote:
> About the release cycle: After the initial release of Plasma 6 when dust
> has mostly settled down (approx. 2 point releases), they want to switch
> over to a release cycle which would align (which is likely also the
> reason why F42 was choosen in this proposal).
Interesting point. And there I thought it was only because the answer is
always 42. ;-)
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Gordon Messmer wrote: > If RPM's ELF dependency generator were better, the importance of > stability would be debatable, but as it is, I really think Fedora should > be more stable than it is, especially for whatever it defines as "the > OS." Today, dnf/rpm will happily allow users to install an application > that will not run because that application actually depends on newer > versions of dependencies than are installed on the system. If a > significant portion of the standard desktop regularly rebased in the > middle of a release, I expect that would be a more common problem. Symbol versioning helps with this, because the ELF dependency generator extracts the symbol versions (though not the individual symbols, only the versions) that are required. And, e.g., Qt uses symbol versioning. The KDE packages also often have explicit versioned Requires on the dependencies where it matters. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Gordon Messmer wrote: > "When you are using the Linux mark pursuant to a sublicense, it should > never be used as a verb or noun. It should be used only as an adjective > followed by the generic name/noun. In other words, “Super Dooper Linux > OS” is okay, but “Super Dooper Linux” isn’t." > > https://www.linuxfoundation.org/legal/the-linux-mark Kinda the same recommendation that also applies to the Fedora trademark, by the way. But everyone only cares about their own trademark. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Aaron Rainbolt wrote: > Still, one could make some case for this. Plasma is, for one, obviously > going to be more familiar to newcomers to the Linux world simply by > virtue of the fact that the paradigms presented by its initial > configuration are more familiar to those coming from the Windows or > ChromeOS worlds, and (hopefully) those paradigms aren't sufficiently > different from MacOS to be too uncomfortable for a user coming from the > Apple world. You make a good point there. The thing is, GNOME tries really hard to design for new users, whom they define as a user who has never before used a computer. Such users are basically on the edge of extinction. A paradigm that works great for someone seeing a computer for the first time in their life does not necessarily work all that great for someone trained to use different paradigms used in the operating system(s) they have used for decades. As you point out, for users switching from a different operating system, which is a much more likely scenario, the GNOME Shell design is really confusing and disruptive, and GNOME's reluctance to make it easy to switch some things back (instead requiring you to install shell extensions for any such change) does not help. Even if the other operating systems' patterns happen to be counterintuitive if you have never seen them before, once trained to them, you will not only be able to work efficiently with them, but also be confused by GNOME's intuitive design that they carefully usability-tested on people with little to no computer experience. That leaves GNU/Linux power users who have used nothing but GNU/Linux for decades. I am in that category, like many regulars of this mailing list. (Well, I am particularly extreme in that even my smartphone runs GNU/Linux, but that is a different story.) And I would argue that GNOME is also a very bad default for users in that category because of its deliberate lack of configurability. Not to mention that the same (concept familiarity) concerns applying to people switching from other operating systems also apply to people switching from any other GNU/Linux desktop environment. Personally, when I tried GNOME 3 once, it took me less than 10 minutes to decide that this is just completely unusable for me personally. So I think it is pretty clear that we do NOT "have two equally good options" as Adam Williamson wrote (in the post to which you were replying). Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Leon Fauster via devel wrote: > I already had RHL installed on a Sun IPX with Gnome, so I'm biased. Interesting that you were not put off by the changes that have happened to GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was actually pretty good. (It was very configurable back then. Remember when it shipped Enlightenment as the window manager, how many options that had?) Then GNOME 2 came, removing much of the configurability of GNOME 1. And then GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME 2, leading to a very hardcoded experience. GNOME 2 was already too much for me, and I switched back to KDE, back because I had already tried KDE 1.1.1 on another distro. And I have never looked back. Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it out once. But it took less than 10 minutes for me to realize that it is not for me. The user experience is just too unfamiliar (the unified application menu and open window selector (launch menu AND task bar replacement), the always maximized windows, the lack of a system tray, the shut down options in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does not make it easy for you to change it. (You can actually get a pretty standard desktop experience nowadays if you install a lot of "unbreak this", "unbreak that" GNOME Shell extensions, but that kinda defeats the point of GNOME.) The default experience felt pretty much unusable to me personally. KDE Plasma not only has more familiar defaults (actually looking and feeling much more similar to GNOME 1 than GNOME 3 does), but also lets you easily change those defaults that you do not like. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Switch to DNF5 (system-wide)
On Wed, Apr 03, 2024 at 11:57:48AM -0700, Adam Williamson wrote: > On Wed, 2024-04-03 at 14:27 -0400, Przemek Klosowski via devel wrote: > > On 4/3/24 06:36, Aoife Moloney wrote: > > > the dnf-automatic command will be obsoleted. > > > > https://dnf5.readthedocs.io/en/latest/changes.html does not say anything > > about automatic updates, and > > > > https://packages.fedoraproject.org/pkgs/dnf5/dnf5-plugin-automatic/ > > > > simply suggests that dns update be executed from systemd timers or cron > > jobs. > > > > > > dns-automatic provided a simple interface to a setup-and-forget > > automatic updates; will DNF5 leave it to be set up by hand? > > > > I am asking because systemd timers have surprising behavior for > > suspendable systems, which leads to problems if updates are scheduled > > for off-hours. > > > > My experience is that even |WakeSystem=true does not make them reliable, > > but I am not sure how to debug this (because the system is suspended, heh). > > > > We do use dnf-automatic quite extensively within infra, I think. Has > this been discussed with infra? Not that I know of. Yes, we do use dnf-automatic all over the place. ;( kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Stephen Smoogen wrote: > Downloads are very hard to measure because too many things are grabbing > everything from mirrors for different reasons. [Plus various people seem > to think manipulating the stats for their particular spin on the number of > downloads will make it more popular (I am looking at the several dozen ips > which were downloading the same spin every ten minutes). The countme > stats for 'running' systems > https://data-analysis.fedoraproject.org/csv-reports/countme/ can probably > give you the data on number of active systems. Countme stats do not tell you though how many of those users actually downloaded their Edition from fedoraproject.org vs. getting it preinstalled by some cloud/VPS/dedicated server provider. If people are not going to fedoraproject.org to download, say, the Cloud Edition or the Server Edition, then it is pointless to feature that particular Edition prominently on fedoraproject.org. That is why I was asking for download statistics specifically. And is there a statistical evaluation of that data somewhere? Downloading 350 MiB (!) of raw CSV data does not sound to me like a convenient way to work with it. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Another route would be to go the Ubuntu route, if you really don't want to > stop having Workstation as the default: Spin (pun intended) the KDE spin > on it's own branding. Though I do understand that is an undertaking on > it's own. It would still be Fedora, about as much as Kubuntu is Ubuntu. > (Though, I don't know about 'Kedora' as it has absolutely no meaning XD) > Though I feel like we should really only go this route if the other ideas > get completely exhausted... That is what I tried with Kannolo. Success was… limited, to say the least. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Andreas Tunek wrote: > From Red Hat's POV it is not Fedora Gnome Workstation ( > https://blogs.gnome.org/uraeus/2020/05/07/gnome-is-not-the-default-for-fedora-workstation/ > ). TL;DR: "We do not want 'GNOME' in the name because we want to only support GNOME in Workstation, whereas 'GNOME Workstation' would imply that there are other Workstations." I am not sure I buy this argument. By the same argument, we should also not call the OS "Fedora Linux" because it implies there is also a "Fedora BSD" or "Fedora Hurd" or even "Fedora Windows" ;-) or something. Giving a product a clear name does not imply existence of another product. (And that is not even arguing the premise of the "one single Workstation that happens to use GNOME" concept, only the branding implications!) > One of the best things with Fedora Workstation is that it is a complete > user facing OS (like Windows, macOS and iOS) that you actually can develop > applications for (if you want to). You don't have to target the extremely > fluffy "Linux desktop", you can target Fedora Workstation. This proposal > would totally eliminate the good points of having this single OS and app > platform. That "conveniently" ignores the existence of that pesky thing called "other distributions". The GNU/Linux version of vendor lock-in. Thanks Red Hat! And besides, a standalone application (as opposed to a desktop widget or similar) developed for one of the Fedora desktop deliverables (Workstation Edition, desktop Spins) is also going to work on any of the others. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > to you? They are quite relevent to others... I would really like to see what the proportion of users downloading the Server, IoT, Cloud, and CoreOS Editions is compared to Workstation or the Spins. I would not expect it to be very high. Most Fedora users are desktop users. And server or cloud users will mostly install Fedora by picking "Fedora" in a combo box at their commercial cloud, VPS, and/or dedicated server provider's web interface, not from fedoraproject.org. I would be surprised if the percentage of users both running a home server or a private cloud (as opposed to a hosted commercial offering in a remote datacenter) AND picking Fedora as the OS to run on it (as opposed to a more conservative OS such as Rocky/Alma or Debian stable) were significant. CoreOS is also mostly a server thing, desktop users get pointed to Atomic Desktop variants (Silverblue/Kinoite/"… Atomic") instead. And IoT is just completely niche. So why do you expect those Editions to be more relevant to users downloading Fedora from fedoraproject.org than the Spins? Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Luis Correia wrote: > I'm mostly a user and I can accept a change from GNOME to KDE, IF and only > if I'm not forced to use Wayland. > > For me it isn't usable in my setup and most things are plain broken. As the maintainer of plasma-workspace-x11 and kwin-x11, I can assure you that that will not be the case. I have been through a whole FESCo debate just to be allowed to maintain those packages. 1. sudo dnf install plasma-workspace-x11 2. Select "Plasma (X11)" as the session type in your display manager. 3. Enjoy! (It is also possible to force SDDM to itself use X11 rather than Wayland, if even SDDM does not work properly under Wayland for you.) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Peter Boy wrote:
> We would be pretty silly if we did that. This differentiation and the
> associated quality and safeguarding criteria are a model for success and
> one of our differentiation criteria.
I think that is a quite pointless "differentiation criteria". Most users do
not even understand the difference between an "Edition" and a "Spin" or
"Lab". And technically, there is none. I do not see how Fedora's success has
anything to do with such an implementation detail.
All this differentiation achieves is creating first-class ("Edition") and
second-class ("Spin" or "Lab") spins, for no benefit whatsoever.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)
Joe Orton wrote: > Given that the ENGINE API is deprecated upstream since OpenSSL 3.0, the > API is optional upstream, and its use has produced compiler warnings > since it was introduced in Fedora 36, it seems perfectly reasonable to > disable this API in Fedora 41. I disagree. Disabling an API that is still widely used and for which there is still no complete replacement (several replies have pointed out issues still preventing "providers" from working in all use cases in which "engines" work) is NOT reasonable. > We have to deal with a very large numbers of FTBFS bugs from e.g. Python > API breaks every other release cycle, or the latest compiler flag > tuning. The fact that the transition creates work for other package > maintainers is obviously not a reasonable blocker for a Fedora Change. And that is exactly the kind of cultural issue we need to solve. The Python 3 transition is exactly an example of a transition that was handled horribly, kicking out lots of useful packages from Fedora just because they were not ported to Python 3. Python 2, or a fork like Tauthon (which has the advantage that it supports some Python 3 features, so some Python-3-only libraries / library versions can be backported to Tauthon more easily than to stock Python 2), should have been retained as a compatibility platform in Fedora. (There is technically still a "python27" package, but the modules available for it are intentionally limited and there are strict rules on what packages are allowed to depend on it.) It should NEVER be considered reasonable to break other people's work. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Putting aside that i heard from Neal Gompa that anaconda cannot > accommodate a « multi-flavor » media, can you imagine how big that iso > would be? Forget 4gb, it’d probably be closer to 20gb! We used to have multiboot live images that let you pick the live image flavor to boot and then install. At one point (for one or two, maybe three, releases only, then came "Fedora.next" and the Ambassadors were pressured to hand out only "Workstation"), we even handed DVDs with those (yes, in those good old days, a multiboot live image still fit on a DVD… then bloat happened!) out at events. (I even did a custom one once for the Vienna event in May 2015, which dual-booted the latest Fedora 21 KDE live-respin with Plasma 4 and the Fedora 22 Beta KDE live with Plasma 5. I did not put Workstation on those because we had tons of pressed Fedora 21 Workstation DVDs anyway.) Unfortunately, the scripts that generated those were unable to keep up with all the complications caused by UEFI and so-called "Secure Boot". (They used to work back when everything still booted in legacy BIOS mode.) So some engineering effort will probably be needed, and a lot of testing on different hardware will definitely be needed, to make the multiboot generator work (reliably) again. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
Eric Blake wrote: > The upstream autoconf discussion says that 'autoreconf -fi' behavior > on which 'serial NN' .m4 files to update is determined by automake, > not autoconf, in part inspired by semantics desired in gnulib. And > the automake and gnulib developers have argued that the upstream > behavior is intentional: > > https://lists.gnu.org/archive/html/bug-autoconf/2024-04/msg5.html Don't you love intentional bugs? Yet another reason to avoid autotools at all costs. By the way, the documentation of the serials "feature" actually warns about this (and seems to imply that even without serials, --force does not work as advertised for those files): https://www.gnu.org/software/automake/manual/html_node/Serials.html | Finally, note that the --force option of aclocal has absolutely no effect | on the files installed by --install. For instance, if you have modified | your local macros, do not expect --install --force to replace the local | macros by their system-wide versions. If you want to do so, simply erase | the local macros you want to revert, and run ‘aclocal --install’. But the documentation of "autoreconf --force" does not include that warning. And this also makes "--force" pretty much useless as it stands. We and Debian both need to patch aclocal downstream immediately to make --force actually work. And then of course Fedora needs to actually always run autoreconf -i -f as Debian already does, or the patch will not do much good. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Wed, Apr 03, 2024 at 04:24:08AM +0200, Kevin Kofler via devel wrote: > Kevin Fenzi wrote: > > Why not the opposite: > > > > Download Workstation > > > > [I'm a linux user and know what I want, just show me the full list of > > downloads, click here]? > > Because that still leads people to click that "Download Workstation" link > before even seeing the options. "I do not want to have to choose" should be > a concious choice, also considering that the mostly unconfigurable (by > design) GNOME is very likely to be the wrong option for anybody not in that > category. And besides: It's still a choice. Just a better presentation IMHO for people who 'do not want to choose'. > > (Which is pretty much what we have now) > > Well, not quite, it is more like: > > [LOGO Workstation (Download Now) (Learn More)] > > [LOGO Server (Download Now) (Learn More)] > > [LOGO IoT (Download Now) (Learn More)] > > [LOGO Cloud (Download Now) (Learn More)] > > [LOGO CoreOS (Download Now) (Learn More)] > > Want more Fedora options? > > Atomic Desktops (Learn More) ← no frame nor logo nor mention of "download" > > Fedora Spins (Learn More) ← no frame nor logo nor mention of "download" > > Fedora Labs (Learn More) ← no frame nor logo nor mention of "download" > > Fedora ALT Downloads (Learn More) ← no frame nor logo > > So you get offered a lot of (most likely) irrelevant (to you) options to you? They are quite relevent to others... Anyhow, I think our positions are pretty clear here, so no need to prolong this subthread. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Wed, Apr 03, 2024 at 06:17:59PM +0200, Leon Fauster via devel wrote: > Am 02.04.24 um 23:32 schrieb Adam Williamson: > > On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote: > > > > > > I am a happy KDE user, since the good old days of version 1.0. I celebrate > > > this decision! My recognition goes to the enormous and sustained work of > > > the entire KDE community. > > > Cheers, > > > Sergiio > > > > To be clear, there is no 'decision'. This is a Change proposal. Any > > Fedora community member can submit a Change proposal proposing just > > about any change; I could submit one tomorrow proposing we abandon all > > software development and open a yak farm instead. > > > > A Change proposal existing is in no way an indication of any ultimate > > outcome. Change proposals can be, and frequently are, rejected. > > > Sorry, for not knowing the process right but where to vote up/down for such > proposal? You can provide your feedback here or in the discussion thread. The actual voting on proposals happens with FESCo members once the proposal has had feedback from the community (and of course if it's not withdrawn, etc). kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Wed, Apr 03, 2024 at 07:27:12AM -0400, Stephen Gallagher wrote: > On Tue, Apr 2, 2024 at 7:41 PM Kevin Fenzi wrote: > > > > On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote: > > > On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette wrote: > > > > > > > > I personally would very much agree with enforcing the use of 2fa on the > > > > Fedora Account System. Maybe take that opportunity to make it a bit > > > > more user friendly? (Such as the fkinit prompt requiring the 2fa code > > > > being added at the end of your password -- to be clear I think the 2fa > > > > code should be separate) > > > > > > https://pagure.io/fedora-packager/pull-request/179 > > > > I agree that fixing the mismatch in prompts might be nice, but why does > > having 2fa seperate make things any better? I mean, it's one more return > > you get to hit. ;) > > > > And... I am not sure about moving the handling of passwords to a bash > > script from a kinit prompt. > > > > The kinit is already being run inside a bash script, so if bash is > compromised with a keylogger, you've already lost the game... I'm not > sure how this is worse. Well, I meant more that now $PASSWORD has your password where before kinit was the only thing you input your password into. :) So, if someone does say a 'sh -x fkinit' to look at something, their password will show up, but it's probibly fine. > Yeah, it's an extra keystroke, but I think there's value in helping > the user provide the input in the proper format. Right now it's > confusing (particularly since the kinit prompt gives bad information > that we have to warn about). Sure. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > Why not the opposite: > > Download Workstation > > [I'm a linux user and know what I want, just show me the full list of > downloads, click here]? Because that still leads people to click that "Download Workstation" link before even seeing the options. "I do not want to have to choose" should be a concious choice, also considering that the mostly unconfigurable (by design) GNOME is very likely to be the wrong option for anybody not in that category. And besides: > (Which is pretty much what we have now) Well, not quite, it is more like: [LOGO Workstation (Download Now) (Learn More)] [LOGO Server (Download Now) (Learn More)] [LOGO IoT (Download Now) (Learn More)] [LOGO Cloud (Download Now) (Learn More)] [LOGO CoreOS (Download Now) (Learn More)] Want more Fedora options? Atomic Desktops (Learn More) ← no frame nor logo nor mention of "download" Fedora Spins (Learn More) ← no frame nor logo nor mention of "download" Fedora Labs (Learn More) ← no frame nor logo nor mention of "download" Fedora ALT Downloads (Learn More) ← no frame nor logo So you get offered a lot of (most likely) irrelevant (to you) options (Server, IoT, Cloud, CoreOS) before even being told that there are more options than those (and Workstation), the "Workstation" link does not tell you that (even though those are clearly workstation/desktop-targeted options too), and you also do not see the full list of options anywhere, but just a list of lists. You actually have to click on "Learn More" after "Fedora Spins" to even see what desktop environments are available. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Adam Williamson wrote:
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next
That was for Fedora 21 in 2014! As you stated it, I know you and I have been
around forever and 2014 feels like yesterday, but it was really quite a long
time ago. ;-)
Now we are planning for Fedora 2*21, which would be a good time to revisit
this decision.
> which was explicitly based around making it much more focused and less of
> a choose-your-own-adventure, specifically including making the download
> page much more opinionated.
Which is exactly what we (KDE users) are complaining about and have been
complaining about for those 10 years. And we know many users have complained
about it, too. If they even found out Fedora supports KDE/Plasma at all,
which not all of them did.
The download page now is not as horrible as it was 10 years ago, but the
main issue (the featuring of the Editions at the expense of everything else,
making the GNOME "Workstation Edition" much more prominent than the other
desktop environment options) is by design and thus still present.
> AFAIR, the numbers Matthew tracks strongly indicate this was associated
> with a very significant immediate bump in Fedora usage.
There is no evidence that this was a consequence of the change itself and
not of the massive marketing done around it. Media loves announcing when
something changes. So if Fedora changes things again to make Editions and
Spins equal, and comes up with a fancy codename (like the old "Fedora.next")
for that ("Fedora.equality"? "Fedora.flexible"? "Fedora.choice"? "Your
Fedora"? Or whatever the marketers can come up with), I expect that we will
get lots of media coverage and another bump in downloads from that.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Steve Cossette wrote: > Sorry, that's pretty much how things are right now, is that what you were > trying to demonstrate? > > I'm not really following. Not really. The current design is better than those old designs that immediately served you an ISO when you clicked "Download now", but the focus is still on the Editions (which are framed and have logos) at the expense of the Spins and the other options (which have neither frames nor logos). Clicking on Workstation then gives you a selection of architectures, but not of desktop environments; for those, you have to find and pick the (much less prominent) Spins option on the front page instead. I think the first thing to offer users should be the Spins (including the "Workstation Edition" which is technically no different from a Spin). Most users are looking for a desktop distribution. The non-desktop options should come last, after all the desktop-ish (desktop, mobile, lab, and atomic) options. Fedora 21 has introduced the Editions vs. Spins distinction, Fedora 2*21=42 would be a good time to retire it. And selecting a desktop/workstation download should require you to select the desktop environment, with a skip option clearly labeled something like "I do not want to choose" or "Options confuse me" (or "I HATE OPTIONS!" as I had called it somewhat hyperbolically), which happens to be a pretty good description of the GNOME design philosophy. Or maybe even just: (·) GNOME (default) A desktop environment focused on ease of use **Pick this option if questions like this one confuse you.** ( ) KDE Plasma Desktop A highly customizable desktop environment ( ) Xfce A lightweight desktop environment etc. But there should be no link directly to any GNOME Edition/Spin/whatever (except Labs, if that specific Lab exists only as a GNOME-based version) without a clearly visible selection of desktop environments (which is unfortunately what the current "Workstation" link is). (And for Labs, the selection should at least visibly state somewhere what desktop environment they are based on, an information which some Labs now put in their description, requiring an extra click to see it, and some not even there.) Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Wed, Apr 03, 2024 at 02:36:07AM +0200, Kevin Kofler via devel wrote: > Kevin Fenzi wrote: > > Ok, thats obvously somewhat tounge in cheek, but if we promote multiple > > things, we need some way to describe them to uses who might not know the > > history of things and do it in a quick enough way that they won't decide > > it's all confusing and go do something else. > > It is actually quite simple: > > Here are your options: Why not the opposite: Download Workstation [I'm a linux user and know what I want, just show me the full list of downloads, click here]? (Which is pretty much what we have now) kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
Kevin Fenzi wrote: > Ok, thats obvously somewhat tounge in cheek, but if we promote multiple > things, we need some way to describe them to uses who might not know the > history of things and do it in a quick enough way that they won't decide > it's all confusing and go do something else. It is actually quite simple: Here are your options: [I HATE OPTIONS, JUST GIVE ME SOMETHING WITH NO OPTIONS!] (big button) → downloads GNOME x86_64 DESKTOP SPINS: Desktop: ( ) GNOME (Workstation) ( ) KDE Plasma Desktop ( ) Xfce etc. Architecture: ( ) x86_64 (64-bit x86/AMD64) ( ) aarch64 (64-bit ARM) etc. [DOWNLOAD SELECTED] MOBILE SPINS: Mobile Environment: ( ) Phosh etc. Architecture: ( ) aarch64 (64-bit ARM) etc. [DOWNLOAD SELECTED] LABS: Lab: ( ) Astronomy etc. Architecture: etc. [DOWNLOAD SELECTED] ATOMIC DESKTOPS: Desktop: ( ) GNOME (Silverblue) ( ) KDE Plasma Desktop (Kinoite) ( ) Sway (Atomic) ( ) Budgie (Atomic) Architecture: etc. [DOWNLOAD SELECTED] OTHER EDITIONS: Edition: ( ) Server etc. Architecture: etc. [DOWNLOAD SELECTED] Of course there is going to be a lot of bikeshedding about the order of the options. I would put them in that order, because I think desktop spins are most likely to be downloaded by a new user, then mobile, then use-case- specific labs, then experiments like Atomic, and then non-desktop stuff like Server. But the most important feature is the "I HATE OPTIONS!" button, because it serves exactly the users you think will be confused by the options and will give them a desktop environment designed exactly for them. Kevin Kofler -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)
On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote: > Alright, so a substantial amount of information changed since the original > submission of the change proposal. We aren't necessarily thinking of > demoting Gnome. The overall spirit of the CP is that we think KDE, and to > some extent the other spins too, need a bit more visibility on the website. > At the very least, Gnome and KDE should be up front on the frontpage. So, I am far from a web designer, but if you aren't a Linux savvy person and just decided to try out this Fedora thing because you heard it was nice and you go to download it and get: our website: Want a workstation? user: yes! our website: great! We have Gnome and KDE! user: what? what does that mean? which one should I get? our website: Gnome: "Get things done with ease, comfort, and control. An easy and elegant way to use your computer, GNOME is designed to help you have the best possible computing experience." KDE: "Powerful, multi-platform, and for everyone Use KDE software to surf the web, keep in touch with colleagues, friends and family, manage your files, enjoy music and videos; and get creative and productive at work. The KDE community develops and maintains more than 200 applications which run on any Linux desktop, and often other platforms too." User: ok, that didn't tell me much, whats the difference? perhaps I will just keep using windows. Ok, thats obvously somewhat tounge in cheek, but if we promote multiple things, we need some way to describe them to uses who might not know the history of things and do it in a quick enough way that they won't decide it's all confusing and go do something else. kevin signature.asc Description: PGP signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
