Re: Orphaned python-astunparse
Am 17.06.24 um 16:05 schrieb Miro Hrončok: python-astunparse is currently broken on Python 3.13 and I have not investigated why. The latest upstream commit is 5 years old. Comment from the upstream issue tracker: "In theory, no current Python package supporting Python since version 3.9 should be required to use this package, as the functionality is available in the stdlib now: https://docs.python.org/3/library/ast.html#ast.unparse python/cpython@27fc3b6" https://github.com/simonpercivall/astunparse/issues/67#issuecomment-1438351272 So I guess it is really not worth keeping this package alive in Fedora. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
[SPDX] Mass license change GPLv2+ to GPL-2.0-or-later
Hi. I am going to do the mass change of the license from GPLv2+ to GPL-2.0-or-later The proposed diff is too big to be attached. So here is a link https://k00.fr/bsjujpgb Affected packages: abcde abcMIDI abook AcetoneISO acpi acpitool admesh adplug afuse aiksaurus airspyone_host algobox alienblaster alsa-firmware alsamixergui ampr-ripd ams amsynth amtterm anaconda-realmd analitza anyterm apfs-fuse apmd aprsd apvlv argtable archivemount aria2 ark arm-image-installer arp-scan arptables arrows arts asc asciiquarium asc-music aspell-pa aspell-te astrometry atari800 aterm atkmm2 AtomicParsley atool attica audacious-plugin-fc audacious-plugins audiotube auriferous authd auto-buildrequires autoconf213 avra awesfx axmail ax25-tools backintime backup-light BackupPC ballbuster balsa barcode bcm43xx-fwcutter beansbinding beediff beep beesu berusky berusky-data berusky2 berusky2-data bes bchunk bindfs bio2jack bitlbee-steam bkhive bless blinken BlockOutII bluez-hcidump bluez-tools boinc-client bolzplatz2006 boswars-addons bridge-utils brutalchess bst-external bubblemon bwbar bwrap-oci byteman cabextract cadaver Cadence caja caja-extensions calligra cambozola caribou castget ccache ccd2iso ccrtp ccsm cdargs cdcollect cd-discid cdrdao cdw centerim certwatch cf-bonveno-fonts cflow cinnamon-desktop cinnamon-menus cinnamon-translations cksfv clanbomber clearlooks-compact-gnome-theme cloc cloog cloudcompare clthreads clustal-omega clustershell clutter clutter-gst3 clutter-gtk cluttermm clxclient cmconvert cmospwd cobbler cogl coldet commoncpp2 compiz-bcop compizconfig-python compiz-plugins-experimental compiz-plugins-main compsize connect-proxy consolation cpipe cpl cpphs cpptest cptutils cpuid cpulimit CQRlib crack-attack CriticalMass csound ctan-cm-lgc-fonts cups-x2go cvs2cl cxxtools cyrus-timezones daa2iso dar davix dbench dbus-c++ dbus-qt3 ddccontrol ddccontrol-db ddclient ddcutil dd2 debbuild d-feet dfu-util dhex dia-CMOS dia-Digital dia-electric2 dia-electronic dia-optics did dieharder diffpdf digikam direwolf ditaa djview4 djvulibre dkms dl dmapd dmraid dmtx-utils dnfdaemon dnf-plugin-diff drbd drgeo drumkv1 drumstick0 dssi dtach dumpet dustin-domestic-manners-fonts dustin-dustismo-fonts dvblast dvdisaster dxcc dymo-cups-drivers easytag eblook ebtables ebumeter eiciel elementary emacs-async emacs-common-ddskk emacs-common-riece emacs-lua emacs-rpm-spec-mode emacs-spice-mode emacs-yaml-mode emerald enblend engauge-digitizer enchant enigma enki epson-inkjet-printer-escpr epson-inkjet-printer-escpr2 epstool esound etckeeper ethstatus exaile exim extrema fail2ban fakechroot fapg fastback fbb fbida fcitx-anthy fcitx-cloudpinyin fcitx-configtool fcitx-fbterm fcitx-hangul fcitx-chewing fcitx-m17n fcitx-sunpinyin fcitx-table-extra fcitx-ui-light fcitx5 fcitx5-anthy fcitx5-configtool fcitx5-gtk fcitx5-chewing fcitx5-chinese-addons fcitx5-libthai fcitx5-lua fcitx5-m17n fcitx5-rime fcitx5-sayura fctxpd fedpkg fedpkg-minimal fetchlog ffsb fftw2 figtoipe fig2ps fillets-ng firefox-pkcs11-loader FlightGear FlightGear-Atlas FlightGear-data flobopuyo flowcanvas fltk fluid fmf fmtools fmt-ptrn fpm2 freedroid FreeSOLID frei0r-plugins fros fs_mark fspy ftplib fusion-icon fvwm f2fs-tools game-music-emu games-menus gammaray gammu gargi-fonts gcab gcstar gdlmm gearhead2 gedit-plugins geeqie genromfs geomview ghc-HaXml gifsicle gimp-dds-plugin gimp-high-pass-filter gimp-lqr-plugin gimp-luminosity-masks gimp-resynthesizer gip git-evtag gitg git2cl gkermit gkrellm-wifi glaxium gle glib gmediarender gmm gnome-battery-bench gnome-bluetooth3 gnome-common gnome-desktop-testing gnome-multi-writer gnome-panel gnome-screenshot gnome-sharp gnome-shell-extension-suspend-button gnome-themes-extra gnome-user-share gnucap gnulib gnurobbo gnusim8085 goaccess goffice goocanvas goocanvas2 gparted gpredict gpsman gputils gpx-viewer gq grace grantlee-qt5 graphlcd-base grepcidr grfcodec grhino gridloc grilo-plugins grip grisbi gromacs gshutdown gsim85 gssdp gstreamermm gstreamer-plugins-espeak gstreamer-plugins-fc gstreamer1-plugin-libav gstreamer1-rtsp-server gstreamer1-vaapi gt gtk+ gtkdatabox gtk+extra gtk-gnutella gtkhash gtkimageview gtkmm2 gtk-sharp2 gtksourceviewmm gtksourceview3 gtksourceview4 gtk-splitter gtk-v4l gtk-xfce-engine gtk2 gtk2-engines guake guitarix gupnp-av gupnp-dlna gwenview hatari hatools hawknl hddtemp HepMC Hermes hexchat hfsutils hidrd hnb homebank htop htppu httperf httrack hw-probe hydrogen CheMPS2 chmlib chocolate-doom chromaprint chunkfs iaxclient icebreaker icecream icemon id3lib id3v2 iec16022 imlib2 imwheel inchi ipe ipxripd irclog2html irc-otr irda-utils irstlm is-it-in-rhel isync ivykis iwd jabberd jconvolver jfreechart jfsutils jgmenu jkmeter jpegoptim jpilot-backup Judy jumpnbump kafs-client kamoso kanagram kanatest kapptemplate kate kbibtex kbilliards kbruch kcalc kcm_systemd kcm_wacomtablet kcron kdb kdebugsettings kdegraphics-mobipocket kdelibs kdelibs3 kdepimlibs kde-runtime kdesdk-thumbnailers kde-style-breeze
[SPDX] Mass license change ASL 2.0 to Apache-2.0
Hi. I am going to do the mass change of the license from ASL 2.0 to Apache-2.0 The proposed diff is too big to be attached. So here is a link https://k00.fr/tkbg4k81 Affected packages: adapt adb-enhanced american-fuzzy-lop apache-cloudstack-cloudmonkey apache-commons-digester apache-commons-modeler apache-commons-pool apr-api-docs armadillo artifacts astral auter auto binaryen bpytop budgie-desktop-view cantoolz cffconvert cld2 codehaus-parent configsnap cotila creds cri-o dib-utils dmlite dnsperf docker-compose docker-distribution domtt edg-mkgridmap elixir email2trac eralchemy erlang-js erlang-p1_acme erlang-riak_kv erlang-riak_pb exec-maven-plugin facter fernflower fetch-crl fluent-bit fts-rest-client gfalFS gfal2 gfal2-python gfal2-util git-pull-request git-review git-secrets gobuster golang-ariga-atlas golang-code-cloudfoundry-clock golang-contrib-opencensus-integrations-ocsql golang-contrib-opencensus-resource golang-entgo-ent golang-github-abbot-http-auth golang-github-adalogics-fuzz-headers golang-github-akamai-akamaiopen-edgegrid golang-github-alibabacloud-debug golang-github-alibabacloud-tea golang-github-aliyun-alibaba-cloud-sdk golang-github-aliyun-credentials golang-github-apache-beam-2 golang-github-appc-docker2aci golang-github-appc-spec golang-github-bradfitz-gomemcache golang-github-casbin-2 golang-github-census-instrumentation-opencensus-proto golang-github-census-instrumentation-opencensus-proto-0 golang-github-cockroachdb-cmux golang-github-cockroachdb-cockroach-go golang-github-cockroachdb-datadriven golang-github-cockroachdb-logtags golang-github-cockroachdb-redact golang-github-containerd-aufs golang-github-containerd-btrfs golang-github-containerd-imgcrypt golang-github-containerd-zfs golang-github-denverdino-aliyungo golang-github-dimchansky-utfbom golang-github-dreamacro-shadowsocks2 golang-github-envoyproxy-protoc-gen-validate golang-github-euank-kmsg-parser golang-github-fnproject-fdk golang-github-git-fixtures-4 golang-github-gocolly-colly-2 golang-github-gogo-status golang-github-gomodule-redigo golang-github-googleapis-gnostic golang-github-google-btree golang-github-google-dap golang-github-google-gousb golang-github-google-jsonnet golang-github-google-martian golang-github-google-renameio golang-github-google-replayers golang-github-google-wire golang-github-gophercloud golang-github-groupcache golang-github-grpc-ecosystem-prometheus golang-github-haproxytech-client-native golang-github-haproxytech-config-parser golang-github-haproxytech-logger golang-github-iglou-eu-wildcard golang-github-iij-doapi golang-github-inconshreveable-vhost golang-github-infobloxopen-infoblox-client golang-github-instrumenta-kubeval golang-github-jacobsa-oglematchers golang-github-jacobsa-ogletest golang-github-jacobsa-reqtrace golang-github-jcmturner-aescts golang-github-jcmturner-dnsutils golang-github-jcmturner-goidentity golang-github-jcmturner-rpc golang-github-jmespath golang-github-jsonnet-bundler golang-github-krishicks-yaml-patch golang-github-kurin-blazer golang-github-kylelemons-godebug golang-github-linkedin-goavro golang-github-liquidweb golang-github-lyft-protoc-gen-star golang-github-masterminds-goutils golang-github-masterzen-simplexml golang-github-masterzen-winrm golang-github-mattbaird-jsonpatch golang-github-matttproud-protobuf-extensions golang-github-mindprince-gonvml golang-github-minio-md5-simd golang-github-minio-6 golang-github-moby-spdystream golang-github-mock golang-github-mwitkow-conntrack golang-github-nats-io-jwt golang-github-nats-io-nkeys golang-github-nats-io-nuid golang-github-nbrownus-metrics-prometheus golang-github-netflix-expect golang-github-nozzle-throttler golang-github-oklog golang-github-oklog-run golang-github-oneofone-xxhash golang-github-openapi-analysis golang-github-openapi-jsonpointer golang-github-openapi-jsonreference golang-github-openapi-loads golang-github-openapi-spec golang-github-openapi-strfmt golang-github-openapi-swag golang-github-opendns-vegadns2client golang-github-opentracing golang-github-opentracing-contrib-grpc golang-github-opentracing-contrib-stdlib golang-github-openzipkin-zipkin golang-github-oxtoacart-bpool golang-github-pdfcpu golang-github-pengsrc-shared golang-github-peterbourgon-ff-3 golang-github-pires-proxyproto golang-github-planetscale-tengo golang-github-posener-autogen golang-github-posener-script golang-github-pquerna-ffjson golang-github-pquerna-otp golang-github-prometheus golang-github-rackspace-gophercloud golang-github-rainycape-memcache golang-github-rainycape-unidecode golang-github-rakyll-statik golang-github-sacloud-libsacloud golang-github-safchain-ethtool golang-github-simonpasquier-klog-gokit golang-github-soheilhy-cmux golang-github-spacemonkeygo-monkit golang-github-sql-civil golang-github-stefanberger-pkcs11uri golang-github-stomp golang-github-stomp-3 golang-github-twitchtv-twirp golang-github-uber-jaeger-client golang-github-uber-jaeger-lib golang-github-unknwon-com golang-github-unknwon-g
Planned Outage - wiki - 2024-06-18 21:00 UTC
Planned Outage - wiki - 2024-06-18 21:00 UTC There will be an outage starting at 2024-06-18 21:00 UTC which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2024-06-18 21:00UTC' Reason for outage: We will be upgrading the wiki to a newer version. During this outage the wiki will be down. Affected Services: https://fedoraproject.org/wiki Ticket Link: https://pagure.io/fedora-infrastructure/issue/11994 Please join #fedora-admin or #fedora-noc on irc.libera.chat or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix. Please add comments to the ticket for this outage above. Updated status for this outage may be available at https://www.fedorastatus.org/ 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
Re: [SPDX] Mass license change GPLv3+ to GPL-3.0-or-later
Miroslav Suchý wrote: > I am going to do the mass change of the license from GPLv3+ to > GPL-3.0-or-later I changed the subject line accordingly. > aws Please exclude AWS. The license change is already in the pipeline, mixed with a big batch of changes that will take some time for me to review. It will get done eventually. You'd just make it necessary to rebase a bunch of commits yet again. Björn Persson pgp5OKpAU7ui7.pgp Description: OpenPGP digital signatur -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2FA policy for provenpackagers is now active
Proven packagers, we changed [2,3] the FESCo policy document [1] for provenpackagers to say: "Provenpackagers SHOULD have two-factor-authentication (2FA) enabled for their FAS accounts." This is not enforced or checked, but please take steps to conform to the policy if you haven't yet. [1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ [2] It's not visible on the web yet, because antora is doing its thing … slowly. [3] https://pagure.io/fesco/issue/3186 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
Re: Schedule for Monday's FESCo Meeting (2024-06-17)
= # #meeting:fedoraproject.org: fesco = Meeting started by @sgallagh:fedora.im at 2024-06-17 19:00:05 Meeting summary --- * TOPIC: Init Process (@sgallagh:fedora.im, 19:00:31) * TOPIC: #3222 Change: Make Tuned the Default Power Profile Management Daemon (@sgallagh:fedora.im, 19:12:35) * TOPIC: Next week's chair (@sgallagh:fedora.im, 19:50:59) * ACTION: zbyszek to chair the next meeting (@sgallagh:fedora.im, 19:53:23) * TOPIC: Open Floor (@sgallagh:fedora.im, 19:53:30) * ACTION: @sgallagh to submit a Change to migrate Fedora ELN away from ODCS (@sgallagh:fedora.im, 20:04:29) Meeting ended at 2024-06-17 20:06:17 Action items * zbyszek to chair the next meeting * @sgallagh to submit a Change to migrate Fedora ELN away from ODCS People Present (lines said) --- * @sgallagh:fedora.im (76) * @conan_kudo:matrix.org (71) * @zbyszek:fedora.im (38) * @nirik:matrix.scrye.com (25) * @salimma:fedora.im (24) * @zodbot:fedora.im (12) * @decathorpe:fedora.im (11) * @humaton:fedora.im (4) * @meetbot:fedora.im (3) * @blackwell:fedora.im (1) * @jsteffan:fedora.im (1) Full meeting notes: https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-06-17/fesco.2024-06-17-19.00.log.html On Mon, Jun 17, 2024 at 8:21 AM Stephen Gallagher wrote: > > Following is the list of topics that will be discussed in the > FESCo meeting Monday at 19:00 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-06-17 19:00 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: Multiple Versioned CRI-O and CRI-Tools Packages > https://pagure.io/fesco/issue/3218 > APPROVED (+6, 0, 0) > > Change: IBus Chewing for Traditional Chinese (Taiwan) Desktop by Default > https://pagure.io/fesco/issue/3217 > APPROVED (+6, 0, 0) > > Change: DNF and bootc in Image Mode Fedora variants > https://pagure.io/fesco/issue/3216 > APPROVED (+5, 0, 0) > > > = Followups = > > > = New business = > > #3222 Change: Make Tuned the Default Power Profile Management Daemon > https://pagure.io/fesco/issue/3222 > > = 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. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Orphaned python-astunparse
On 17-06-2024 16:05, Miro Hrončok wrote: Hello. I orphaned python-astunparse. It used to be a dependency of python-gast (a dependency of pythran), but it is no longer so since at least Fedora 36. Thanks for the heads up. python-astor is the only dependent package in Rawhide, seems to be a leaf. It's a test dependency for python-astor used only for a handful of optional tests. I removed it. python-astunparse is currently broken on Python 3.13 and I have not investigated why. The latest upstream commit is 5 years old. https://bugzilla.redhat.com/2279984 Time to let it go. -- Sandro -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: GIMP Version 3 (self-contained)
On Sun, Jun 16, 2024 at 05:24:10PM +0100, Aoife Moloney wrote: > This new version involves substantial changes to the technologies > used, which in turn means that third party plugins have to be ported > to be compatible. Therefore, this change will add the new version as a > new package gimp3 which can be installed side-by-side > with the existing version 2.x package, so people can continue working > on existing projects with the old gimp version and its plugins. The naming of the srpm / dist-git repos is fine. But please call the binary rpm with the new version 'gimp' and the binary rpm with the old version 'gimp2' in F41+. We want users to be upgraded to gimp-3 when they update the system. It's fine if they then install gimp-2 for compat reasons. But the upgrade should be automatic. Also, the new version should carry normal appinfo metadata so it shows up in the graphical search, etc. > In order to make upgrades seamless for users (and avoid having to go > through an exception process for a “new” gimp2 package > needing Python 2.x), the existing package will remain named > gimp and it plus gimp3 will obsolete the > version 2.x packages from Fedora Linux <= 40 in version 41. This statement is dubious. As you wrote yourself in the earlier thread, there is an automatic exception to the review process for compat packages. The guidelines indeed don't say anything explicitly about compat packages depending on deprecated packages, but it seems reasonable to assume this does not introduce the requirement of a FPC review. (Consider: you can certainly keep gimp==2 and add gimp3==3 without review. But if instead gimp2==2 is added and gimp is updated to 3, no new dependency on the deprecated package is introduced. So nothing changes for the distro, and this should be treated the same.) The guidelines [1] say this: > other packages in Fedora MUST NOT add a dependency on a deprecated > package (that includes Requires, BuildRequires, Recommends, > Suggests, etc.). This applies both for updates of existing packages > and new packages added to Fedora. Those submitting new packages, > along with package reviewers, MUST check to see if any dependencies > of the package they are submitting or reviewing have been > deprecated. (It is, however, acceptable for a deprecated package to > be renamed.) I'm not sure what this last sentence is trying to say. It is a non-sequitur to the earlier text, *unless* the intent was actually to say something different: "It is, however, acceptable for a package requiring a deprecated package to be renamed." ?? Either way, I think we should clarify the guidelines to allow this. Please drop this para from the Change page. People are already confused about requirements for compat packages, and I think this paragraph is not needed and will only cause additional confusion. [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/#_consequences_of_a_package_being_deprecated > == Feedback == The gimp3 package in F40 has: /usr/bin/gimp-2.99 /usr/bin/gimp-console-2.99 /usr/bin/gimp-script-fu-interpreter-3.0 /usr/bin/gimp-test-clipboard-2.99 Please make this 'gimp3' and 'gimp3-console' (so that the users can use stable names. This is the style of naming of binaries that compat python versions use.) 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
Re: F41 Change Proposal: GIMP Version 3 (self-contained)
On Mon, 2024-06-17 at 14:00 -0400, Przemek Klosowski via devel wrote: > On 6/17/24 02:39, Vitaly Zaitsev via devel wrote: > > On 16/06/2024 18:24, Aoife Moloney wrote: > > > This release of Fedora Linux ships version 3 of the GNU Image > > > Manipulation Program, with many new features and improved user > > > experience. The package is called gimp3, the old > > > version > > > will still be available under the old name, gimp for > > > users who need it for existing projects. > > > > +1 to the proposal, but -1 to the quoted statement. > > > > GIMP 3 should go to the gimp package and the gimp2 legacy > > compatibility package should be introduced. > > > Vitaly got it right---it should be a major exception to introduce > versioned software naming, i.e. only when there are major system- > level > implications, like for Python2->3 transition. I do appreciate that > people may have gimp application-level workflows [1] but Fedora > should > not be expected to fix them, given the upstream policy of releasing > the > new GIMP. I don't agree with you , First where it is write that major release must be the un-version package ? keep gimp2 as gimp and do gimp3 package will not force modify any other package and we won't have broken things , which may happen if you build one package for gimp2 when there is gimp3 already and no one notice, but that is my opinion . Historically we got some cases , like wxGTK, wxGTK3, openjpeg and openjpeg2 ( btw openjpeg is not used by any package and openjpeg2 should move to openjpeg ) > Speaking of gimp2, it looks like the GIMP upstream is planning to > publish a gimp 2.10.x stable branch > https://developer.gimp.org/core/roadmap/ but with a low priority. > > [1] obligatory XKCD reference: https://m.xkcd.com/1172/ > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/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 -- Sérgio M. B. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: GIMP 3.0 in F41?
On Wed, May 15, 2024 at 10:27:33AM +0200, Vít Ondruch wrote: > > Dne 13. 05. 24 v 23:22 Nils Philippsen napsal(a): > > On Mon, 2024-05-13 at 14:58 +0200, Vít Ondruch wrote: > > > Why would you push Gimp 3 into Fedora <= 40? > > Why wouldn’t I? It’s technically feasible without really jumping > > through hoops, and I don’t want to force users to upgrade the OS – or > > wait for Fedora 41 to be at a level of stability acceptable to them – > > before they can use the new version. > > > I am not against Gimp 3 in F40 and older per se. But the issue is that it > drives you towards `gimp3` for compatibility reasons. IOW I think that it > would be perfectly fine to have Gimp 2 (gimp package) as default in F40 and > Gimp 3 (still gimp package) in F41+. Because while they might be > substantially different, the change happens with major Fedora version and > users should be prepared for such changes. > > IOW situation would be much easier if `gimp` package was Gimp 2 up until F40 > and Gimp 3 since F41. Optionally, it would also make sense to provide > `gimp2` package in F41 for backward compatibility. That is all true, but this approach is still compatible with the way that the repos and srpms are named. It's entirely fine to build gimp.srpm → gimp.rpm and gimp3.srpm → gimp3.rpm in F40, and gimp.srpm → gimp2.rpm and gimp3.srpm → gimp.rpm in F41+. This is similar to how python3.rpm is currently build from python3.12.srpm in F40 and python3.13.srpm in F41. 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
Re: F41 Change Proposal: GIMP Version 3 (self-contained)
On 6/17/24 02:39, Vitaly Zaitsev via devel wrote: On 16/06/2024 18:24, Aoife Moloney wrote: This release of Fedora Linux ships version 3 of the GNU Image Manipulation Program, with many new features and improved user experience. The package is called gimp3, the old version will still be available under the old name, gimp for users who need it for existing projects. +1 to the proposal, but -1 to the quoted statement. GIMP 3 should go to the gimp package and the gimp2 legacy compatibility package should be introduced. Vitaly got it right---it should be a major exception to introduce versioned software naming, i.e. only when there are major system-level implications, like for Python2->3 transition. I do appreciate that people may have gimp application-level workflows [1] but Fedora should not be expected to fix them, given the upstream policy of releasing the new GIMP. Speaking of gimp2, it looks like the GIMP upstream is planning to publish a gimp 2.10.x stable branch https://developer.gimp.org/core/roadmap/ but with a low priority. [1] obligatory XKCD reference: https://m.xkcd.com/1172/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: [SPDX] Mass license change GPL+ to GPL-1.0-or-later
On Mon, Jun 17, 2024 at 4:24 PM Miroslav Suchý wrote: > > Dne 15. 04. 24 v 8:53 dop. Miroslav Suchý napsal(a): > > > > I am going to do the mass change of the license from GPL+ to > > GPL-1.0-or-later > > > Done. It appears that your script had issues. There are a lot of packages that were rebuilt without pushing any changes to them, for example: https://src.fedoraproject.org/rpms/thunar-sendto-clamtk See also: https://pagure.io/releng/issue/12167 Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)
> Wiki - https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot > * Other Developers: No work required from other Fedora developers. The > only requirement outside of the scope of the proposal owners is to > reintroduce AppStream metadata into the Nvidia driver repo on > RPMFusion.org. I wont be re-adding the AppStream metadata into the Nvidia driver repo until someone files a proper request at rpmfusion. https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Infrastructure -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)
On Mon, 2024-06-17 at 12:44 +0100, Aoife Moloney wrote: > Wiki - > https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot > Discussion Thread - > https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-installation-with-secure-boot-support-self-contained/120330 > > This is a proposed Change for Fedora Linux. > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if > approved > by the Fedora Engineering Steering Committee. > > > == Summary == > > Nvidia Drivers have been removed from GNOME Software because it > didn't > support Secure Boot which is increasingly often enabled. This change > brings the option back with Secure Boot supported. > > == Owner == > > * Name: [[User:eischmann|Jiří Eischmann]] > * Name: Milan Crha > > * Email: eischm...@redhat.com > * Email: mc...@redhat.com > > > == Detailed Description == > > The goal is this change is to provide an easy way to install Nvidia > drivers in Fedora Workstation. It was removed from GNOME Software > because the original mechanism didn't support Secure Boot. When users > installed the drivers with Secure Boot enabled, they could not boot > the OS. > What we're doing this time is using mokutil to create a key for the > user to self-sign the drivers. When installing the drivers, the user > is asked to provide a password for the key. On the next reboot the > user is presented with the mokutil interface to enroll the key. I don't know if you are aware akmods already support secure boot since F36 [1] and in "Importing the key" is described on enroll the public self sign key [1] https://rpmfusion.org/Howto/Secure%20Boot > See the > [https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034 > upstream merge request] for more details and screenshots. > > == Feedback == > > > == Benefit to Fedora == > The Nvidia drivers are necessary not only for gaming, but especially > for CUDA and AI/LLM workloads. The Nvidia drivers can't be part of > Fedora because of their license, but Fedora should offer an easy > installation of them to stay relevant in the respective fields. > > == Scope == > > * Proposal Owners: The feature will be implemented in GNOME Software > 47 and will be shipped in the gnome-software package in Fedora Linux > 41. > > * Other Developers: No work required from other Fedora developers. > The > only requirement outside of the scope of the proposal owners is to > reintroduce AppStream metadata into the Nvidia driver repo on > RPMFusion.org. > > * Release Engineering: > > * Policies and Guidelines: > > * Trademark approval: > > * Alignment with Community Initiatives: > > == Upgrade/compatibility impact == > > No impact is expected. > > == How To Test == > > 1. Open GNOME Software. > 2. Search for "nvidia". > 3. Choose the Nvidia driver, click Install and follow the > prompts. > 4. Reboot and enroll the self-signing key in the mokutil tool > following <> > 5. The OS should boot up with the Nvidia driver enabled. > > == User Experience == > > This change aims to improve user experience of installing the > proprietary Nvidia driver. > > == Contingency Plan == > If the feature is not implemented on time for Fedora Linux 41, we can > simply remove AppStream metadata from the Nvidia driver repo and the > driver will not show up in GNOME Software like in Fedora Linux 40. > > == Documentation == > The GNOME Software part is intuitive and doesn't require > documentation. The mokutil part is less intuitive and will be > documented in the Fedora Workstation section on > docs.fedoraproject.org. The docs will be published when the feature > lands in Fedora Linux 41. > > == Release Notes == > > -- > Aoife Moloney > > Fedora Operations Architect > > Fedora Project > > Matrix: @amoloney:fedora.im > > IRC: amoloney > -- > ___ > 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://p
Re: [SPDX] Mass license change GPL+ to GPL-1.0-or-later
Dne 15. 04. 24 v 8:53 dop. Miroslav Suchý napsal(a): I am going to do the mass change of the license from GPL+ to GPL-1.0-or-later Done. -- Miroslav Suchy, RHCA Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Orphaned python-astunparse
Hello. I orphaned python-astunparse. It used to be a dependency of python-gast (a dependency of pythran), but it is no longer so since at least Fedora 36. python-astor is the only dependent package in Rawhide, seems to be a leaf. python-astunparse is currently broken on Python 3.13 and I have not investigated why. The latest upstream commit is 5 years old. https://bugzilla.redhat.com/2279984 -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
On Mon, Jun 17, 2024 at 2:37 PM Chris Adams wrote: > > Once upon a time, Daniel P. Berrangé said: > > I think I've convinced upstream to change their approach to make their > > recent changes a compile-time opt-in, to allow build time choice of the > > non-optimized code, rather than forcing it on everyone. So hopefully > > we don't need todo anything in Fedora now. > > Since this seems to be performance related, any chance Fedora can > provide both a baseline and a x86-64-v2 version, maybe with a wrapper to > automatically choose the correct verion? You mean ... like this? https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance on individual packages requiring x86_64-v2 baseline ?
Once upon a time, Daniel P. Berrangé said: > I think I've convinced upstream to change their approach to make their > recent changes a compile-time opt-in, to allow build time choice of the > non-optimized code, rather than forcing it on everyone. So hopefully > we don't need todo anything in Fedora now. Since this seems to be performance related, any chance Fedora can provide both a baseline and a x86-64-v2 version, maybe with a wrapper to automatically choose the correct verion? -- Chris Adams -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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-06-17)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:00 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-06-17 19:00 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: Multiple Versioned CRI-O and CRI-Tools Packages https://pagure.io/fesco/issue/3218 APPROVED (+6, 0, 0) Change: IBus Chewing for Traditional Chinese (Taiwan) Desktop by Default https://pagure.io/fesco/issue/3217 APPROVED (+6, 0, 0) Change: DNF and bootc in Image Mode Fedora variants https://pagure.io/fesco/issue/3216 APPROVED (+5, 0, 0) = Followups = = New business = #3222 Change: Make Tuned the Default Power Profile Management Daemon https://pagure.io/fesco/issue/3222 = 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. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-installation-with-secure-boot-support-self-contained/120330 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Nvidia Drivers have been removed from GNOME Software because it didn't support Secure Boot which is increasingly often enabled. This change brings the option back with Secure Boot supported. == Owner == * Name: [[User:eischmann|Jiří Eischmann]] * Name: Milan Crha * Email: eischm...@redhat.com * Email: mc...@redhat.com == Detailed Description == The goal is this change is to provide an easy way to install Nvidia drivers in Fedora Workstation. It was removed from GNOME Software because the original mechanism didn't support Secure Boot. When users installed the drivers with Secure Boot enabled, they could not boot the OS. What we're doing this time is using mokutil to create a key for the user to self-sign the drivers. When installing the drivers, the user is asked to provide a password for the key. On the next reboot the user is presented with the mokutil interface to enroll the key. See the [https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034 upstream merge request] for more details and screenshots. == Feedback == == Benefit to Fedora == The Nvidia drivers are necessary not only for gaming, but especially for CUDA and AI/LLM workloads. The Nvidia drivers can't be part of Fedora because of their license, but Fedora should offer an easy installation of them to stay relevant in the respective fields. == Scope == * Proposal Owners: The feature will be implemented in GNOME Software 47 and will be shipped in the gnome-software package in Fedora Linux 41. * Other Developers: No work required from other Fedora developers. The only requirement outside of the scope of the proposal owners is to reintroduce AppStream metadata into the Nvidia driver repo on RPMFusion.org. * Release Engineering: * Policies and Guidelines: * Trademark approval: * Alignment with Community Initiatives: == Upgrade/compatibility impact == No impact is expected. == How To Test == 1. Open GNOME Software. 2. Search for "nvidia". 3. Choose the Nvidia driver, click Install and follow the prompts. 4. Reboot and enroll the self-signing key in the mokutil tool following <> 5. The OS should boot up with the Nvidia driver enabled. == User Experience == This change aims to improve user experience of installing the proprietary Nvidia driver. == Contingency Plan == If the feature is not implemented on time for Fedora Linux 41, we can simply remove AppStream metadata from the Nvidia driver repo and the driver will not show up in GNOME Software like in Fedora Linux 40. == Documentation == The GNOME Software part is intuitive and doesn't require documentation. The mokutil part is less intuitive and will be documented in the Fedora Workstation section on docs.fedoraproject.org. The docs will be published when the feature lands in Fedora Linux 41. == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- ___ 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
Potential botan (1.x) retirement
Hey, I was wondering if there's anything that could be done about the botan package we still ship in Fedora (not to be confused with botan2). As already mentioned by Jack in [0] it's been EOLed for over five years and it no longer meets today's security requirements. It looks like the only consumer of botan seems to be monotone, which indeed still requires botan 1.x, but there's a couple of patches (not only) from the NixOS folks [1] that adapt it to use the supported botan 2.x version (packaged as botan2 in Fedora). It would be great if we could make use of this in Fedora as well and eventually retire the botan package altogether. Thanks! Cheers, Frantisek [0] https://bugzilla.redhat.com/show_bug.cgi?id=2280094 [1] https://lists.nongnu.org/archive/html/monotone-devel/2024-02/msg2.html -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposl: Libvirt Virtual Network NFTables (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposl-libvirt-virtual-network-nftables-self-contained/120329 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The default firewall backend for the default libvirt virtual network (the virbr0 bridge device), will change from 'iptables' to 'nftables'. == Owner == * Name: [[User:berrange| Daniel Berrange]] * Email: berra...@redhat.com == Detailed Description == A default installation of libvirt will create an isolated bridge device (virbr0), to which guest virtual machines can have their NIC connected. Firewall rules are used to provide NAT based connectivity on this bridge device, as well as allow access to the DNS/DHCP services provided by the dnsmasq it launches on the host. Historically libvirt has always used the iptables tools, which first talked to the iptables kernel modules, but in recent Fedora uses the nftables kernel modules. When Fedora switched Firewalld to use nftables for its own firewall rules, libvirt kept using its iptables userspace backend, which then indirectly created kernel nftables rules. To work correctly, libvirt added the ability to associate its bridge devices with a 'libvirt' zone in firewall to ensure guest->host DHCP/DNS/SSH traffic was not blocked by firewall. With this change, libvirt will now prefer to directly use the nftables userspace tools to create its firewall rules, where they are installed: * nftables only installed => libvirt uses its nftables backend * iptables only intsalled => libvirt uses its iptables backend * nftables and iptables installed => libvirt uses its nftables backend This default behaviour can be overridden to force a specific backend by editting settings in /etc/libvirt/network.conf. Note that this change only applies to libvirt's virtual network functionality. Libvirt's nwfilter (network filter) functionality is still exclusively using iptables/ebtables. This will be switched to nftables in a future Fedora release, timeframe to be determined. == Feedback == TBD == Benefit to Fedora == * Libvirt will be using the same recommended modern nftables userspace as firewalld instead of the legacy iptables compatibility tools which secretly talk to nftables behind the scenes. * All the libvirt nftables rules will be self-contained in a dedicated 'libvirt_network' nftables table, reducing the scope for other applications accidentally changing/removing them. * Improved performance scalability since libvirt's nftables rules are written to use an interface ID match which is a simple lookup, while traditional string based interface name matches in iptables require multiple string comparisons. == Scope == * Proposal owners: Change the libvirt RPM spec to set the 'nftables' backend as the preferred default * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == Existing hosts with libvirt deployed will be using iptables for their firewall rules. When the Fedora upgrade brings in the new libvirt, it will detect the switch to nftables and attempt to remove the historically created iptables rules, and create new nftables rules providing equivalent functionality. A number of iptables chains will remain present after an upgrade * Chain LIBVIRT_FWI * Chain LIBVIRT_FWO * Chain LIBVIRT_FWX * Chain LIBVIRT_INP * Chain LIBVIRT_OUT These chains should not contain rules and thus be harmless. They will go away permanently the next time the host is rebooted, or can be deleted manually if desired. === Reverting to iptables for compatibility === If an incompatibility is discovered between libvirt's nftables backend and some other use case, it is possible to tell libvirt to revert to its iptables backend. * Edit /etc/libvirt/network.conf and set 'firewall_backend = "iptables"' * systemctl restart virtnetworkd Libvirt should then automatically delete its nftables rules and create equivalent iptables rules as present on previous Fedora releases. Alternatively, if the 'nftables' userspace tools are not installed at all, libvirt will attempt to use the 'iptables' userspace tools instead, if present. === Known issue: docker === The Docker iptables integration force changes the iptables FORWARD chain policy from ACCEPT to DENY. This makes '''Docker incompatible with any application that is using nftables''' to try to allow forwarding: https://docs.docker.com/network/packet-filtering-firewalls/#docker-on-a-router When libvirt uses its iptables backend, its FORWARD rules will end up in the same table as docker's, and so override the DE
Next Open NeuroFedora Meeting: Monday, 17 June 2024 (today) at 13:00 UTC
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday, 17 June at 13:00 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us over on Matrix in the Fedora Meeting channel: https://matrix.to/#/#meeting:fedoraproject.org You can use this link to see the local time for the meeting: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting&iso=20240617T13&p1=1440&ah=1 or you can use this command in a terminal: $ date -d 'Monday, June 17, 2024 13:00 UTC' The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - CompNeuro lab compose status check for F41: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! The meeting announcement is also posted on the NeuroFedora blog here: https://neuroblog.fedoraproject.org/2024/06/17/next-open-neurofedora-meeting-17-june-1300-utc.html You can learn more about NeuroFedora here: https://neuro.fedoraproject.org Cheers, -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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
F41 Change Proposal: Confidential Virtualization Host with AMD SEV-SNP (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/ConfidentialVirtHostAMDSEVSNP Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-confidential-virtualization-host-with-amd-sev-snp-self-contained/120326 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This enables Fedora virtualization hosts to launch confidential virtual machines using AMD's SEV-SNP technology. Confidential virtualization prevents admins with root shell access, or a compromised host software stack, from accessing memory of any running guest. SEV-SNP is an evolution of previously provided SEV and SEV-ES technologies providing stronger protection and unlocking new features such as a secure virtual TPM. == Owner == * Name: [[User:berrange| Daniel P. Berrangé]] * Email: berra...@redhat.com == Detailed Description == Fedora has provided support for launching confidential virtual machines using KVM on x86_64 hosts for several years, using the SEV and SEV-ES technologies available from AMD CPUs. These technologies have a number of design limitations, however, that make them less secure than is desired, and prevent exposure of desirable features such as secure TPMs. The SEV-SNP technology is a significant design enhancement and architectural change to addresses the key gaps, increasing security and unlocking more powerful use cases for confidential virtual machines. With SEV/SEV-ES, attestation of the launched VM has to be initiated from the host, which means for a guest owner to attest their VM, they need to rely on API services exposed by the virtualization management stack which will vary across applications. With SEV-SNP, guest owners can initiate attestation from within guest context, providing a standard mechanism across any virtualization environment running SEV-SNP, avoiding a reliance on any host platform tools/APIs. The SEV-SNP technology also unlocks the ability to have a paravisor run in guest context, which is a miniature OS that runs at a higher privilege level (VMPL 0) than the guest firmware / OS (VMPL 3). The paravisor, specifically the [https://github.com/coconut-svsm/svsm Coconut SVSM] implementation, is able to expose trusted services to the guest firmware and OS, which also remain inaccessible to the host. This makes it possible to provide a secure virtual TPM for confidential guests, thus allowing guest OS software to be better secured than is the case with normal virtual TPMs running in host OS context. == Feedback == * TBD == Benefit to Fedora == Confidential guests running under a Fedora SEV-SNP enabled KVM host will be able to: * Self initiate an VM attestation to prove integrity of their running guest machine. This guarantees their guest is running on AMD hardware with SEV-SNP setup in a given configuration, running a particular build for EDK2 firmware, providing data confidentiality even if the host is compromised or malicious. * Measure all aspects of the guest machine boot process into PCRs in a securely hosted virtual TPM * Protect against various known weaknesses of the traditional SEV and SEV-ES technologies == Scope == === Proposal owners === * Ensure kernel packages built in Fedora have SEV-SNP feature integrated and enabled. Code is in kvm/next tree, targetted to merge to linus's tree when 6.11 merge window opens. Will require backport to Fedora's 6.10 tree. * Ensure QEMU packages built in Fedora have SEV-SNP feature integrated and enabled. Queued for merge into the forthcoming [https://wiki.qemu.org/Planning/9.1 9.1.0 upstream release] - rc0 Jul 30th, GA Sep 3rd. F41 beta will ship a QEMU rc, and F41 GA will have QEMU GA release. * Ensure libvirt packages built in Fedora have SEV-SNP feature integrated. Targeted to release immediately following merge into QEMU git HEAD. Releases on 1st of each month, anticipated Sept 1st release at latest, version 10.7.0, but ideally Aug 1st release. * Ensure EDK2 packages built in Fedora have a EFI binary built suitable for use with SEV-SNP guests with SVSM paravisor. EDK2 currently in rawhide has support for SNP + SVSM. Only lacking vTPM support. * Add new Coconut SVSM package, to provide paravisor for SEV-SNP guests. Work in progress adding required rust deps. * Add new IGVM library package, to enable bundling of Coconut SVSM and EDK2 firmware into one launch binary. Work in progress adding required rust deps. * Ensure that an IGVM binary is built containing paired EDK2 and SVSM binaries. * Ensure that virt-install is able to launch an SEV-SNP guest with SVSM and EDK2 === Other developers === * Kernel maintainers: responsible for building new kernel that includes SEV-SNP feature. Currently code is in kvm/next tree, targetted for linus' tree when the 6.11 merge window opens. '''ONLY
Fedora rawhide compose report: 20240617.n.0 changes
OLD: Fedora-Rawhide-20240616.n.0 NEW: Fedora-Rawhide-20240617.n.0 = SUMMARY = Added images:2 Dropped images: 3 Added packages: 1 Dropped packages:0 Upgraded packages: 114 Downgraded packages: 0 Size of added packages: 332.07 KiB Size of dropped packages:0 B Size of upgraded packages: 2.79 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -20.92 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: i3 live aarch64 Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20240617.n.0.iso Image: Server_KVM qcow2 ppc64le Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20240617.n.0.ppc64le.qcow2 = DROPPED IMAGES = Image: i3 live x86_64 Path: Spins/x86_64/iso/Fedora-i3-Live-x86_64-Rawhide-20240616.n.0.iso Image: LXQt live aarch64 Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20240616.n.0.iso Image: Sericea ociarchive aarch64 Path: Sericea/aarch64/images/Fedora-Sericea-Rawhide.20240616.n.0.ociarchive = ADDED PACKAGES = Package: cockpit-files-1-1.fc41 Summary: A filesystem browser for Cockpit RPMs:cockpit-files Size:332.07 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: TurboGears2-2.4.3-16.fc41 Old package: TurboGears2-2.4.3-15.fc40 Summary: Next generation front-to-back web development megaframework RPMs: python3-TurboGears2 Size: 338.72 KiB Size change: 8.26 KiB Changelog: * Sun Jun 16 2024 Python Maint - 2.4.3-16 - Rebuilt for Python 3.13 Package: artifacts-0.0.20240518-1.fc41 Old package: artifacts-0.0.20230928-2.fc41 Summary: Collection of digital forensic artifacts RPMs: artifacts Size: 121.91 KiB Size change: 14.32 KiB Changelog: * Sun Jun 16 2024 Fabian Affolter - 0.0.20240518-1 - Update to latest upstream release (closes rhbz#2281371) Package: btrfs-assistant-2.1.1-1.fc41 Old package: btrfs-assistant-2.0-1.fc41 Summary: GUI management tool to make managing a Btrfs filesystem easier RPMs: btrfs-assistant Size: 792.88 KiB Size change: 1.49 KiB Changelog: * Sun Jun 16 2024 Arthur Bols - 2.1.1-1 - Update to 2.1.1 (fedora#2281564) Package: calibre-7.12.0-2.fc41 Old package: calibre-7.12.0-1.fc41 Summary: E-book converter and library manager RPMs: calibre Size: 53.71 MiB Size change: -89.09 KiB Changelog: * Sun Jun 16 2024 Zbigniew J??drzejewski-Szmek - 7.12.0-2 - Skip test that fails with python3.13 (rhbz#2291497) Package: cinnamon-6.2.0-1.fc41 Old package: cinnamon-6.2.0-0.4.20240613git3aed68c.fc41 Summary: Window management and application launching for GNOME RPMs: cinnamon cinnamon-calendar-server Size: 7.70 MiB Size change: -1.66 MiB Changelog: * Sun Jun 16 2024 Leigh Scott - 6.2.0-1 - Update to 6.2.0 Package: distro-info-0.18-21.fc41 Old package: distro-info-0.18-20.fc40 Summary: Provides information about releases of Debian and Ubuntu RPMs: distro-info perl-distro-info python3-distro-info Size: 167.27 KiB Size change: -421 B Changelog: * Sun Jun 16 2024 Python Maint - 0.18-21 - Rebuilt for Python 3.13 Package: dnf-repo-0.6.1-1.fc41 Old package: dnf-repo-0.6-1.fc41 Summary: A dnf wrapper with fine control of enabled repos RPMs: dnf-repo Size: 31.16 MiB Size change: -52.84 KiB Changelog: * Fri Jun 14 2024 Jens Petersen - 0.6.1-1 - https://hackage.haskell.org/package/dnf-repo-0.6.1/changelog Package: fedscm-admin-1.1.7-8.fc41 Old package: fedscm-admin-1.1.7-7.fc40 Summary: CLI tool to process Fedora SCM requests RPMs: fedscm-admin Size: 84.49 KiB Size change: 498 B Changelog: * Sun Jun 16 2024 Python Maint - 1.1.7-8 - Rebuilt for Python 3.13 Package: ghc-rpm-macros-2.7.1-1.fc41 Old package: ghc-rpm-macros-2.7.0-1.fc41 Summary: RPM macros for building Haskell packages for GHC RPMs: ghc-obsoletes ghc-rpm-macros ghc-rpm-macros-extra ghc-rpm-macros-quick Size: 68.37 KiB Size change: -1.55 KiB Changelog: * Sat Jun 15 2024 Jens Petersen - 2.7.1-1 - build macros now undefine debug_package rather than _enable_debug_packages Package: ghc9.6-9.6.5-19.fc41 Old package: ghc9.6-9.6.5-18.fc41 Summary: Glasgow Haskell Compiler RPMs: ghc9.6 ghc9.6-Cabal ghc9.6-Cabal-devel ghc9.6-Cabal-doc ghc9.6-Cabal-prof ghc9.6-Cabal-syntax ghc9.6-Cabal-syntax-devel ghc9.6-Cabal-syntax-doc ghc9.6-Cabal-syntax-prof ghc9.6-array ghc9.6-array-devel ghc9.6-array-doc ghc9.6-array-prof ghc9.6-base ghc9.6-base-devel ghc9.6-base-doc ghc9.6-base-prof ghc9.6-binary ghc9.6-binary-devel ghc9.6-binary-doc ghc9.6-binary-prof ghc9.6-bytestring ghc9.6-bytestring-devel ghc9.6-bytestring-doc ghc9.6-bytestring-prof ghc9.6-compiler ghc9.6-compiler-default ghc9.6-containers ghc9.6-containers-devel ghc9.6-containers-doc ghc9.6-containers-prof ghc9.6-deepseq
Re: Orphaned packages looking for new maintainers
I'll grab this one - erlang-p1_acme On Fri, Jun 14, 2024 at 9:44 PM wrote: > > Report started at 2024-06-14 19:04:03 UTC > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via the *Take* button in the left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://a.gtmx.me/orphans/orphans.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > > Package (co)maintainers Status > Change > > 3Depict orphan 4 weeks ago > BitchXorphan, rdieter 4 weeks ago > balsa orphan 4 weeks ago > bti orphan 7 weeks ago > buildstream atim, orphan 3 weeks ago > container-exception-logger@abrt-sig, mmarusak, orphan 4 weeks ago > cutecworphan 4 weeks ago > dnssec-nodes orphan 4 weeks ago > dnssec-system-trayorphan 4 weeks ago > erlang-p1_acme@erlang-maint-sig, orphan5 weeks ago > fleet-commander-admin orphan 4 weeks ago > fleet-commander-clientorphan 4 weeks ago > gofer orphan 4 weeks ago > golang-github-client9-gospell @go-sig, orphan 4 weeks ago > golang-github-elves-elvish@go-sig, orphan 8 weeks ago > golang-github-xiaq-persistent @go-sig, orphan 8 weeks ago > golang-k8s-cli-runtime@go-sig, orphan 5 weeks ago > golang-k8s-kubectl@go-sig, orphan 5 weeks ago > grpc defolos, orphan 2 weeks ago > gtypist orphan 4 weeks ago > jgit orphan 4 weeks ago > jolokia-jvm-agent orphan 9 weeks ago > kanotf-fonts orphan 4 weeks ago > laf-pluginorphan 4 weeks ago > levien-museum-fonts orphan 4 weeks ago > libitlmoceap, orphan 4 weeks ago > logserial orphan 4 weeks ago > mingw-cppunit orphan 6 weeks ago > mingw-freeimage orphan 9 weeks ago > mingw-sword orphan 5 weeks ago > neofetch orphan 6 weeks ago > nuntius kalev, orphan4 weeks ago > oc-inject orphan 4 weeks ago > perl-Flickr-API orphan 4 weeks ago > perl-Flickr-Uploadorphan 4 weeks ago > perl-Getopt-GUI-Long orphan 4 weeks ago > perl-QWizard orphan 4 weeks ago > php-doctrine-common3 orphan 1 weeks ago > php-doctrine-orm orphan, remi 1 weeks ago > pidgin-guifications nosnilmot, orphan4 weeks ago > polkit-gnome @epel-packagers-sig, orphan 0 weeks ago > prometheus-jmx-exporter orphan 9 weeks ago > prometheus-simpleclient-java orphan 9 weeks ago > python-amico orphan 1 weeks ago > python-glue orphan 4 weeks ago > python-googleapis-comm
Re: Exiv2 0.28.2
Il 17/06/24 07:15, zebo...@gmail.com ha scritto: > This is still in progress in f41-build-side-91095 > > ```todotxt sort:priority:desc sort:status:asc > x calligra > x darktable > digikam > x exiv2 > geeqie > gegl04 > x gerbera > gimp-lensfun > x gnome-commander > gpscorrelate > x gthumb > x gwenview > x hugin > immix > kde-runtime > x kf5-kfilemetadata > x kf6-kfilemetadata > koko > kphotoalbum > krename > krita > libextractor > x libgexiv2 > x libkexiv2 > luminance-hdr > merkaartor > mythtv > nomacs > x pcmanfm-qt > x pdf2djvu > x photoqt > x phototonic > x python3-exiv2 > x qgis > x qimgv > x rawstudio > x rawtherapee > x siril > stellarium > x taglib-sharp > x ufraw > x viewnior > ``` > > My next day off is Sunday, so it might take a moment to go through the > remaining. Can I help you in some way? Is there anything specific other than trigger a new build in the side tag and check the result? Mattia-- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Mon, Jun 17, 2024 at 08:24:40AM +0100, Richard W.M. Jones wrote: > On Wed, Jun 12, 2024 at 03:07:02PM +0100, Daniel P. Berrangé wrote: > > On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote: > > > On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé > > > wrote: > > > > > > > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote: > > > > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé > > > > > wrote: > > > > > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, > > > > > > users > > > > > > with older x86_64 hardware would likely be unable to run QEMU, from > > > > > > F41 > > > > > > onwards, unless some TBD action is taken. > > > > > > > > > > > > Thus I'm wondering whether Fedora has any policy or guidance on > > > > > > handling > > > > > > such a situation both in general, and more specifically for > > > > > > "critical path" > > > > > > packages, if that difference is relevant ? The packaging guidelines > > > > > > aren't > > > > > > especially explicit about this situation, unless I've missed > > > > > > something > > > > > > beyond the "compiler flags" and "architecture support" sections. > > > > > > > > > > > > > > > > Absent a project-wide decision to move to the newer baseline, I think > > > > > the best approach we can take would be to find some way to communicate > > > > > to the user that the software isn't usable. In the case of Qemu, does > > > > > the application report an error or crash if it's run on hardware > > > > > without the requisite baseline? > > > > > > > > I've not tested, but I would expect it to crash attempting to execute an > > > > illegal instruction > > > > > > > > > > OK, that's a situation that will lead to annoying and unresolvable bug > > > reports. Would it be possible to put something in place that would > > > check processor capabilities early in execution before hitting any of > > > the affected instructions? > > > > Not trivial as a bunch of code executes from ELF constructors before > > main() starts. > > A little known feature of GCC constructors if you can assign a > priority to them, which controls the ordering (apparently, I did not > test). Smaller numbers run the constructor earlier / destructor later: > > https://maskray.me/blog/2021-11-07-init-ctors-init-array > > Numbers <= 100 are reserved, but unless you opt in with the > -Wprio-ctor-dtor flag, you won't get a warning about this. Maybe we > can add a constructor(0) which checks CPUID? I think I've convinced upstream to change their approach to make their recent changes a compile-time opt-in, to allow build time choice of the non-optimized code, rather than forcing it on everyone. So hopefully we don't need todo anything in Fedora now. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Guidance on individual packages requiring x86_64-v2 baseline ?
On Wed, Jun 12, 2024 at 03:07:02PM +0100, Daniel P. Berrangé wrote: > On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote: > > On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé > > wrote: > > > > > > On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote: > > > > On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé > > > > wrote: > > > > > IOW, if [when] we rebase Fedora to the next QEMU upstream release, > > > > > users > > > > > with older x86_64 hardware would likely be unable to run QEMU, from > > > > > F41 > > > > > onwards, unless some TBD action is taken. > > > > > > > > > > Thus I'm wondering whether Fedora has any policy or guidance on > > > > > handling > > > > > such a situation both in general, and more specifically for "critical > > > > > path" > > > > > packages, if that difference is relevant ? The packaging guidelines > > > > > aren't > > > > > especially explicit about this situation, unless I've missed something > > > > > beyond the "compiler flags" and "architecture support" sections. > > > > > > > > > > > > > Absent a project-wide decision to move to the newer baseline, I think > > > > the best approach we can take would be to find some way to communicate > > > > to the user that the software isn't usable. In the case of Qemu, does > > > > the application report an error or crash if it's run on hardware > > > > without the requisite baseline? > > > > > > I've not tested, but I would expect it to crash attempting to execute an > > > illegal instruction > > > > > > > OK, that's a situation that will lead to annoying and unresolvable bug > > reports. Would it be possible to put something in place that would > > check processor capabilities early in execution before hitting any of > > the affected instructions? > > Not trivial as a bunch of code executes from ELF constructors before > main() starts. A little known feature of GCC constructors if you can assign a priority to them, which controls the ordering (apparently, I did not test). Smaller numbers run the constructor earlier / destructor later: https://maskray.me/blog/2021-11-07-init-ctors-init-array Numbers <= 100 are reserved, but unless you opt in with the -Wprio-ctor-dtor flag, you won't get a warning about this. Maybe we can add a constructor(0) which checks CPUID? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
