-----BEGIN PGP PUBLIC KEY BLOCK-----
xsFNBGJo5iQBEADBDrePgICrxsoCWxlAiEKAgZgqeX1XhHxhDCkprNwOA9ZEU7G9
77BEHgYLSrAh3LraWYK+piBXBuHdg8KCUppUmEC4GtiHg+KxtxRjgZn/tjLD6vgZ
kwZYs0KXQVCK2bhSL0paEA78Xcx1B6xa8JArnjk87VoNl6RCjJESXkwlqGtQTEOp
bNxBy5Pd0T33xYeKcOz0GWY5ndkU1gD7NtMZdWZ8vcQclLquQO5OE33OhK78cU4Z
k4xFL5I5R4rBhlrOsw002bbD0+QI6wUKQByHfvcAz59eHS/wJOrAY/1p+IKql/4f
sRQQSRPSc+3CqELdxzF2s+AG0PciQms3RVYT6czH28Ce9C9BDAENga28FvQDf5Zi
STUeXZm0XJ9g+dLg+6FBPHp9wX+ybfAmIRXQlV4D6DledQAWjoBy3j09JOGQGSH0
S3EbQ68Qn2xyGBlYeFCZbMlKDN8NrpVCx9Jf6dDb3Qv2Do1yIIRu5x0vwKlNsQG0
NffMryLCQ0tVBNNiwqrHIbmZEhSUEmKf6u+zZsx1JMewe6fRw3hf3VOzENH5tGpZ
Z1Yg8m3E2yiXmPJ9cX3iZD0l7/L8CEiuMWt/q/NEDnKsGovi9N1r04Yxxo5lWoHr
+4taaOnC2C7YEHICIWx3lEU0lm24PbNG4QBJCJ8ctwG2rV3AMILCVSzW0QARAQAB
zSVNYXJrIEVzbGVyIDxtYXJrLmVzbGVyQGNhbm9uaWNhbC5jb20+wsGUBBMBCgA+
FiEELTsQ/oZuJMqL99Qt1guDyQUTvU8FAmJo5iQCGwMFCQPCZwAFCwkIBwIGFQoJ
CAsCBBYCAwECHgECF4AACgkQ1guDyQUTvU/Gqw/9F5ko+KS9CRXXcp4SkdhHB6aG
tD9rEJycEywPymmI+OwCJppmbQBzzwW7QGLHi8TTiWnWMSeikhSh0p9pPCc9rhLt
tYDlGZwoxXPt7PwS0k9JjITNviTNZD6uHIoYmFMxS65qdh7s7OSQj4+nTij1b+dV
qzaG4krGB/pav2D2adt4k02KfqIkPiLY0Jo+o8hKOx2HRh8xqEU/eySRtVvIx55c
D4Qh63KQv465Afz+QuKsbxuqA2iboUP/srYtMQtFi8TCF7/5gLwDbGDgOAYhIxyf
vgAH5dbBFB8lIMPjIeTbP0lE+xMHUmQsKhtYICnjhnGRJeT6vBlDFuUar5DYA3fI
m9LEAf1T1eMK4FBUSCv+cULlT9+rsHDbG6tiZU/BDp/mkKFs2Ax9W68+fgXy7bor
ixrgDhfSCsYWaxLsXW/GEmyCbp30PZlLr6kvfQq7CMEjeE79FEsef7/ppRH/t+mv
6p2xhb+DDbvqzcQZ7LQn3+PLxkR37spQRvevPxpx000CqTO5gV19w/2ZSPydm2Zd
44XSranzwDdD4o5ZsMXAPuCNlVAVzxAhxNj2QQL7xh9bdDDmM9Z7qBPwFX42n7mw
ryjBHqMtrSCSI8hupSh2B/bQSRyWd3/KQ2vlJMoq7H5EJiJYpb3blvb4tfoSfEag
PqYV1jJEcKImOGs988rOwU0EYmjmJAEQAL0wGwC8P1qj0fuLaFpPKBAFtxBqnJJc
c+63DjQ17/QJrYpKwGGkW6fz/Nn0nUDf88FdrHd7t6a9c3m82/gvsr8VjAD4SISp
DjPIpfCj5gWGAuhATWB0pwjWRsgFkIThaa0px6ZJFGdU9lJmi633Xsk4s9bws8kZ
pnwtk+StRueqcSElfLw1/gbu6EhcEH62iBb2qlRhgtntgy1dcnqDEQhcdccWSgna
+ZlDIo3Z75RWoIXxrtzUe9PDdG4Ou+k/H96mS7pZdmU6elbQlcDGYegYGH6OTYjv
Zyl81ACN9Y3Fcmc+luBMeuyQndHFnG6rjOwHr6iM9ZKRBq03QiAAp4vooPyLqG9n
ZmoeLH0Q7L2pVIwroVtsJvnjws5z3DujguZcLYCeA/WEXj8p0lYy9WVGrfJ7LyLp
+Uj7AdXFB6msED51Swb6QkpWrcC7V2COKZmfYGXFy7PdIwWeqgYjJ0zqEldHGDTD
V0yTuuER2bJ/T1WBVy9U46/KRUXYevgCZFGPbyO/vKLwKVbrbkimULMFcPJpKinF
PQs0ch7HA6PPog0wbux5Bm9O78lzYo/WFlvofFKTzfGEsnifCVXkcsu0Qp8m6DQZ
yeFO8SH3DHaHFaPKc3JYEFTdmP0PdvH8aqb5TVTb8G+hvxktDkCuCrlaoFVSCNhI
WfJ6rAxxYGuNABEBAAHCwXwEGAEKACYWIQQtOxD+hm4kyov31C3WC4PJBRO9TwUC
YmjmJAIbDAUJA8JnAAAKCRDWC4PJBRO9T3SnEACEprj9LsxvhbM6A/aLk3la8UD9
MYtLSmbl+KPGEvP0r7viPftolgV8O+tRG09Z7Wd/63WsHjA2Psgwdm49BziL8tCf
ONfVXCojPxR/uyL5ykPHSE/yC+mz3DTPWcncGCdteil6Cw43MHNCm2oYJ38VXAwV
9pikHeO5Pj5xukmc/bQr3v3NrDQI+AQpNbWs2r4vw+y01IidmMh12RkuGi2UYOga
jvfDeoSSEF7VJ6Qlij9UjatkbZpSHjn2rf+B9DdlkRNr5Vfd9/xaSFQoazdgNS/Q
HqOeZ+9HqNrUlHTH9BUaTkmV6MDXtEjVGfROXxXPw/q29QUzZUZE3agqmuxB3yar
PjW24mNu5Kd22rb06blTfBO0o7DOX9UwOVLfFLejfWAYANuXilcju9/3dHRsv6o9
9tGfRxJIMOPVY6JgswYISB7CwdA+Uda6UvU+qwYCRi7B8L13H3uhDKzA5sgRZnz2
oQw+bOB/ErZv78NVnhrdy9LAkLk0U8RVvH8sWPco4ZjQVou6wDMEsKaIlioU8x6n
YOi8LBpijWpaKEpCbU4nRdV/4d3eWr7tu1MWGcm70C6mrjypxI6TVCPg+gimjM4D
7LOpJKZJVGQg9JYPUhccp27Nn/3L2/Y9F3tKUfCTPHanOzHg4KNRRUr8CQD8qi+8
nWqztY9OeZjz0vagYM7BTQRiaOZoARAA6bzogRYAMYdwU2BsWFurvrghzEbqjguN
XwBiQ/90kXb3exYZvGXTCxdrV5FRjPU6eeX2TAyZRt6XnK6nyrZFlRAcXeWCeo05
d+mdK6fv4iOc/T0JeMZCrNm4BDjcGNOr7KImVQTNuoN9nVieVQSK/hRpSFPkNLbn
1oemHqZitxoI5HCBAVQrKR8d0REzn9Y1jdCHkhgSNaEcAww6CgF2Mlsw5txhmIh9
IZircfAzGU6lI1MgjPkDOFPDdwIoc8xtuAJB/G6gT8Ot9FQ3EMaV2zPTL7Jd1ZQR
hOrs75gjLlhOyYYb5Y3isaMKzUMYKQDFWrCws/sGEm2TwbD5gI6ipa2r71DcGijj
GJQITAQsS+rdUKBts+DPKfZR4nlLq41/utA4LJL2y33SFXeqylyIoKPs1FJ0JZyM
VXiWQyxAuPjYJPZbcSh8exj6rct/QVZgztSuvKxeaEqZ/xwkQ/uHWZxQy7lZxBbw
LCVH8HxVApD/tc3/U/jQjtQSblX3KnMia5rHjX+p9tYSSeLNPA99KNrqwLdDh9Mz
/Rm131NUHwlOEIpSeqDfs1+jQYy0QdZnxDHrIVnpIz6M8IVFRBo4LQmi0sPkzzEZ
A29s3+IzofztGXf+b+vZAmnOrQEgNPjdIVHfvQJVqcm1JdOzyuHEvN8IiV/90RAP
r2NqNrtRjQMAEQEAAcLBfAQYAQoAJhYhBC07EP6GbiTKi/fULdYLg8kFE71PBQJi
aOZoAhsgBQkDwmcAAAoJENYLg8kFE71PE2wQAK2ntrQ0902+a3KC/Ak7VhOTV0c0
my8e7mqesYRGXB158P7UJZS1grU6MjBbMsArFdshTRquSmEOnAB6ahnD+JNq+Jzf
9QKknvekzkjlC11FxTHMGncKnScsu8Vont+rFBA66JYLrh7my5CpzijTVTYC9HcA
SbnW0IzzJl90cVh5tC9S+m6Dh3kNcujWyJ8D+ceaEhwYE2LgbbDUSJa2p1tBiXQ6
SGu6nX0nyXL5p7zzRhAl/ao5cZ/FTijvdQe1Vzm7qArKj6A3ir5YOWzSnaCbfbSm
J2pPgZZCNybzStmcoZ73GgBJxIh89vixfBRLTJVECePLTw2gBmoxR1ziqs0pKW3H
y3VKBb+QMJAVmRwRlonMTgT5gHa8bCL8U7Qvx9jOrApOEqFee3dytIOoVsCUkNh0
vOKmlLuqrIopdbJm8F58qOV/eR5chfxax9jOSHkZ812LyMyxr8y6wn3d26XF4Ho1
tGRAYDI77qaLxaPbzIFas1t9X/+U+sz3Bg0exmi9/mp9wwvLJh3XOC+2MaHzBXGl
x+MvgOYIvEtZXVvfwjay19rhJRvn0D497VaVrhw7md5IbKY42h5qUCCzlHsqHEe5
YDxswWadH4fZhy+cEatf29lYJ2BaK+PIsmp22bxbxdGdoZ2cbqQXIko+3XxaiVp5
z7V5USx9zNkfsrbz
=3tFx
-----END PGP PUBLIC KEY BLOCK-----
==========================================================================
Ubuntu Security Notice USN-6189-1
June 28, 2023
etcd vulnerability
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 23.04
- Ubuntu 22.10
Summary:
etcd could be made to expose sensitive information over the
network.
Software Description:
- etcd: highly-available key value store -- client
Details:
It was discovered that etcd leaked credentials when debugging
was enabled. This allowed remote attackers to discover etcd
authentication credentials and possibly escalate privileges on
systems using etcd.
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 23.04:
etcd-client 3.4.23-4ubuntu0.1
etcd-server 3.4.23-4ubuntu0.1
Ubuntu 22.10:
etcd-client 3.3.25+dfsg-7ubuntu0.22.10.2
etcd-server 3.3.25+dfsg-7ubuntu0.22.10.2
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-6189-1
CVE-2021-28235
Package Information:
https://launchpad.net/ubuntu/+source/etcd/3.4.23-4ubuntu0.1
https://launchpad.net/ubuntu/+source/etcd/3.3.25+dfsg-7ubuntu0.22.10.2
Tuesday, June 27, 2023
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
Hello,
I'd like to provide an update on Python 3.12 mass rebuild.
The mass rebuild is still in progress. So far 2666 packages were rebuilt in side tag which is about 65,8% out of 4049 python packages. We are now working on fixing important packages blocking others.
As mentioned in previous email - if you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via:
on branch rawhide:
$ fedpkg build --target=f39-python
$ koji wait-repo f39-python --build <nvr>
Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do.
When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us.
Builds: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=-build_id&inherited=0
Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over.
Thanks. Let us know if you have any questions.
Here is the list of packages that failed to build but their dependencies are available. If you'd like to help us, any fixes are welcome. Please build the package with --target=f39-python if you fix it.
If your package is failing with ModuleNotFoundError: No module named 'imp', this is happening because Python 3.12 removed the long deprecated imp module. As a stopgap measure, you can BuildRequire python3-zombie-imp package, which allows you to import the imp module even on Python 3.12. We strongly recommend talking to upstream and encouraging them to migrate to importlib instead.
Maintainers by package:
NFStest ajmitchell steved
Zim cheeselee ohaessler
andriller fab
appliance-tools ngompa
aubio nphilipp tartina
awake fab
awscli2 davdunc nforro
b43-tools pwalter
beaker martstyk
binwalk ajax swt2c
borgbackup fschwarz
botan2 bkircher thm
brd jsbackus
btest fab
cdist fnux
classification-banner rga
condor bcotton matyas ttheisen valtri
criu adrian rstoyanov
cxxtest mgieseki
dionaea rebus
distgen hhorak phracek pkubat praiskup zmiklank
dnf-plugin-diff praiskup
dnf-plugins-extras dmach jmracek mblaha pkratoch
dtc arnd bonzini jwboyer pbrobinson
electron-cash jonny
elements aalvarez
emacs-jedi melmorabity
eric rdieter
fail2ban atkac hobbes1069 orion tmz
fedora-gather-easyfix pingou
flann rmattes
flatpak-module-tools kalev otaylor
fonts-tweak-tool tagoh
future sagitter
gaupol music
gfal2-python jonathanspw mipatras
gnome-doc-utils alexl caolanm limb rhughes rstrode
h5py orion stevetraylen terjeros
i2c-tools ajax jorton jzerdik olysonek
kernel-tools acaringi jforbes jwboyer lgoncalv patrickt pbrobinson
kicad avigne lkundrak stevenfalco
kitty atim jonathanspw salimma solopasha zawertun
lammps cz4rs ellio167 junghans rberger
lensfun germano grahamwhiteuk nphilipp ohaessler rdieter trix
libffado nphilipp
libfreenect jkastner kathenas kwizart rmattes
libnl3 dcbw jirka thaller
libssh2-python clalance
lilv nphilipp tartina
livecd-tools bcl bruno ngompa
lvm2 agk bmarzins bmr cfeist kzak lvm-team mauelsha mbroz mcsontos pjones prajnoha zkabelac
m2crypto mitr ngompa
manafirewall ngompa thunderbirdtr
mercurial kiilerix nbecker pstodulk
mrchem jussilehtola
oct2spec orion
offlineimap cicku dodji sergesanspaille teuf
onboard yanqiyu
pam_wrapper asn jhrozek
pdc-client kevin lholecek lsedlar nphilipp
pdf-stapler aarem raphgro
photoqt eischmann
py-radix kevin
pyflowtools stingray
pyftpdlib aekoroglu
pygsl jamatos
pyke spot
pyodbc fjanus hhorak osloup
pyosmium tomh
python-GridDataFormats rathann
python-IPy kevin
python-PyPDF2 aarem
python-acora fab
python-aiofiles ankursinha
python-aiosmtpd abompard
python-aiozeroconf fab
python-alarmdecoder fab
python-annexremote ankursinha
python-ansi sdyroff
python-ansible-pygments chedi
python-ansiwrap fab
python-apsw cicku dfateyev maci
python-argcomplete churchyard ignatenkobrain mfabik msrb stevetraylen
python-ase besser82 marcindulak
python-astroid bcl limb lupinix mrunge orion
python-astropy-healpix lupinix
python-astropy-helpers lupinix
python-async-generator carlwgeorge
python-asyncssh gsauthof
python-audioread terjeros
python-avocado cleber merlinm
python-bidict fab
python-biopython alexlan lbazan rathann sagitter
python-bleach bowlofeggs ignatenkobrain mrunge
python-blowfish limb
python-bluepy alciregi
python-bokeh ankursinha
python-boto apevec gholms limb
python-botocore davdunc fale gholms limb lkundrak
python-bottle aekoroglu fedepell
python-box dmsimard fab
python-catkin_tools ankursinha cottsay rmattes
python-chai kevin pingou
python-check-manifest fab
python-click-spinner fab
python-cloudpickle jonathanspw lbalhar
python-cpio jamatos kevin
python-cram ktdreyer
python-curio carlwgeorge
python-cypari2 pcpa
python-cypy orphan
python-deap zbyszek
python-diff-match-patch amigadave
python-dockerfile-parse cverna maxamillion ttomecek twaugh
python-dominate fab hvad
python-drat orphan
python-drgn dcavalca filbranden osandov salimma
python-ephem fab
python-esphomeflasher dcavalca
python-fastbencode opohorel
python-firehose athoscr dmalcolm
python-flask-babel jonathanspw ngompa pcpa
python-flask-cors frantisekz
python-flask-login smani
python-flufl-bounce abompard
python-fpylll pcpa
python-fspath ankursinha
python-gccinvocation dmalcolm
python-geomet qulogic
python-grako brouhaha
python-graph-tool ankursinha
python-guizero churchyard
python-hdfs ankursinha
python-igor zbyszek
python-immutables carlwgeorge
python-iniparse aekoroglu lupinix
python-invoke jkucera
python-iowait aekoroglu
python-ipgetter fab
python-javaproperties mhayden
python-jep raphgro
python-josepy nb
python-json-logger hguemar
python-jsonrpc-server nonamedotc
python-kafka hiwkby
python-kmod grover mlombard
python-lacrosse fab
python-lazr-smtptest abompard
python-leveldb survient
python-liblarch miguel7ra
python-libsass nonamedotc
python-logging-tree fab
python-logutils jcaratzas kevin
python-managesieve gui1ty
python-markdown_2 aekoroglu
python-matplotlib-scalebar ankursinha
python-maxminddb carlwgeorge ignatenkobrain lbalhar
python-metar jdekloe
python-mirakuru mikelo2
python-mistune08 salimma
python-modestmaps cottsay
python-multi_key_dict cottsay
python-mygpoclient slankes vpv
python-ndindex zbyszek
python-neovim asn salimma
python-nmap fab
python-nose_fixes besser82
python-notario ktdreyer
python-nss dshea
python-nudatus churchyard
python-numpydoc jonathanspw orion tomspur
python-optcomplete chedi
python-pathos ankursinha
python-pathtools scoady
python-pdir2 supakeen
python-pint lzachar mrunge
python-pivy hobbes1069
python-pluginlib aviso
python-podman-api orphan
python-protego echevemaster
python-ptrace terjeros
python-py9p psavelye
python-pyaes peter
python-pycodestyle churchyard orion
python-pydiffx jonathanspw
python-pydocstyle tadej
python-pyfim ankursinha
python-pylatex ankursinha
python-pyopencl frantisekz
python-pyopengl swt2c
python-pyoptical ignatenkobrain orphan
python-pyrad antorres cicku peter
python-pysam davidsch
python-pyside2 hobbes1069
python-pysnooper lbalhar zbyszek
python-pytest-bdd music
python-pytest-metadata pschindl
python-pytest-subtests fab
python-pytest-venv lbalhar
python-pytest-virtualenv kevin
python-pyzolib cottsay
python-qpageview limb
python-qutepart raphgro
python-recordclass dcavalca
python-redis cicku kevin maxamillion
python-rope nonamedotc
python-rpmfluff dshea ignatenkobrain jhutar
python-rstcheck-core ankursinha
python-schedutils jkastner
python-semver aekoroglu mhayden raphgro
python-signedjson aekoroglu
python-simplemediawiki orphan
python-simpleparse grover mlombard
python-simplewrap ankursinha ignatenkobrain
python-slip nphilipp
python-smart-gardena fab
python-smartcols kalev
python-smbpasswd rebus
python-sphinxygen fed500
python-sqlalchemy nphilipp
python-stdlib-list lbazan
python-tables jonathanspw zbyszek
python-tambo ktdreyer
python-testresources apevec carlwgeorge mrunge
python-textdistance nonamedotc
python-token-bucket supakeen
python-tokenize-rt rominf
python-twisted jonathanspw jsteffan
python-uinput bytehackr
python-upoints fab
python-uri-templates mbaldessari
python-urllib-gssapi simo
python-virtualenv-clone tadej
python-visionegg-quest ankursinha ignatenkobrain
python-wcmatch pnemade
python-webscrapbook ferdnyc
python-webtest ondrejj
python-wordcloud dcavalca
python-yamlordereddictloader greghellings
python-yappi amoralej
python-yara aekoroglu mikelo2 rebus
python-yourls tflink
python-yte music
python-ytmusicapi thunderbirdtr
python-zmq tomspur
python3-cangjie bochecha
python3-py3dns bojan kevin
python3-saml tchaikov
python3-script jonathanspw
qpid-proton irina kpvdr
rabbitvcs cicku limb pwalter
rmlint orphan
shybrid vanessakris
sudo alakatos kzak mattdm rsroka zfridric
sugar aperezbios chimosky
sugar-datastore chimosky
sugar-toolkit-gtk3 aperezbios chimosky pbrobinson
swid-tools adelton
swift-lang tachoknight
sword cicku greghellings jkastner
system-storage-manager lczerner trawets
terminator dmaphy mattrose ohaessler
thefuck principis
transmageddon kalev uraeus
trelby limb
unicorn fab mikep
upm pbrobinson
urjtag jkastner scottt
ustreamer tao-j
uwsgi ertzing
vit ankursinha
volume_key huzaifas jkucera mitr
watchman dcavalca filbranden salimma
wordxtr pnemade
xcb-proto ajax slaanesh
xen jforbes myoung
ydiff netvor
zbar limb mchehab slaanesh
Packages by maintainer:
aalvarez elements
aarem pdf-stapler python-PyPDF2
abompard python-aiosmtpd python-flufl-bounce python-lazr-smtptest
acaringi kernel-tools
adelton swid-tools
adrian criu
aekoroglu pyftpdlib python-bottle python-iniparse python-iowait python-markdown_2 python-semver python-signedjson python-yara
agk lvm2
ajax binwalk i2c-tools xcb-proto
ajmitchell NFStest
alakatos sudo
alciregi python-bluepy
alexl gnome-doc-utils
alexlan python-biopython
amigadave python-diff-match-patch
amoralej python-yappi
ankursinha python-aiofiles python-annexremote python-bokeh python-catkin_tools python-fspath python-graph-tool python-hdfs python-matplotlib-scalebar python-pathos python-pyfim python-pylatex python-rstcheck-core python-simplewrap python-visionegg-quest vit
antorres python-pyrad
aperezbios sugar sugar-toolkit-gtk3
apevec python-boto python-testresources
arnd dtc
asn pam_wrapper python-neovim
athoscr python-firehose
atim kitty
atkac fail2ban
avigne kicad
aviso python-pluginlib
bcl livecd-tools python-astroid
bcotton condor
besser82 python-ase python-nose_fixes
bkircher botan2
bmarzins lvm2
bmr lvm2
bochecha python3-cangjie
bojan python3-py3dns
bonzini dtc
bowlofeggs python-bleach
brouhaha python-grako
bruno livecd-tools
bytehackr python-uinput
caolanm gnome-doc-utils
carlwgeorge python-async-generator python-curio python-immutables python-maxminddb python-testresources
cfeist lvm2
chedi python-ansible-pygments python-optcomplete
cheeselee Zim
chimosky sugar sugar-datastore sugar-toolkit-gtk3
churchyard python-argcomplete python-guizero python-nudatus python-pycodestyle
cicku offlineimap python-apsw python-pyrad python-redis rabbitvcs sword
clalance libssh2-python
cleber python-avocado
cottsay python-catkin_tools python-modestmaps python-multi_key_dict python-pyzolib
cverna python-dockerfile-parse
cz4rs lammps
davdunc awscli2 python-botocore
davidsch python-pysam
dcavalca python-drgn python-esphomeflasher python-recordclass python-wordcloud watchman
dcbw libnl3
dfateyev python-apsw
dmach dnf-plugins-extras
dmalcolm python-firehose python-gccinvocation
dmaphy terminator
dmsimard python-box
dodji offlineimap
dshea python-nss python-rpmfluff
echevemaster python-protego
eischmann photoqt
ellio167 lammps
ertzing uwsgi
fab andriller awake btest python-acora python-aiozeroconf python-alarmdecoder python-ansiwrap python-bidict python-box python-check-manifest python-click-spinner python-dominate python-ephem python-ipgetter python-lacrosse python-logging-tree python-nmap python-pytest-subtests python-smart-gardena python-upoints unicorn
fale python-botocore
fed500 python-sphinxygen
fedepell python-bottle
ferdnyc python-webscrapbook
filbranden python-drgn watchman
fjanus pyodbc
fnux cdist
frantisekz python-flask-cors python-pyopencl
fschwarz borgbackup
germano lensfun
gholms python-boto python-botocore
grahamwhiteuk lensfun
greghellings python-yamlordereddictloader sword
grover python-kmod python-simpleparse
gsauthof python-asyncssh
gui1ty python-managesieve
hguemar python-json-logger
hhorak distgen pyodbc
hiwkby python-kafka
hobbes1069 fail2ban python-pivy python-pyside2
huzaifas volume_key
hvad python-dominate
ignatenkobrain python-argcomplete python-bleach python-maxminddb python-pyoptical python-rpmfluff python-simplewrap python-visionegg-quest
irina qpid-proton
jamatos pygsl python-cpio
jcaratzas python-logutils
jdekloe python-metar
jforbes kernel-tools xen
jhrozek pam_wrapper
jhutar python-rpmfluff
jirka libnl3
jkastner libfreenect python-schedutils sword urjtag
jkucera python-invoke volume_key
jmracek dnf-plugins-extras
jonathanspw gfal2-python kitty python-cloudpickle python-flask-babel python-numpydoc python-pydiffx python-tables python-twisted python3-script
jonny electron-cash
jorton i2c-tools
jsbackus brd
jsteffan python-twisted
junghans lammps
jussilehtola mrchem
jwboyer dtc kernel-tools
jzerdik i2c-tools
kalev flatpak-module-tools python-smartcols transmageddon
kathenas libfreenect
kevin pdc-client py-radix python-IPy python-chai python-cpio python-logutils python-pytest-virtualenv python-redis python3-py3dns
kiilerix mercurial
kpvdr qpid-proton
ktdreyer python-cram python-notario python-tambo
kwizart libfreenect
kzak lvm2 sudo
lbalhar python-cloudpickle python-maxminddb python-pysnooper python-pytest-venv
lbazan python-biopython python-stdlib-list
lczerner system-storage-manager
lgoncalv kernel-tools
lholecek pdc-client
limb gnome-doc-utils python-astroid python-blowfish python-boto python-botocore python-qpageview rabbitvcs trelby zbar
lkundrak kicad python-botocore
lsedlar pdc-client
lupinix python-astroid python-astropy-healpix python-astropy-helpers python-iniparse
lvm-team lvm2
lzachar python-pint
maci python-apsw
marcindulak python-ase
martstyk beaker
mattdm sudo
mattrose terminator
matyas condor
mauelsha lvm2
maxamillion python-dockerfile-parse python-redis
mbaldessari python-uri-templates
mblaha dnf-plugins-extras
mbroz lvm2
mchehab zbar
mcsontos lvm2
melmorabity emacs-jedi
merlinm python-avocado
mfabik python-argcomplete
mgieseki cxxtest
mhayden python-javaproperties python-semver
miguel7ra python-liblarch
mikelo2 python-mirakuru python-yara
mikep unicorn
mipatras gfal2-python
mitr m2crypto volume_key
mlombard python-kmod python-simpleparse
mrunge python-astroid python-bleach python-pint python-testresources
msrb python-argcomplete
music gaupol python-pytest-bdd python-yte
myoung xen
nb python-josepy
nbecker mercurial
netvor ydiff
nforro awscli2
ngompa appliance-tools livecd-tools m2crypto manafirewall python-flask-babel
nonamedotc python-jsonrpc-server python-libsass python-rope python-textdistance
nphilipp aubio lensfun libffado lilv pdc-client python-slip python-sqlalchemy
ohaessler Zim lensfun terminator
olysonek i2c-tools
ondrejj python-webtest
opohorel python-fastbencode
orion fail2ban h5py oct2spec python-astroid python-numpydoc python-pycodestyle
orphan python-cypy python-drat python-podman-api python-pyoptical python-simplemediawiki rmlint
osandov python-drgn
osloup pyodbc
otaylor flatpak-module-tools
patrickt kernel-tools
pbrobinson dtc kernel-tools sugar-toolkit-gtk3 upm
pcpa python-cypari2 python-flask-babel python-fpylll
peter python-pyaes python-pyrad
phracek distgen
pingou fedora-gather-easyfix python-chai
pjones lvm2
pkratoch dnf-plugins-extras
pkubat distgen
pnemade python-wcmatch wordxtr
praiskup distgen dnf-plugin-diff
prajnoha lvm2
principis thefuck
psavelye python-py9p
pschindl python-pytest-metadata
pstodulk mercurial
pwalter b43-tools rabbitvcs
qulogic python-geomet
raphgro pdf-stapler python-jep python-qutepart python-semver
rathann python-GridDataFormats python-biopython
rberger lammps
rdieter eric lensfun
rebus dionaea python-smbpasswd python-yara
rga classification-banner
rhughes gnome-doc-utils
rmattes flann libfreenect python-catkin_tools
rominf python-tokenize-rt
rsroka sudo
rstoyanov criu
rstrode gnome-doc-utils
sagitter future python-biopython
salimma kitty python-drgn python-mistune08 python-neovim watchman
scoady python-pathtools
scottt urjtag
sdyroff python-ansi
sergesanspaille offlineimap
simo python-urllib-gssapi
slaanesh xcb-proto zbar
slankes python-mygpoclient
smani python-flask-login
solopasha kitty
spot pyke
steved NFStest
stevenfalco kicad
stevetraylen h5py python-argcomplete
stingray pyflowtools
supakeen python-pdir2 python-token-bucket
survient python-leveldb
swt2c binwalk python-pyopengl
tachoknight swift-lang
tadej python-pydocstyle python-virtualenv-clone
tagoh fonts-tweak-tool
tao-j ustreamer
tartina aubio lilv
tchaikov python3-saml
terjeros h5py python-audioread python-ptrace
teuf offlineimap
tflink python-yourls
thaller libnl3
thm botan2
thunderbirdtr manafirewall python-ytmusicapi
tmz fail2ban
tomh pyosmium
tomspur python-numpydoc python-zmq
trawets system-storage-manager
trix lensfun
ttheisen condor
ttomecek python-dockerfile-parse
twaugh python-dockerfile-parse
uraeus transmageddon
valtri condor
vanessakris shybrid
vpv python-mygpoclient
yanqiyu onboard
zawertun kitty
zbyszek python-deap python-igor python-ndindex python-pysnooper python-tables
zfridric sudo
zkabelac lvm2
zmiklank distgen
On 6/13/23 14:02, Tomas Hrnciar wrote:
Monday, June 26, 2023
ELN: Mass-rebuild has started
Just a heads-up that we've begun the targeted mass-rebuild for Fedora
ELN. It's running in Koji's "background" priority, so it should
hopefully not significantly impact other builds. My estimate is that
it will be running for about the next two days, followed up by manual
rebuilds for flaky tests/network hiccoughs, etc.
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
ELN. It's running in Koji's "background" priority, so it should
hopefully not significantly impact other builds. My estimate is that
it will be running for about the next two days, followed up by manual
rebuilds for flaky tests/network hiccoughs, etc.
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)
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 is the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. JDKs in fedora are already static, and we repack portable
tarballs into RPMs. Currently, the portable tarball is built for each
Fedora and EPEL version. Goal here is to build each JDK
(8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
all live Fedoras. If jdk is buitl in epel, it will be built in oldest
possible epel and repacked in newer live epels.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek@redhat.com
== Detailed Description ==
As described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
during last year, packaging of JDKs had changed dramatically. As
described in the same wiki page and in individual sub changes and
devel threads, the primary reason for this is to lower maintenance and
still keep Fedora Java friendly.
* In the first system wide change, we have changed the JDKs to build
properly as standalone, portable JDK - the way JDK is supposed to be
built. I repeat, we spent ten years by patching JDK to become properly
dynamic against system libs, and all patches went upstream, but this
has become a fight which can not be won.
* As a second step we introduced portable RPMs, which do not have any
system integration, only build JDK and pack the final tarball in RPM
for Fedora use.
* In third step - without any noise, just verified with fesco -
https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
integrated RPMs. Instead of this, normal RPMs BUildRequire portable
RPMs and just unpack it, and repack it.
Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
oldest live Fedora, and repack everywhere. java-latest-openjdk, which
contains latests STS JDK - currently 20, soon briefly 21 and a bit
after 22... If we would built java-latest-openjdk in oldest live EPEL
- epel8 now, we have verified, that such repacked JDKs works fine,
however repack from epel seem to not be acceptable, thus
ajva-latest-openjdk will be built twice - one in oldest live fedora,
and once in oldest live epel. Build forme oldest possible epel will be
repacked to that one or newer epels, and build from oldest live fedroa
to all fedoras.
=== theoretical tagging solution ===
1. request side tags for all releases
2. build the actual Java in the side tag for the oldest thing
3. tag the result ot (2) to all side tags from (1)
4. waitrepo them
5. build the repacked java packages in all the side tags from (1)
6. untag the result of (2) from all the side tags from (1)
7. ship bodhi updates from side tags OR retag the builds to candidate tags
(and delete the side tags)
The build from (2) will be eventually garbage collected. To prevent that, it
might be re-tagged regularly. This is where releng might be able to help by
creating a long lived tag to tag this into for preserving.
Yes, we could make a 'fN-openjdk' tag and mark it protected... that part
would be easy enough.
==== including portable srpms in release (improving of step 6) ====
To include portable rpms in all live Fedoras is currently not
possible. Best solution would be simply make and bodhi update of one
portable rpm to all live fedoras. Bodhi is currenlty not capable to do
so, issue was raised:
https://github.com/fedora-infra/bodhi/issues/5387 investigating
possibility to deliver single build as update to several releases.
"..It's not possible ATM, it would require a heavy rewrite of the
code, starting from the database structure (every build is now related
to a single release)..." Maybe on long run..."
On long run, if bodhi will allow this, that will be way to go.
On short run, there are following options:
a) ask releng to tag the portables directly
- this needs manual approach of rare humans, thus no go unless
strictly enforced by unpredicted conditions
- this walks around whole testing repos. For portables tarballs, as
nothing should depend on them, and are tested indirectly after repack,
this should be technically ok, but is heavily discouraged in
principle.
b) build portable for all OSes, but do not ship them (don't do bodhi update)
- this would probably work for all frontiers, only the real
repacked JDK will be different
- pros is, that we will be sure that portables builds on live fedoras
- cons is, that the portable JDK will not be available by dnf install anyway
c) build portable for all OSes, including bodhi update
- pros is, that we will be sure that portables builds on live fedoras
- another pros is that the portable JDK will be available by dnf
install anyway
- there may be clash during the build which will cause to repack
wrong (newer, non certified) portables
d) include SRPM_REBUILD.readme in srpm and generated
PORTABLES_INSTALL.readme in RPMs, which will ideally at least contain:
- instruction why you need portables
- instruction how to find the portables
- from SRPM_REBUILD.readme pointing to PORTABLES_INSTALL.readme
- generated link to the koji, allowing to download the SRPM
- generated link to the koji, allowing to download the binaries
- generated instruction how to dnf install used portables
I would currently vote for d). If there will be complains about broken
SRPM rebuild, or need to install portables without hacking, then
fall-back a, b or c via Change Proposal.
Once Bodhi allows single build to be tagged to several release, I will
move to that.
== Feedback ==
== Benefit to Fedora ==
Java maintainers will finally have some free time... No kidding -
maintenance and *certification* of so much supported JDKs on so much
Fedora versions is brutal. By building once, and repack, we will
regain cycles to continue support Fedora with all LTS and one STS JDK.
If we fail to build once and repack everywhere, Java maintainers will
most likely need to lower the number of JDKs in fedora to system one
only.
== Scope ==
* Proposal owners: Technically all JDKs (except 8, where some more
tuning is needed, and EPEL for java-latest) are prepared, as they have
a portable version, and RPMs just repack it. Except tuning up the JDK8
and EPEL for latest, scope owners are done.
* Other developers: There will be needed significant support from RCM
and maybe senior Fedora leadership to help to finish the build in
oldest and enable to repack everywhere
* '''Release engineering: [https://pagure.io/releng/issue/11438
#11438]''' There will be needed significant support from RCM, where
I'm actually unsure what they will have to do to enable this. The mas
rebuild will not be needed.
* Policies and guidelines: AFAIK none (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: All supported JDKs will remain
in Fedora in highest possible quality with full QA and certification,
and its packagers will not lose their minds. Note that QA will still
run on all live Fedoras, not only on the builder one.
== Upgrade/compatibility impact ==
The change should be completely transparent to any user.
== How To Test ==
`sudo dnf update/install "java*"` will install expected set of working packages.
SRPM rebuild of both portables (which were built once) and of any rpms
(from this freshly rebuild portbales) have to remain possible
== User Experience ==
The change should be absolutely transparent to any user.
== Dependencies ==
To finish this we will need heavy support from RCM, and maybe others.
Although there are precedents with such pacakge, they all bites. From
SW point of view, the dependece chain is `normal RPMs build requires
portable RPMs` and thats all.
== Contingency Plan ==
* Contingency mechanism: Even if It should be straight forward to
revert back to building per OS, it '''may be impossible for current
maintainers to save time''' for it. If this change is approved, we
will be building '''4-5''' (jdk8,11,17,sts and 21) builds for all
fedoras. If this change is not finished in time, we may '''need to
orphan some of the JDKs'''. In better case, we will be able to keep
living '''one LTS as system JDK, and java-latest-openjdk''' as future
system JDK. That is 2*(3-5) builds (rawhide, (forked,), latest live,
oldest live (oldest not yet dropped)). '''In worst case''', we may be
able to maintain only java-latest-openjdk. On long run changing it to
'''rolling system JDK,''' which are the expected 3-5 builds.
* Contingency deadline: N/A
* Blocks release? No. The change can be introduced even on the fly to
live distributions.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
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 is the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. JDKs in fedora are already static, and we repack portable
tarballs into RPMs. Currently, the portable tarball is built for each
Fedora and EPEL version. Goal here is to build each JDK
(8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
all live Fedoras. If jdk is buitl in epel, it will be built in oldest
possible epel and repacked in newer live epels.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek@redhat.com
== Detailed Description ==
As described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
during last year, packaging of JDKs had changed dramatically. As
described in the same wiki page and in individual sub changes and
devel threads, the primary reason for this is to lower maintenance and
still keep Fedora Java friendly.
* In the first system wide change, we have changed the JDKs to build
properly as standalone, portable JDK - the way JDK is supposed to be
built. I repeat, we spent ten years by patching JDK to become properly
dynamic against system libs, and all patches went upstream, but this
has become a fight which can not be won.
* As a second step we introduced portable RPMs, which do not have any
system integration, only build JDK and pack the final tarball in RPM
for Fedora use.
* In third step - without any noise, just verified with fesco -
https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
integrated RPMs. Instead of this, normal RPMs BUildRequire portable
RPMs and just unpack it, and repack it.
Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
oldest live Fedora, and repack everywhere. java-latest-openjdk, which
contains latests STS JDK - currently 20, soon briefly 21 and a bit
after 22... If we would built java-latest-openjdk in oldest live EPEL
- epel8 now, we have verified, that such repacked JDKs works fine,
however repack from epel seem to not be acceptable, thus
ajva-latest-openjdk will be built twice - one in oldest live fedora,
and once in oldest live epel. Build forme oldest possible epel will be
repacked to that one or newer epels, and build from oldest live fedroa
to all fedoras.
=== theoretical tagging solution ===
1. request side tags for all releases
2. build the actual Java in the side tag for the oldest thing
3. tag the result ot (2) to all side tags from (1)
4. waitrepo them
5. build the repacked java packages in all the side tags from (1)
6. untag the result of (2) from all the side tags from (1)
7. ship bodhi updates from side tags OR retag the builds to candidate tags
(and delete the side tags)
The build from (2) will be eventually garbage collected. To prevent that, it
might be re-tagged regularly. This is where releng might be able to help by
creating a long lived tag to tag this into for preserving.
Yes, we could make a 'fN-openjdk' tag and mark it protected... that part
would be easy enough.
==== including portable srpms in release (improving of step 6) ====
To include portable rpms in all live Fedoras is currently not
possible. Best solution would be simply make and bodhi update of one
portable rpm to all live fedoras. Bodhi is currenlty not capable to do
so, issue was raised:
https://github.com/fedora-infra/bodhi/issues/5387 investigating
possibility to deliver single build as update to several releases.
"..It's not possible ATM, it would require a heavy rewrite of the
code, starting from the database structure (every build is now related
to a single release)..." Maybe on long run..."
On long run, if bodhi will allow this, that will be way to go.
On short run, there are following options:
a) ask releng to tag the portables directly
- this needs manual approach of rare humans, thus no go unless
strictly enforced by unpredicted conditions
- this walks around whole testing repos. For portables tarballs, as
nothing should depend on them, and are tested indirectly after repack,
this should be technically ok, but is heavily discouraged in
principle.
b) build portable for all OSes, but do not ship them (don't do bodhi update)
- this would probably work for all frontiers, only the real
repacked JDK will be different
- pros is, that we will be sure that portables builds on live fedoras
- cons is, that the portable JDK will not be available by dnf install anyway
c) build portable for all OSes, including bodhi update
- pros is, that we will be sure that portables builds on live fedoras
- another pros is that the portable JDK will be available by dnf
install anyway
- there may be clash during the build which will cause to repack
wrong (newer, non certified) portables
d) include SRPM_REBUILD.readme in srpm and generated
PORTABLES_INSTALL.readme in RPMs, which will ideally at least contain:
- instruction why you need portables
- instruction how to find the portables
- from SRPM_REBUILD.readme pointing to PORTABLES_INSTALL.readme
- generated link to the koji, allowing to download the SRPM
- generated link to the koji, allowing to download the binaries
- generated instruction how to dnf install used portables
I would currently vote for d). If there will be complains about broken
SRPM rebuild, or need to install portables without hacking, then
fall-back a, b or c via Change Proposal.
Once Bodhi allows single build to be tagged to several release, I will
move to that.
== Feedback ==
== Benefit to Fedora ==
Java maintainers will finally have some free time... No kidding -
maintenance and *certification* of so much supported JDKs on so much
Fedora versions is brutal. By building once, and repack, we will
regain cycles to continue support Fedora with all LTS and one STS JDK.
If we fail to build once and repack everywhere, Java maintainers will
most likely need to lower the number of JDKs in fedora to system one
only.
== Scope ==
* Proposal owners: Technically all JDKs (except 8, where some more
tuning is needed, and EPEL for java-latest) are prepared, as they have
a portable version, and RPMs just repack it. Except tuning up the JDK8
and EPEL for latest, scope owners are done.
* Other developers: There will be needed significant support from RCM
and maybe senior Fedora leadership to help to finish the build in
oldest and enable to repack everywhere
* '''Release engineering: [https://pagure.io/releng/issue/11438
#11438]''' There will be needed significant support from RCM, where
I'm actually unsure what they will have to do to enable this. The mas
rebuild will not be needed.
* Policies and guidelines: AFAIK none (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives: All supported JDKs will remain
in Fedora in highest possible quality with full QA and certification,
and its packagers will not lose their minds. Note that QA will still
run on all live Fedoras, not only on the builder one.
== Upgrade/compatibility impact ==
The change should be completely transparent to any user.
== How To Test ==
`sudo dnf update/install "java*"` will install expected set of working packages.
SRPM rebuild of both portables (which were built once) and of any rpms
(from this freshly rebuild portbales) have to remain possible
== User Experience ==
The change should be absolutely transparent to any user.
== Dependencies ==
To finish this we will need heavy support from RCM, and maybe others.
Although there are precedents with such pacakge, they all bites. From
SW point of view, the dependece chain is `normal RPMs build requires
portable RPMs` and thats all.
== Contingency Plan ==
* Contingency mechanism: Even if It should be straight forward to
revert back to building per OS, it '''may be impossible for current
maintainers to save time''' for it. If this change is approved, we
will be building '''4-5''' (jdk8,11,17,sts and 21) builds for all
fedoras. If this change is not finished in time, we may '''need to
orphan some of the JDKs'''. In better case, we will be able to keep
living '''one LTS as system JDK, and java-latest-openjdk''' as future
system JDK. That is 2*(3-5) builds (rawhide, (forked,), latest live,
oldest live (oldest not yet dropped)). '''In worst case''', we may be
able to maintain only java-latest-openjdk. On long run changing it to
'''rolling system JDK,''' which are the expected 3-5 builds.
* Contingency deadline: N/A
* Blocks release? No. The change can be introduced even on the fly to
live distributions.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
F39 Change Proposal: LLVM 17 (System-Wide)
https://fedoraproject.org/wiki/Changes/LLVM-17
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 ==
Update all llvm sub-projects in Fedora Linux to version 17.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar@redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 17, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang16, llvm16, and lld16 will be added to
ensure that packages that currently depend on clang and llvm version
16 libraries will continue to work.
Other notable changes:
* The Clang Resource Directory will be moved from /usr/lib64/clang/17/
to /usr/lib/clang/17/ this is the location of clang's internal headers
and runtime libraries like libomp and compiler-rt. Package owners of
packages that read or write this directory will need to update their
packages when rebuilding against/with LLVM 17. The
%clang_resource_dir helper macro can be used to make this transition
smoother, and packages are encouraged to update to use this macro even
before the LLVM 17 update.
* Along with the Clang Resource Directory change, compiler-rt will now
install its libraries into /usr/lib/clang/17/lib/$TRIPLE/ instead of
/usr/lib64/clang/17/lib/
* The macros.clang file with RPM macros will be moved from the
clang-devel package to the clang-resource-filesystem package.
===LLVM Build Schedule===
We will be changing our build schedule slightly from previous Fedora
releases. We will now plan to ship a release candidate in Fedora
build prior to the Beta Freeze rather than waiting until after.
====Important Dates====
* July 28: Upstream: 17.0.0-rc1 Release
* Aug 8: Fedora: f39 branch created
* Aug 11: Upstream: 17.0.0-rc2 Release
* Aug 22: Fedora: f39 Beta Freeze
* Aug 25: Upstream: 17.0.0-rc3 Release
* Sep 8: Upstream: 17.0.0 Release
* Oct 10: Fedora: f39 Final Freeze
====Plan====
# Build LLVM 17.0.0-rc1 in COPR.
# Build LLVM 17.0.0-rc1 into a rawhide side-tag in Koji.
# Build LLVM 17.0.0-rc1 into a f39 side-tag in Koji.
# Build LLVM 17.0.0-rc2 into a rawhide side-tag in Koji.
# Build LLVM 17.0.0-rc2 into a f39 side-tag in Koji.
# Push F39 Bodhi Update with 17.0.0-rc2 (or 17.0.0-rc1 if -rc2 is not
ready) prior to the Beta Freeze.
# Continue building new release candidates and pushing them to stable
until the Final Freeze.
We are not planning to push 17.0.0-rc1 into rawhide because the
library ABI is not stabilized at that point. Typically, the ABI
stabilizes after -rc2, but there are no guarantees from upstream about
this. Given the history of minimal ABI changes after -rc2, we feel
like it's safe to push -rc2 into rawhide. The worst case scenario
would be an ABI change -rc3 that we force us to patch LLVM to maintain
compatibility with the -rc2 ABI. This scenario would not require
rebuilding LLVM library uses in Fedora, so this would not require much
extra work from our team.
Updates after 17.0.0-rc2 will generally be very small and can be done
after the Final Freeze is over. If we are late packaging -rc3 or the
final release, we will not ask for a Final Freeze exception, unless
they contain a fix for a critical release blocking bug.
== Feedback ==
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Do scratch builds of Fedora packages that depend on llvm and report
issues to package maintainer.
* Other developers:
** Fix build issues found with LLVM-17 or switch their package to use
the llvm16 compat libs. The LLVM team no longer plans to block Bodhi
updates on dependent packages that fail to build or run with LLVM-17.
There should be around 6-8 weeks between when -rc1 lands in koji and
the Final Freeze for package maintainers to fix issues uncovered with
the LLVM-17 update.
* Release engineering: [https://pagure.io/releng/issues/11455]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
17.
== User Experience ==
== Dependencies ==
Packages that depend on one of the llvm packages will need to be
updated to work with LLVM17 or will need to switch to using one of the
llvm16 compat packages.
== Contingency Plan ==
* Contingency mechanism: If there are major problems with LLVM 17,
the compatibility package provide a way for other packages to continue
using LLVM 16.
* Contingency deadline: Beta Freeze
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 17:
*llvm
*clang
*lld
*lldb
*compiler-rt
*libomp
*llvm-test-suite
*libcxx
*python-lit
*flang
*mlir
*polly
*libclc
*llvm-bolt
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
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 ==
Update all llvm sub-projects in Fedora Linux to version 17.
== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar@redhat.com>
== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 17, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang16, llvm16, and lld16 will be added to
ensure that packages that currently depend on clang and llvm version
16 libraries will continue to work.
Other notable changes:
* The Clang Resource Directory will be moved from /usr/lib64/clang/17/
to /usr/lib/clang/17/ this is the location of clang's internal headers
and runtime libraries like libomp and compiler-rt. Package owners of
packages that read or write this directory will need to update their
packages when rebuilding against/with LLVM 17. The
%clang_resource_dir helper macro can be used to make this transition
smoother, and packages are encouraged to update to use this macro even
before the LLVM 17 update.
* Along with the Clang Resource Directory change, compiler-rt will now
install its libraries into /usr/lib/clang/17/lib/$TRIPLE/ instead of
/usr/lib64/clang/17/lib/
* The macros.clang file with RPM macros will be moved from the
clang-devel package to the clang-resource-filesystem package.
===LLVM Build Schedule===
We will be changing our build schedule slightly from previous Fedora
releases. We will now plan to ship a release candidate in Fedora
build prior to the Beta Freeze rather than waiting until after.
====Important Dates====
* July 28: Upstream: 17.0.0-rc1 Release
* Aug 8: Fedora: f39 branch created
* Aug 11: Upstream: 17.0.0-rc2 Release
* Aug 22: Fedora: f39 Beta Freeze
* Aug 25: Upstream: 17.0.0-rc3 Release
* Sep 8: Upstream: 17.0.0 Release
* Oct 10: Fedora: f39 Final Freeze
====Plan====
# Build LLVM 17.0.0-rc1 in COPR.
# Build LLVM 17.0.0-rc1 into a rawhide side-tag in Koji.
# Build LLVM 17.0.0-rc1 into a f39 side-tag in Koji.
# Build LLVM 17.0.0-rc2 into a rawhide side-tag in Koji.
# Build LLVM 17.0.0-rc2 into a f39 side-tag in Koji.
# Push F39 Bodhi Update with 17.0.0-rc2 (or 17.0.0-rc1 if -rc2 is not
ready) prior to the Beta Freeze.
# Continue building new release candidates and pushing them to stable
until the Final Freeze.
We are not planning to push 17.0.0-rc1 into rawhide because the
library ABI is not stabilized at that point. Typically, the ABI
stabilizes after -rc2, but there are no guarantees from upstream about
this. Given the history of minimal ABI changes after -rc2, we feel
like it's safe to push -rc2 into rawhide. The worst case scenario
would be an ABI change -rc3 that we force us to patch LLVM to maintain
compatibility with the -rc2 ABI. This scenario would not require
rebuilding LLVM library uses in Fedora, so this would not require much
extra work from our team.
Updates after 17.0.0-rc2 will generally be very small and can be done
after the Final Freeze is over. If we are late packaging -rc3 or the
final release, we will not ask for a Final Freeze exception, unless
they contain a fix for a critical release blocking bug.
== Feedback ==
== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.
== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Do scratch builds of Fedora packages that depend on llvm and report
issues to package maintainer.
* Other developers:
** Fix build issues found with LLVM-17 or switch their package to use
the llvm16 compat libs. The LLVM team no longer plans to block Bodhi
updates on dependent packages that fail to build or run with LLVM-17.
There should be around 6-8 weeks between when -rc1 lands in koji and
the Final Freeze for package maintainers to fix issues uncovered with
the LLVM-17 update.
* Release engineering: [https://pagure.io/releng/issues/11455]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
This change should not impact upgradeability.
== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
17.
== User Experience ==
== Dependencies ==
Packages that depend on one of the llvm packages will need to be
updated to work with LLVM17 or will need to switch to using one of the
llvm16 compat packages.
== Contingency Plan ==
* Contingency mechanism: If there are major problems with LLVM 17,
the compatibility package provide a way for other packages to continue
using LLVM 16.
* Contingency deadline: Beta Freeze
== Documentation ==
Release notes will be added for this change.
== Release Notes ==
LLVM sub-projects in Fedora have been updated to version 17:
*llvm
*clang
*lld
*lldb
*compiler-rt
*libomp
*llvm-test-suite
*libcxx
*python-lit
*flang
*mlir
*polly
*libclc
*llvm-bolt
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
F39 Change Proposal: Improve Default Font Handling with default-fonts metapackages (System-Wide)
https://fedoraproject.org/wiki/Changes/ImproveDefaultFontHandling
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 aims to make default fonts easier to update and install for all
the variants on Fedora and reduce the maintenance costs for them.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]]
* Email: <tagoh AT redhat DOT com>
* Name: [[User:Pnemade|Parag Nemade]]
* Email: <pnemade AT redhat DOT com>
== Detailed Description ==
Currently there are multiple sources to manage what font packages
should be installed for a Fedora release and spins, such as comps,
langpacks, lorax, workstation-ostree-config, and fedora-kickstarts,
which makes it complicated to make default default fonts changes.
New default-fonts metapackages will be added to langpacks, some of
which will replace the default font listed in `@fonts`, etc. Then
going forward those lists of metapackages should only need to be
changed quite rarely.
* `default-fonts` metapackage to pull in:
** `default-fonts-core` metapackage to pull in:
*** `default-fonts-core-sans`, `default-fonts-core-serif`,
`default-fonts-core-mono`, `default-fonts-core-emoji`,
`default-fonts-core-math`
**** Metapackages to pull in the default fonts for Western characters and Emoji
** `default-fonts-cjk` metapackage to pull in:
*** `default-fonts-cjk-sans`, `default-fonts-cjk-serif`,
`default-fonts-cjk-mono`
**** Metapackages to pull in the default fonts for Chinese, Japanese, and Korean
** `default-fonts-other` metapackage to pull in:
*** `default-fonts-other-sans`, `default-fonts-other-serif`,
`default-fonts-other-mono`
**** Metapackages to pull in the default fonts for other (non-CJK) languages
* `default-fonts-<language code>`
** Metapackages to pull in a default fonts for a specific language
* `default-fonts-extra-<language code>`
** Metapackages to pull in extra fonts for a certain languages if any
== Feedback ==
== Benefit to Fedora ==
This Change provides the easier way to manage and install our default
fonts on Fedora. In current package sets, langpacks offers non-fonts
packages to be installed even though one don't want to install them.
After this Change, one doesn't need to install those extra
dependencies for the purpose of the font installation.
== Scope ==
* Proposal owners:
** update the fedora-comps @fonts group and workstation-ostree-config
to use the new default-fonts packages
** fontconfig package default font dependency to be updated
** optionally update lorax to use the new default fonts (if they no
longer need to remove many fonts files since most are now variable
fonts anyway), otherwise it can be done for Fedora 40.
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
Currently installed langpacks packages will pull in the appropriate
default-fonts packages when upgrading.
Using default-fonts meta-packages means that users will get upgraded
to new default fonts seamlessly going forward.
This should provide a more reliable font experience since default
fonts should have higher fontconfig priority.
== How To Test ==
# Install the above meta packages
# See what font packages will be pulled in
We have a copr repo for early testing. You can try to install the
updated langpacks if you like.
https://copr.fedorainfracloud.org/coprs/tagoh/langpacks-v4/
== User Experience ==
Users will automatically be moved to any new/changed default system
fonts when they upgrade to a newer version of Fedora.
It will be easier for users to remove CJK or non-core fonts from their
system if they really want to, or to add them in minimal
installations.
== Dependencies ==
No. Updated langpacks still have compatibility on existing
dependencies. This Change can be done in langpacks only.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** Change owners will revert the relevant changes.
== Documentation ==
None
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
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 aims to make default fonts easier to update and install for all
the variants on Fedora and reduce the maintenance costs for them.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]]
* Email: <tagoh AT redhat DOT com>
* Name: [[User:Pnemade|Parag Nemade]]
* Email: <pnemade AT redhat DOT com>
== Detailed Description ==
Currently there are multiple sources to manage what font packages
should be installed for a Fedora release and spins, such as comps,
langpacks, lorax, workstation-ostree-config, and fedora-kickstarts,
which makes it complicated to make default default fonts changes.
New default-fonts metapackages will be added to langpacks, some of
which will replace the default font listed in `@fonts`, etc. Then
going forward those lists of metapackages should only need to be
changed quite rarely.
* `default-fonts` metapackage to pull in:
** `default-fonts-core` metapackage to pull in:
*** `default-fonts-core-sans`, `default-fonts-core-serif`,
`default-fonts-core-mono`, `default-fonts-core-emoji`,
`default-fonts-core-math`
**** Metapackages to pull in the default fonts for Western characters and Emoji
** `default-fonts-cjk` metapackage to pull in:
*** `default-fonts-cjk-sans`, `default-fonts-cjk-serif`,
`default-fonts-cjk-mono`
**** Metapackages to pull in the default fonts for Chinese, Japanese, and Korean
** `default-fonts-other` metapackage to pull in:
*** `default-fonts-other-sans`, `default-fonts-other-serif`,
`default-fonts-other-mono`
**** Metapackages to pull in the default fonts for other (non-CJK) languages
* `default-fonts-<language code>`
** Metapackages to pull in a default fonts for a specific language
* `default-fonts-extra-<language code>`
** Metapackages to pull in extra fonts for a certain languages if any
== Feedback ==
== Benefit to Fedora ==
This Change provides the easier way to manage and install our default
fonts on Fedora. In current package sets, langpacks offers non-fonts
packages to be installed even though one don't want to install them.
After this Change, one doesn't need to install those extra
dependencies for the purpose of the font installation.
== Scope ==
* Proposal owners:
** update the fedora-comps @fonts group and workstation-ostree-config
to use the new default-fonts packages
** fontconfig package default font dependency to be updated
** optionally update lorax to use the new default fonts (if they no
longer need to remove many fonts files since most are now variable
fonts anyway), otherwise it can be done for Fedora 40.
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
Currently installed langpacks packages will pull in the appropriate
default-fonts packages when upgrading.
Using default-fonts meta-packages means that users will get upgraded
to new default fonts seamlessly going forward.
This should provide a more reliable font experience since default
fonts should have higher fontconfig priority.
== How To Test ==
# Install the above meta packages
# See what font packages will be pulled in
We have a copr repo for early testing. You can try to install the
updated langpacks if you like.
https://copr.fedorainfracloud.org/coprs/tagoh/langpacks-v4/
== User Experience ==
Users will automatically be moved to any new/changed default system
fonts when they upgrade to a newer version of Fedora.
It will be easier for users to remove CJK or non-core fonts from their
system if they really want to, or to add them in minimal
installations.
== Dependencies ==
No. Updated langpacks still have compatibility on existing
dependencies. This Change can be done in langpacks only.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** Change owners will revert the relevant changes.
== Documentation ==
None
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
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 new PatternFly-based UI has been developed by the Anaconda team
for some time now and we would like to make it available for users of
Fedora to enhance and modernize installation experience. As the first
step in this user adoption process, we are targeting Fedora
Workstation only.
== Owner ==
* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
* Email: jkonecny@redhat.com
* Name: Fedora Workstation SIG
* Email: desktop@lists.fedoraproject.org
== Detailed Description ==
The Anaconda team has been working on a new web-based UI for the OS
installer for some time. We would like to give users the fruits of our
work and get feedback so that we know what we need to improve or where
we should focus.
To make the adoption as painless as possible, the Fedora Workstation
was chosen as the first target so we have better control over the
environment and can have a focus. Also, Fedora Workstation has a
smaller featureset than other installation media. The adoption for the
other media later is planned too, but the exact date will be based on
feedback and our capacity allowance.
=== What will '''not''' change with the new Web UI? ===
The new UI will mostly use already existing functional code (some
modifications are necessary), so the stability should be similar. The
Anaconda specific kernel boot parameters are also staying almost
unchanged. The Anaconda team aims to reduce functionality that is not
used but still put a maintenance burden on the team. This should
result in much easier future extensions and stability of the
installer. The current approach is to start from what is known to be
required and used, then add future features based on the feedback.
=== What is going to change with the new Web UI? ===
The new web UI is not just a change of the UI technology, which is
based on the React and Cockpit framework, but also a complete overhaul
of the user experience. The new UI is trying to be easier to use by
removing most of the complexities but still leaving possibilities to
do everything you might need to do. We are trying to achieve a state
where even users who don't have previous experience with the Linux
operating system will be able to do the installation smoothly.
List of what is part of the new UI:
* Wizard solution instead of hub and spoke
* New welcome screen to select language (will be preselected from a
language configured in system)
* Timezone and date configuration
* Disk selection
* Guided partitioning
* Review configuration
* Installation progress
* Build-in help
Let's go over the important sections from the UI.
==== Use of wizard ====
Anaconda was a hub&spoke solution where users entered spoke to
configure an aspect. The benefit of this solution is that you can skip
what you don't need. However, the drawback is that it's much more
information at once and harder to use when you are not familiar with
what you need. For that reason, the team decided to go with an easier
to use solution, the traditional wizard. See here for more details
https://communityblog.fedoraproject.org/anaconda-is-getting-a-new-suit-and-a-wizard/
.
==== Guided partitioning ====
The current (GTK) Anaconda UI approach is to have three types of partitioning.
* Automatic - do everything automatically
* Custom - you can do everything with top-down approach where users
work on mount points and specified what technology they want to use
and how
* Blivet-gui - added later as bottom-up approach which enables users
to create the partitioning stack themselves manually
These methods are giving great freedom but each of these has its
issues. For automatic, the issue is almost no customizations and not a
clear output. For custom and blivet-gui, you need to understand the
Linux storage really well to know what you are doing, which could be
intimidating.
Because of those issues, we decided to choose another approach, which
we are calling guided partitioning. This type of partitioning is
giving users paths with explanations of what will happen but does not
overload them with too many options at once. These paths could be then
customized. This solution was taken as the best compromise between the
automatic (no customization) and custom/blivet-gui, which was too
heavy and hard to maintain.
We will provide the recommended solution and improved customization
based on the users feedback. However, in case someone is not happy
about the recommended solution, we are going to provide a way to guide
users, to create their partitioning themselves (with a tool of their
choice) and then tell Anaconda how to use it. This method could be
also used for easy re-installation of the existing system and we are
planning to improve the experience in the future even more.
==== Build-in help ====
Another pain point of the current UI is problematic help content.
Currently, it's a button that will show a lot of text from the
documentation, which might be misleading because it's not part of the
feature development. To improve the state, the help side panel was
added, which will provide specific help for what the user wants to
know directly in a UI. For example, if you are in the guided
partitioning screen you can find a link (blue text) with "learn more
about the…" and after clicking on this you will find details about the
given guided path. Another benefit of the new help solution is that it
is part of the source code so it changes with the feature work and
could be localized (harder to achieve before).
==== Changes not directly related to UI ====
The Anaconda team is in contact with Fedora Workstation SIG and
actively working with them to get the best user experience for users.
Together, we agreed on building the approach with the support of Gnome
Initial Setup as part of the Fedora Workstation Live environment,
which will prompt you for language and keyboard layout. Configuration
from the system is then used by Anaconda. This way, Anaconda doesn't
need to ask a second time for language (maybe just confirmation) and
keyboard layout which will be converted from the live system into the
installed system. This should result in a much better user experience.
=== Additional information ===
* We are not planning to add support for spins with this change, they
will use the existing GTK UI.
* We don't support remote connections to the WebUI yet.
== Feedback ==
Currently we mainly discuss this with Fedora Workstation SIG and have
their support for this change. We also have feedback from our preview
builds https://fedoramagazine.org/anaconda-web-ui-preview-image-now-public/
. The feedback was mostly positive even though there are some
concerns.
Other than that we also reached to Fedora QE team and [[User:Mattdm|
Matthew Miller]] and more.
For more details about the feedback here are some tickets:
* https://pagure.io/fedora-workstation/issue/362
* https://pagure.io/fedora-workstation/issue/366
* https://pagure.io/fedora-workstation/issue/367
* https://pagure.io/fedora-workstation/issue/368
* https://pagure.io/fedora-workstation/issue/371
* https://pagure.io/fedora-workstation/issue/375
* https://pagure.io/fedora-workstation/issue/377
* https://github.com/rhinstaller/anaconda/discussions/categories/web-ui
== Benefit to Fedora ==
Fedora Workstation installation will have a more comfortable and
better user experience, especially for the new-to-distro users. We are
also targeting to have a consistent look and feel with Cockpit and
Image Builder projects, so that users might be more familiar with the
new Anaconda.
By this, we would be more aligned with Fedora Workstation SIG goals of
simple and easy-to-use solutions, and hide the complexities to make
the installation experience more robust.
It should be easier for users to reinstall the existing system.
It will also allow the Anaconda team to make the extensions to the UI
faster than it was before and should be less prone to errors compared
to the current UI.
== Scope ==
* Proposal owners:
** Anaconda team
** Fedora Workstation SIG
* Other developers: Should not have impact out of the Fedora
Workstation Live environment.
* Release engineering: Will be added
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: TBD
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
Standard installation testing of Live installation always before. We
already reached the Fedora QE team to discuss an impact on them and
ideally set the test day for more comprehensive testing with more
details.
Steps:
* Download the ISO image (not yet available - WIP)
* Start a VM with this ISO image
* Run the installation
* See journal log and/or browser console in case we missed error in the Anaconda
Bugs should be filed to [https://bugzilla.redhat.com/ Red Hat
Bugzilla] on the Anaconda component.
== User Experience ==
Installation of the system should provide a much better and more
polished user experience. Compared to the current UI users should be
fine without the familiarity of the complexities of OS installation.
== Dependencies ==
None packages should be impacted by this change. The current GTK UI
will still be available for other uses.
== Contingency Plan ==
* Contingency mechanism: Return back to the current GTK UI by changing
packages to build the ISO.
* Contingency deadline: Beta freeze
* Blocks release? No, we can ship without the new web UI
Another solution for the contingency plan which we would like to have
is support for the current GTK UI as a second UI on the same Live ISO.
That should be doable easily and if the new UI would be really a
blocker for someone, they can provide us feedback and until resolved
use the GTK UI instead.
== Documentation ==
Documentation will be expected especially for custom partitioning
replacement but not only that.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
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 new PatternFly-based UI has been developed by the Anaconda team
for some time now and we would like to make it available for users of
Fedora to enhance and modernize installation experience. As the first
step in this user adoption process, we are targeting Fedora
Workstation only.
== Owner ==
* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
* Email: jkonecny@redhat.com
* Name: Fedora Workstation SIG
* Email: desktop@lists.fedoraproject.org
== Detailed Description ==
The Anaconda team has been working on a new web-based UI for the OS
installer for some time. We would like to give users the fruits of our
work and get feedback so that we know what we need to improve or where
we should focus.
To make the adoption as painless as possible, the Fedora Workstation
was chosen as the first target so we have better control over the
environment and can have a focus. Also, Fedora Workstation has a
smaller featureset than other installation media. The adoption for the
other media later is planned too, but the exact date will be based on
feedback and our capacity allowance.
=== What will '''not''' change with the new Web UI? ===
The new UI will mostly use already existing functional code (some
modifications are necessary), so the stability should be similar. The
Anaconda specific kernel boot parameters are also staying almost
unchanged. The Anaconda team aims to reduce functionality that is not
used but still put a maintenance burden on the team. This should
result in much easier future extensions and stability of the
installer. The current approach is to start from what is known to be
required and used, then add future features based on the feedback.
=== What is going to change with the new Web UI? ===
The new web UI is not just a change of the UI technology, which is
based on the React and Cockpit framework, but also a complete overhaul
of the user experience. The new UI is trying to be easier to use by
removing most of the complexities but still leaving possibilities to
do everything you might need to do. We are trying to achieve a state
where even users who don't have previous experience with the Linux
operating system will be able to do the installation smoothly.
List of what is part of the new UI:
* Wizard solution instead of hub and spoke
* New welcome screen to select language (will be preselected from a
language configured in system)
* Timezone and date configuration
* Disk selection
* Guided partitioning
* Review configuration
* Installation progress
* Build-in help
Let's go over the important sections from the UI.
==== Use of wizard ====
Anaconda was a hub&spoke solution where users entered spoke to
configure an aspect. The benefit of this solution is that you can skip
what you don't need. However, the drawback is that it's much more
information at once and harder to use when you are not familiar with
what you need. For that reason, the team decided to go with an easier
to use solution, the traditional wizard. See here for more details
https://communityblog.fedoraproject.org/anaconda-is-getting-a-new-suit-and-a-wizard/
.
==== Guided partitioning ====
The current (GTK) Anaconda UI approach is to have three types of partitioning.
* Automatic - do everything automatically
* Custom - you can do everything with top-down approach where users
work on mount points and specified what technology they want to use
and how
* Blivet-gui - added later as bottom-up approach which enables users
to create the partitioning stack themselves manually
These methods are giving great freedom but each of these has its
issues. For automatic, the issue is almost no customizations and not a
clear output. For custom and blivet-gui, you need to understand the
Linux storage really well to know what you are doing, which could be
intimidating.
Because of those issues, we decided to choose another approach, which
we are calling guided partitioning. This type of partitioning is
giving users paths with explanations of what will happen but does not
overload them with too many options at once. These paths could be then
customized. This solution was taken as the best compromise between the
automatic (no customization) and custom/blivet-gui, which was too
heavy and hard to maintain.
We will provide the recommended solution and improved customization
based on the users feedback. However, in case someone is not happy
about the recommended solution, we are going to provide a way to guide
users, to create their partitioning themselves (with a tool of their
choice) and then tell Anaconda how to use it. This method could be
also used for easy re-installation of the existing system and we are
planning to improve the experience in the future even more.
==== Build-in help ====
Another pain point of the current UI is problematic help content.
Currently, it's a button that will show a lot of text from the
documentation, which might be misleading because it's not part of the
feature development. To improve the state, the help side panel was
added, which will provide specific help for what the user wants to
know directly in a UI. For example, if you are in the guided
partitioning screen you can find a link (blue text) with "learn more
about the…" and after clicking on this you will find details about the
given guided path. Another benefit of the new help solution is that it
is part of the source code so it changes with the feature work and
could be localized (harder to achieve before).
==== Changes not directly related to UI ====
The Anaconda team is in contact with Fedora Workstation SIG and
actively working with them to get the best user experience for users.
Together, we agreed on building the approach with the support of Gnome
Initial Setup as part of the Fedora Workstation Live environment,
which will prompt you for language and keyboard layout. Configuration
from the system is then used by Anaconda. This way, Anaconda doesn't
need to ask a second time for language (maybe just confirmation) and
keyboard layout which will be converted from the live system into the
installed system. This should result in a much better user experience.
=== Additional information ===
* We are not planning to add support for spins with this change, they
will use the existing GTK UI.
* We don't support remote connections to the WebUI yet.
== Feedback ==
Currently we mainly discuss this with Fedora Workstation SIG and have
their support for this change. We also have feedback from our preview
builds https://fedoramagazine.org/anaconda-web-ui-preview-image-now-public/
. The feedback was mostly positive even though there are some
concerns.
Other than that we also reached to Fedora QE team and [[User:Mattdm|
Matthew Miller]] and more.
For more details about the feedback here are some tickets:
* https://pagure.io/fedora-workstation/issue/362
* https://pagure.io/fedora-workstation/issue/366
* https://pagure.io/fedora-workstation/issue/367
* https://pagure.io/fedora-workstation/issue/368
* https://pagure.io/fedora-workstation/issue/371
* https://pagure.io/fedora-workstation/issue/375
* https://pagure.io/fedora-workstation/issue/377
* https://github.com/rhinstaller/anaconda/discussions/categories/web-ui
== Benefit to Fedora ==
Fedora Workstation installation will have a more comfortable and
better user experience, especially for the new-to-distro users. We are
also targeting to have a consistent look and feel with Cockpit and
Image Builder projects, so that users might be more familiar with the
new Anaconda.
By this, we would be more aligned with Fedora Workstation SIG goals of
simple and easy-to-use solutions, and hide the complexities to make
the installation experience more robust.
It should be easier for users to reinstall the existing system.
It will also allow the Anaconda team to make the extensions to the UI
faster than it was before and should be less prone to errors compared
to the current UI.
== Scope ==
* Proposal owners:
** Anaconda team
** Fedora Workstation SIG
* Other developers: Should not have impact out of the Fedora
Workstation Live environment.
* Release engineering: Will be added
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: TBD
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
Standard installation testing of Live installation always before. We
already reached the Fedora QE team to discuss an impact on them and
ideally set the test day for more comprehensive testing with more
details.
Steps:
* Download the ISO image (not yet available - WIP)
* Start a VM with this ISO image
* Run the installation
* See journal log and/or browser console in case we missed error in the Anaconda
Bugs should be filed to [https://bugzilla.redhat.com/ Red Hat
Bugzilla] on the Anaconda component.
== User Experience ==
Installation of the system should provide a much better and more
polished user experience. Compared to the current UI users should be
fine without the familiarity of the complexities of OS installation.
== Dependencies ==
None packages should be impacted by this change. The current GTK UI
will still be available for other uses.
== Contingency Plan ==
* Contingency mechanism: Return back to the current GTK UI by changing
packages to build the ISO.
* Contingency deadline: Beta freeze
* Blocks release? No, we can ship without the new web UI
Another solution for the contingency plan which we would like to have
is support for the current GTK UI as a second UI on the same Live ISO.
That should be doable easily and if the new UI would be really a
blocker for someone, they can provide us feedback and until resolved
use the GTK UI instead.
== Documentation ==
Documentation will be expected especially for custom partitioning
replacement but not only that.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
F39 Change Proposal: Allow Removal of tzdata (System-Wide)
https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
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 ==
Allow the removal of tzdata especially on containers in order to minimize size.
== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: patsy@redhat.com
== Detailed Description ==
This change will allow the removal of tzdata. When tzdata is removed,
the system will default to UTC. In order to reduce overhead, many
container installations now remove the data associated with tzdata but
cannot fully remove the package due to dependencies by other packages.
This results in confusion regarding the expected timezone info.
In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata. These
packages should also gracefully handle instances where tzdata has been
removed. For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.
== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone. As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.
== Benefit to Fedora ==
This change will allow tzdata to be removed from containers without
leaving inconsistent package remnants.
== Scope ==
* Proposal owners: No changes are needed to tzdata.
* Other developers: Some packages need to change their spec files from
`Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
all packages switched in this way, but it is not required. Supporting
optional tzdata installation for as many workloads as possible allows
those workloads to minimize their container image size.
List of packages which need to be changed:
* glibc (glibc-common)
* gcc (libstdc++)
* python3.XX (3.9, 3.10, 3.11, 3.12)
List of packages which would be beneficial to be changed:
* python3-dateutil
* python3-pytz
* libical
Upon acceptance of the change request we will file bugs to fix each of
these packages for Fedora 39.
* Release engineering: No changes needed.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
If tzdata is already installed, then it continues to be installed on the system.
Following the Fedora Weak Dependencies Policy dnf will treat the
Recommends on tzdata as if it were a Requires and tzdata will always
be installed in a default system
(https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/)
However, the recommends will allow tzdata to be correctly uninstalled
in a container build file rather than having to use 'rm -rf' to delete
the zone files to recover space.
== How To Test ==
Language runtimes were installed and A/B tests carried out with tzdata
present and tzdata removed. The intent of these tests was to ensure
that the system can use the language frameworks without tzdata present
and that when the data was required that meaningful errors were
presented to the user.
Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11),
using their time and date APIs. This testing led to the correction of
the libstdc++ implementation as noted here:
https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea42b42c3
Developers can test this by installing Rawhide and uninstalling tzdata
and verifying their package operates as expected.
If tzdata cannot be uninstalled then we recommend filling a bug
against the package that Requires: tzdata and having a discussion with
the maintainer to make tzdata optional e.g. Recommends: tzdata.
== User Experience ==
The user can remove tzdata to minimize the container size.
With tzdata removed the system is UTC only.
== Dependencies ==
Fixing glibc, gcc, and python3.xx at a minimum to make tzdata
Recommends instead of Requires.
== Contingency Plan ==
* Contingency mechanism: Back out the change. Don't do it.
* Contingency deadline: Can be backed out at the last minute since we
are only dealing with conversions from Requires to Recommends.
* Blocks release? No
== Documentation ==
Document that the tzdata package may be removed if needed to reduce
space on containers. With tzdata removed, the system will default to
UTC.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
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 ==
Allow the removal of tzdata especially on containers in order to minimize size.
== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: patsy@redhat.com
== Detailed Description ==
This change will allow the removal of tzdata. When tzdata is removed,
the system will default to UTC. In order to reduce overhead, many
container installations now remove the data associated with tzdata but
cannot fully remove the package due to dependencies by other packages.
This results in confusion regarding the expected timezone info.
In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata. These
packages should also gracefully handle instances where tzdata has been
removed. For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.
== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone. As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.
== Benefit to Fedora ==
This change will allow tzdata to be removed from containers without
leaving inconsistent package remnants.
== Scope ==
* Proposal owners: No changes are needed to tzdata.
* Other developers: Some packages need to change their spec files from
`Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
all packages switched in this way, but it is not required. Supporting
optional tzdata installation for as many workloads as possible allows
those workloads to minimize their container image size.
List of packages which need to be changed:
* glibc (glibc-common)
* gcc (libstdc++)
* python3.XX (3.9, 3.10, 3.11, 3.12)
List of packages which would be beneficial to be changed:
* python3-dateutil
* python3-pytz
* libical
Upon acceptance of the change request we will file bugs to fix each of
these packages for Fedora 39.
* Release engineering: No changes needed.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
If tzdata is already installed, then it continues to be installed on the system.
Following the Fedora Weak Dependencies Policy dnf will treat the
Recommends on tzdata as if it were a Requires and tzdata will always
be installed in a default system
(https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/)
However, the recommends will allow tzdata to be correctly uninstalled
in a container build file rather than having to use 'rm -rf' to delete
the zone files to recover space.
== How To Test ==
Language runtimes were installed and A/B tests carried out with tzdata
present and tzdata removed. The intent of these tests was to ensure
that the system can use the language frameworks without tzdata present
and that when the data was required that meaningful errors were
presented to the user.
Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11),
using their time and date APIs. This testing led to the correction of
the libstdc++ implementation as noted here:
https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea42b42c3
Developers can test this by installing Rawhide and uninstalling tzdata
and verifying their package operates as expected.
If tzdata cannot be uninstalled then we recommend filling a bug
against the package that Requires: tzdata and having a discussion with
the maintainer to make tzdata optional e.g. Recommends: tzdata.
== User Experience ==
The user can remove tzdata to minimize the container size.
With tzdata removed the system is UTC only.
== Dependencies ==
Fixing glibc, gcc, and python3.xx at a minimum to make tzdata
Recommends instead of Requires.
== Contingency Plan ==
* Contingency mechanism: Back out the change. Don't do it.
* Contingency deadline: Can be backed out at the last minute since we
are only dealing with conversions from Requires to Recommends.
* Blocks release? No
== Documentation ==
Document that the tzdata package may be removed if needed to reduce
space on containers. With tzdata removed, the system will default to
UTC.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder
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 ==
Image Builder is a set of modern tools for building operating system
images. Its goal is to make the builds reliable and reproducible.
Moreover, it's designed to give the end users a simple workflow to
build their own custom images. The aim of this change is to switch the
build tool for Fedora Workstation live ISO from livemedia-creator to
Image Builder.
== Owner ==
* Name: [[User:obudai|Ondřej Budai]]
* Email: obudai@redhat.com
* Name: [[User:Supakeen|Simon de Vlieger]]
* Email: supakeen@redhat.com
* Name: [[User:jkonecny|Jiří Konečný]]
* Email: jkonecny@redhat.com
== Detailed Description ==
Image builder is currently getting support for building
[https://github.com/osbuild/osbuild-composer/pull/3440 live ISOs].
Once the PR implementing the new image type is merged,
[https://pagure.io/pungi-fedora/blob/8b2c85799cce5c096484cdebe1dbe521eaf7fe92/f/fedora.conf#_530
the pungi-fedora configuration] needs to be updated. This change will
ensure that pungi creates an osbuildImage task in koji instead of the
currently used livemedia one.
Pungi and Koji already support Image Builder, so no additional work is
required there (refer to the
[https://docs.pagure.org/pungi/configuration.html#osbuild-composer-for-building-images
pungi] and [https://github.com/osbuild/koji-osbuild/ koji]
documentation). The only missing part in terms of infrastructure is
provisioning ppc64le worker machines for Image Builder, see the
relevant [https://pagure.io/fedora-infrastructure/issue/11243
fedora-infra ticket].
Note that Image Builder is already used for
[https://fedoraproject.org/wiki/Changes/IoTArtifactsWithOSBuild
building ISOs and raw disks of Fedora IoT]. Therefore, this proposal
does not introduce a new tool to the Fedora build pipeline.
== Feedback ==
Currently, Image Builder does not populate the DNF database correctly,
leading to all RPMs installed on the target system being marked as
user-installed. This is [https://github.com/osbuild/osbuild/issues/455
a known issue] that the team is planning to address as soon as the
initial support for live ISOs is merged.
== Benefit to Fedora ==
The maintainer team of Image Builder believes that the project
undergoes more comprehensive testing compared to
lorax/livemedia-creator. Thus, by switching to Image Builder, Fedora
should experience fewer issues with the image building pipeline.
Another advantage is the project's emphasis on making Image Builder
more user-friendly. End users can easily build their own customized
version of the live ISO using a simple
[https://www.osbuild.org/guides/image-builder-on-premises/blueprint-reference.html
TOML blueprint file] and a
[https://www.osbuild.org/guides/image-builder-on-premises/building-an-image-from-cli.html
CLI interface]. This approach, utilizing well-known file formats, is a
positive step compared to livemedia-creator's kickstart files. More
information about building customized images can found on
[https://major.io/p/build-custom-centos-stream-cloud-image/ Major
Hayden's blog] or in
[https://www.youtube.com/watch?v=PsQySAEOeFs&t=17001s a conference
talk] given by Ondřej Budai, one of the proposal owners. Moreover,
Image Builder provides [https://github.com/osbuild/cockpit-composer/ a
graphical interface] for visually defining blueprints, further
simplifying the workflow.
We believe that Image Builder can also be beneficial to the
[https://fedoraproject.org/wiki/Respins-SIG Respins SIG] as it nicely
aligns with their objective of providing a simple method for building
up-to-date, customizable images.
== Scope ==
* Proposal owners:
Finishing implementing support for the live ISO upstream and
collaborate with release engineering to switch the pungi config to use
Image Builder.
* Other developers:
Our focus for this change is specifically on Fedora Workstation.
Nevertheless, we are open to collaborating with all spins/SIG to
transition their build pipelines to Image Builder. However, for the
initial switch, we aim to minimize the impact by focusing on a single
artifact. We anticipate that more artifacts will be transitioned in
subsequent releases of Fedora Linux.
* Release engineering: [https://pagure.io/releng/issue/11500 #11500]
Provide ppc64le machines to Image Builder. Switch the pungi config to
use Image Builder.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
There shouldn't be any. The goal of this proposal is to build the same
images as livemedia-creator does, just using a different tooling.
== How To Test ==
Once the pungi config is changed, grab the ISO built by Image Builder
and test if there are any unexpected changes.
== User Experience ==
No change is expected.
== Dependencies ==
The Workstation SIG and the installer team are working on a change to
use the new installer web UI for the Workstation live ISO. We are
fully aware of this change and have the capability to build ISOs with
and without the new UI. As a result, these changes should be
independent of each other. Furthermore, the installer and Image
Builder teams are closely collaborating, ensuring that any issues that
may arise can be addressed with high priority.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Release
engineering to revert the change in pungi, so that the old tooling is
used instead.
* Contingency deadline: Final freeze (the change is trivially revertible)
* Blocks release? No
== Documentation ==
N/A
== Release Notes ==
Fedora Workstations ISOs are now built using Image Builder instead of
the legacy tooling used before.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
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 ==
Image Builder is a set of modern tools for building operating system
images. Its goal is to make the builds reliable and reproducible.
Moreover, it's designed to give the end users a simple workflow to
build their own custom images. The aim of this change is to switch the
build tool for Fedora Workstation live ISO from livemedia-creator to
Image Builder.
== Owner ==
* Name: [[User:obudai|Ondřej Budai]]
* Email: obudai@redhat.com
* Name: [[User:Supakeen|Simon de Vlieger]]
* Email: supakeen@redhat.com
* Name: [[User:jkonecny|Jiří Konečný]]
* Email: jkonecny@redhat.com
== Detailed Description ==
Image builder is currently getting support for building
[https://github.com/osbuild/osbuild-composer/pull/3440 live ISOs].
Once the PR implementing the new image type is merged,
[https://pagure.io/pungi-fedora/blob/8b2c85799cce5c096484cdebe1dbe521eaf7fe92/f/fedora.conf#_530
the pungi-fedora configuration] needs to be updated. This change will
ensure that pungi creates an osbuildImage task in koji instead of the
currently used livemedia one.
Pungi and Koji already support Image Builder, so no additional work is
required there (refer to the
[https://docs.pagure.org/pungi/configuration.html#osbuild-composer-for-building-images
pungi] and [https://github.com/osbuild/koji-osbuild/ koji]
documentation). The only missing part in terms of infrastructure is
provisioning ppc64le worker machines for Image Builder, see the
relevant [https://pagure.io/fedora-infrastructure/issue/11243
fedora-infra ticket].
Note that Image Builder is already used for
[https://fedoraproject.org/wiki/Changes/IoTArtifactsWithOSBuild
building ISOs and raw disks of Fedora IoT]. Therefore, this proposal
does not introduce a new tool to the Fedora build pipeline.
== Feedback ==
Currently, Image Builder does not populate the DNF database correctly,
leading to all RPMs installed on the target system being marked as
user-installed. This is [https://github.com/osbuild/osbuild/issues/455
a known issue] that the team is planning to address as soon as the
initial support for live ISOs is merged.
== Benefit to Fedora ==
The maintainer team of Image Builder believes that the project
undergoes more comprehensive testing compared to
lorax/livemedia-creator. Thus, by switching to Image Builder, Fedora
should experience fewer issues with the image building pipeline.
Another advantage is the project's emphasis on making Image Builder
more user-friendly. End users can easily build their own customized
version of the live ISO using a simple
[https://www.osbuild.org/guides/image-builder-on-premises/blueprint-reference.html
TOML blueprint file] and a
[https://www.osbuild.org/guides/image-builder-on-premises/building-an-image-from-cli.html
CLI interface]. This approach, utilizing well-known file formats, is a
positive step compared to livemedia-creator's kickstart files. More
information about building customized images can found on
[https://major.io/p/build-custom-centos-stream-cloud-image/ Major
Hayden's blog] or in
[https://www.youtube.com/watch?v=PsQySAEOeFs&t=17001s a conference
talk] given by Ondřej Budai, one of the proposal owners. Moreover,
Image Builder provides [https://github.com/osbuild/cockpit-composer/ a
graphical interface] for visually defining blueprints, further
simplifying the workflow.
We believe that Image Builder can also be beneficial to the
[https://fedoraproject.org/wiki/Respins-SIG Respins SIG] as it nicely
aligns with their objective of providing a simple method for building
up-to-date, customizable images.
== Scope ==
* Proposal owners:
Finishing implementing support for the live ISO upstream and
collaborate with release engineering to switch the pungi config to use
Image Builder.
* Other developers:
Our focus for this change is specifically on Fedora Workstation.
Nevertheless, we are open to collaborating with all spins/SIG to
transition their build pipelines to Image Builder. However, for the
initial switch, we aim to minimize the impact by focusing on a single
artifact. We anticipate that more artifacts will be transitioned in
subsequent releases of Fedora Linux.
* Release engineering: [https://pagure.io/releng/issue/11500 #11500]
Provide ppc64le machines to Image Builder. Switch the pungi config to
use Image Builder.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
There shouldn't be any. The goal of this proposal is to build the same
images as livemedia-creator does, just using a different tooling.
== How To Test ==
Once the pungi config is changed, grab the ISO built by Image Builder
and test if there are any unexpected changes.
== User Experience ==
No change is expected.
== Dependencies ==
The Workstation SIG and the installer team are working on a change to
use the new installer web UI for the Workstation live ISO. We are
fully aware of this change and have the capability to build ISOs with
and without the new UI. As a result, these changes should be
independent of each other. Furthermore, the installer and Image
Builder teams are closely collaborating, ensuring that any issues that
may arise can be addressed with high priority.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Release
engineering to revert the change in pungi, so that the old tooling is
used instead.
* Contingency deadline: Final freeze (the change is trivially revertible)
* Blocks release? No
== Documentation ==
N/A
== Release Notes ==
Fedora Workstations ISOs are now built using Image Builder instead of
the legacy tooling used before.
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
_______________________________________________
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave@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
Friday, June 23, 2023
[USN-6161-2] .NET regression
==========================================================================
Ubuntu Security Notice USN-6161-2
June 23, 2023
dotnet6, dotnet7 regression
==========================================================================
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 23.04
- Ubuntu 22.10
- Ubuntu 22.04 LTS
Summary:
USN 6161-1 introduced a regression in .NET that could incorrectly
cause X.509 certificate imports to fail when they should succeed.
Software Description:
- dotnet6: dotNET CLI tools and runtime
- dotnet7: dotNET CLI tools and runtime
Details:
USN-6161-1 fixed vulnerabilities in .NET. The update introduced
a regression with regards to how the runtime imported X.509
certificates. This update fixes the problem.
We apologize for the inconvenience.
Original advisory details:
It was discovered that .NET did not properly enforce certain
restrictions when deserializing a DataSet or DataTable from
XML. An attacker could possibly use this issue to elevate their
privileges. (CVE-2023-24936)
Kevin Jones discovered that .NET did not properly handle the
AIA fetching process for X.509 client certificates. An attacker
could possibly use this issue to cause a denial of service.
(CVE-2023-29331)
Kalle Niemitalo discovered that the .NET package manager,
NuGet, was susceptible to a potential race condition. An
attacker could possibly use this issue to perform remote
code execution. (CVE-2023-29337)
Tom Deseyn discovered that .NET did not properly process certain
arguments when extracting the contents of a tar file. An attacker
could possibly use this issue to elevate their privileges. This
issue only affected the dotnet7 package. (CVE-2023-32032)
It was discovered that .NET did not properly handle memory in
certain circumstances. An attacker could possibly use this issue
to cause a denial of service or perform remote code execution.
(CVE-2023-33128)
Update instructions:
The problem can be corrected by updating your system to the following
package versions:
Ubuntu 23.04:
aspnetcore-runtime-6.0 6.0.118-0ubuntu1~23.04.1
aspnetcore-runtime-7.0 7.0.107-0ubuntu1~23.04.1
dotnet-host 6.0.118-0ubuntu1~23.04.1
dotnet-host-7.0 7.0.107-0ubuntu1~23.04.1
dotnet-hostfxr-6.0 6.0.118-0ubuntu1~23.04.1
dotnet-hostfxr-7.0 7.0.107-0ubuntu1~23.04.1
dotnet-runtime-6.0 6.0.118-0ubuntu1~23.04.1
dotnet-runtime-7.0 7.0.107-0ubuntu1~23.04.1
dotnet-sdk-6.0 6.0.118-0ubuntu1~23.04.1
dotnet-sdk-7.0 7.0.107-0ubuntu1~23.04.1
dotnet6 6.0.118-0ubuntu1~23.04.1
dotnet7 7.0.107-0ubuntu1~23.04.1
Ubuntu 22.10:
aspnetcore-runtime-6.0 6.0.118-0ubuntu1~22.10.1
aspnetcore-runtime-7.0 7.0.107-0ubuntu1~22.10.1
dotnet-host 6.0.118-0ubuntu1~22.10.1
dotnet-host-7.0 7.0.107-0ubuntu1~22.10.1
dotnet-hostfxr-6.0 6.0.118-0ubuntu1~22.10.1
dotnet-hostfxr-7.0 7.0.107-0ubuntu1~22.10.1
dotnet-runtime-6.0 6.0.118-0ubuntu1~22.10.1
dotnet-runtime-7.0 7.0.107-0ubuntu1~22.10.1
dotnet-sdk-6.0 6.0.118-0ubuntu1~22.10.1
dotnet-sdk-7.0 7.0.107-0ubuntu1~22.10.1
dotnet6 6.0.118-0ubuntu1~22.10.1
dotnet7 7.0.107-0ubuntu1~22.10.1
Ubuntu 22.04 LTS:
aspnetcore-runtime-6.0 6.0.118-0ubuntu1~22.04.1
aspnetcore-runtime-7.0 7.0.107-0ubuntu1~22.04.1
dotnet-host 6.0.118-0ubuntu1~22.04.1
dotnet-host-7.0 7.0.107-0ubuntu1~22.04.1
dotnet-hostfxr-6.0 6.0.118-0ubuntu1~22.04.1
dotnet-hostfxr-7.0 7.0.107-0ubuntu1~22.04.1
dotnet-runtime-6.0 6.0.118-0ubuntu1~22.04.1
dotnet-runtime-7.0 7.0.107-0ubuntu1~22.04.1
dotnet-sdk-6.0 6.0.118-0ubuntu1~22.04.1
dotnet-sdk-7.0 7.0.107-0ubuntu1~22.04.1
dotnet6 6.0.118-0ubuntu1~22.04.1
dotnet7 7.0.107-0ubuntu1~22.04.1
In general, a standard system update will make all the necessary changes.
References:
https://ubuntu.com/security/notices/USN-6161-2
https://ubuntu.com/security/notices/USN-6161-1
https://launchpad.net/bugs/2024893, https://launchpad.net/bugs/2024894
Package Information:
https://launchpad.net/ubuntu/+source/dotnet6/6.0.119-0ubuntu1~23.04.1
https://launchpad.net/ubuntu/+source/dotnet7/7.0.108-0ubuntu1~23.04.1
https://launchpad.net/ubuntu/+source/dotnet6/6.0.119-0ubuntu1~22.10.1
https://launchpad.net/ubuntu/+source/dotnet7/7.0.108-0ubuntu1~22.10.1
https://launchpad.net/ubuntu/+source/dotnet6/6.0.119-0ubuntu1~22.04.1
https://launchpad.net/ubuntu/+source/dotnet7/7.0.108-0ubuntu1~22.04.1
Subscribe to:
Posts (Atom)