5:20 a.m.
Hi folks,
in order that BZ (https://bugzilla.redhat.com/show_bug.cgi?id=963113)
libpng library was bumped.
koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5391511
$> rpm -qpl
/var/lib/mock/fedora-rawhide-x86_64/result/libpng-devel-1.6.2-1.fc20.x86_64.rpm
/usr/bin/libpng-config
/usr/bin/libpng16-config
/usr/include/libpng16
/usr/include/libpng16/png.h
/usr/include/libpng16/pngconf.h
/usr/include/libpng16/pnglibconf.h
/usr/include/png.h
/usr/include/pngconf.h
/usr/include/pnglibconf.h
/usr/lib64/libpng.so
/usr/lib64/libpng16.so
/usr/lib64/pkgconfig/libpng.pc
/usr/lib64/pkgconfig/libpng16.pc
/usr/share/man/man3/libpng.3.gz
/usr/share/man/man3/libpngpf.3.gz
$> rpm -qpl
/var/lib/mock/fedora-rawhide-x86_64/result/libpng-1.6.2-1.fc20.x86_64.rpm
/usr/lib64/libpng16.so.16
/usr/lib64/libpng16.so.16.2.0
/$>
Please rebuild your packages with new libpng library
Here is the list:
$> repoquery --enablerepo fedora-source --alldeps --archlist=src
--whatrequires libpng-devel
0ad-0:0.0.11-3.fc18.src
3Depict-0:0.0.11-1.fc18.src
BlockOutII-0:2.4-3.fc18.src
ClanLib-0:2.3.6-3.fc18.src
ClanLib06-0:0.6.5-24.fc18.src
ClanLib1-0:1.0.0-11.fc18.src
CriticalMass-0:1.5-5.fc18.src
DevIL-0:1.7.8-10.fc18.src
FlightGear-0:2.8.0-1.fc18.src
FlightGear-Atlas-0:0.4.9-0.4.cvs20120911.fc18.src
GREYCstoration-0:2.8-11.fc18.src
GraphicsMagick-0:1.3.17-1.fc18.src
IBSimu-0:1.0.5-4.b.fc18.src
ImageMagick-0:6.7.7.5-3.fc18.src
Io-language-0:20110912-6.fc18.src
LuxRender-0:1.0-2.fc18.src
MagicPoint-0:1.13a-2.fc18.src
OpenImageIO-0:1.0.9-1.fc18.src
OpenSceneGraph-0:3.0.1-13.fc18.src
PerceptualDiff-0:1.1.1-10.fc18.src
Pixie-0:2.2.6-9.fc18.src
R-0:2.15.2-3.fc18.src
SDL_image-0:1.2.12-3.fc18.src
SFML-0:1.6-7.fc18.src
SILLY-0:0.1.0-12.fc18.src
SteGUI-0:0.0.1-21.fc18.src
Thunar-0:1.6.1-1.fc18.src
WindowMaker-0:0.95.3-3.fc18.src
YafaRay-0:0.1.1-6.fc18.src
abiword-1:2.8.6-18.fc18.src
adonthell-0:0.3.5-0.14.fc18.src
aeskulap-0:0.2.2-0.11beta1.fc18.src
alevt-0:1.6.2-20.fc18.src
alienarena-0:7.53-3.fc18.src
allegro-0:4.4.2-4.fc18.src
allegro5-0:5.0.3-5.fc18.src
amanith-0:0.3-22.fc18.src
ambdec-0:0.5.1-3.fc18.src
amoebax-0:0.2.0-10.fc18.src
amsn-0:0.98.9-4.fc18.src
aqsis-0:1.8.2-1.fc18.src
armacycles-ad-0:0.2.8.3.2-3.fc18.src
asc-0:2.4.0.0-8.fc18.src
atari++-0:1.60-4.fc18.src
autotrace-0:0.31.1-31.fc18.src
bandwidthd-0:2.0.1-20.fc18.src
blender-1:2.64a-3.fc18.src
bogl-0:0.1.18-22.fc18.src
bolzplatz2006-0:1.0.3-20.fc18.src
boswars-0:2.6.1-6.fc18.src
bwbar-0:1.2.3-13.fc18.src
cairo-0:1.12.8-2.fc18.src
calibre-0:0.9.8-1.fc18.src
celestia-0:1.6.1-6.fc18.src
cfdg-0:3.0-0.beta2.fc18.2.src
chromium-bsu-0:0.9.15-3.fc18.src
cptutils-0:1.45-2.fc18.src
crossfire-client-0:1.70.0-2.fc18.src
csound-0:5.13.0-9.fc18.src
cups-1:1.5.4-14.fc18.src
cvsgraph-0:1.6.1-11.fc18.src
darktable-0:1.0.5-3.fc18.src
dcmtk-0:3.6.0-12.fc18.src
devilspie-0:0.22-9.fc18.src
dillo-0:3.0.2-3.fc18.src
directfb-0:1.6.2-1.fc18.src
dosbox-0:0.74-7.fc18.src
dvdauthor-0:0.7.1-1.fc18.src
dvdisaster-0:0.72.3-3.fc18.src
ebumeter-0:0.1.0-8.fc18.src
emacs-1:24.2-5.fc18.src
enblend-0:4.0-15.fc18.src
enigma-0:1.01-21.fc18.src
esc-0:1.1.0-18.fc18.src
evas-0:1.2.1-2.fc18.src
extremetuxracer-0:0.4-10.fc18.src
fawkes-0:0.5.0-3.fc18.src
fbdesk-0:1.4.1-12.fc18.src
fbida-0:2.09-2.fc18.src
feh-0:2.3-3.fc18.src
fife-2:0.3.3r3-3.fc18.src
flam3-0:3.0.1-4.fc18.src
fldigi-0:3.21.49-1.fc18.src
fontforge-0:20120731b-2.fc18.src
foobillard-0:3.0a-19.fc18.src
freedroid-0:1.0.2-17.fc18.src
freedroidrpg-0:0.15.1-2.fc18.src
freeimage-0:3.10.0-11.fc18.src
freewrl-0:1.22.13.1-3.fc18.src
fuse-emulator-0:1.0.0.1-5.fc18.src
fvwm-0:2.6.5-3.fc18.src
g2clib-0:1.2.3-5.fc18.src
gambas2-0:2.24.0-3.fc18.src
gambas3-0:3.3.3-1.fc18.src
ganglia-0:3.3.7-5.fc18.src
gavl-0:1.4.0-1.fc18.src
gd-0:2.0.35-18.fc18.src
gdal-0:1.9.1-10.fc18.src
gdk-pixbuf2-0:2.26.5-1.fc18.src
gegl-0:0.2.0-2.fc18.src
gerbv-0:2.6.0-2.fc18.src
ghostscript-0:9.06-3.fc18.src
gif2png-0:2.5.8-1801.fc18.src
gimp-2:2.8.2-6.fc18.src
gipfel-0:0.3.2-15.fc18.src
gl2ps-0:1.3.5-5.fc18.src
glaxium-0:0.5-14.fc18.src
gle-0:4.2.4c-4.fc18.src
glglobe-0:0.2-12.fc18.src
glibc-0:2.16-24.fc18.src
gnash-1:0.8.10-4.fc18.src
gnome-xcf-thumbnailer-0:1.0-9.fc18.src
gnubg-1:0.9.0.1-15.fc18.src
gnuplot-0:4.6.1-1.fc18.src
gnustep-gui-0:0.22.0-2.fc18.src
gource-0:0.38-1.fc18.src
grace-0:5.1.23-1.fc18.src
grads-0:2.0.1-3.fc18.src
graphviz-0:2.28.0-23.fc18.src
grass-0:6.4.2-4.fc18.src
grfcodec-0:6.0.1-1.fc18.src
gstreamer-plugins-good-0:0.10.31-5.fc18.src
gstreamer1-plugins-good-0:1.0.3-1.fc18.src
gtk2-0:2.24.13-1.fc18.src
guile-cairo-0:1.4.0-11.fc18.src
gutenprint-0:5.2.9-2.fc18.src
hatari-0:1.6.2-2.fc18.src
htmldoc-0:1.8.27-20.fc18.src
hugin-0:2012.0.0-1.fc18.src
icc_examin-0:0.51-2.fc18.src
icoutils-0:0.29.1-7.fc18.src
imlib2-0:1.4.5-5.fc18.src
inkscape-0:0.48.4-1.fc18.src
irrlicht-0:1.7.3-4.fc18.src
java-1.7.0-openjdk-1:1.7.0.9-2.3.3.fc18.1.src
jkmeter-0:0.6.1-5.fc18.src
jmeters-0:0.4.1-2.fc18.src
jwm-0:2.1.0-2.fc18.src
kdelibs-6:4.9.4-4.fc18.src
koffice-kivio-3:1.6.3-36.trinity.20100511svn.fc18.src
krusader-0:2.4.0-0.8.beta3.fc18.src
kxstitch-0:0.8.4.1-12.fc18.src
lbrickbuster2-0:2.6.4-2.fc18.src
leptonica-0:1.69-2.fc18.src
libAfterImage-0:1.20-6.fc18.src
libass-0:0.10.1-2.fc18.src
libclaw-0:1.7.0-5.fc17.src
libdmtx-0:0.7.2-8.fc18.src
libgaiagraphics-0:0.4b-2.fc18.src
libgdiplus-0:2.10-6.fc18.src
libglpng-0:1.45-8.fc18.src
libguac-0:0.6.3-2.fc18.src
libharu-0:2.2.1-1.fc18.src
libicns-0:0.8.1-2.fc18.src
libkate-0:0.3.8-6.fc18.src
libmatchbox-0:1.9-10.fc18.src
libpano13-0:2.9.18-4.fc18.src
librasterlite-0:1.1c-2.fc18.src
librsvg2-0:2.36.4-1.fc18.src
libtheora-1:1.1.1-4.fc18.src
libtwin-0:0.0.3-7.fc18.src
libucil-0:0.9.10-6.fc18.src
libwebp-0:0.1.3-2.fc18.src
libwmf-0:0.2.8.4-33.fc18.src
links-1:2.6-2.fc18.src
logstalgia-0:1.0.3-3.fc18.src
luminance-hdr-0:2.3.0-2.fc18.src
m4ri-0:20120415-2.fc18.src
mana-0:0.6.1-5.fc18.src
manaworld-0:0.5.2-9.fc18.src
mapnik-0:2.0.0-7.fc18.src
mapserver-0:6.0.3-6.fc18.src
matchbox-window-manager-0:1.2-10.20070628svn.fc18.src
mathgl-0:1.11.2-7.fc17.src
megaglest-0:3.7.1-1.fc18.src
mhgui-0:0.2-14.fc18.src
minetest-0:0.3.1-11.fc18.src
motif-0:2.3.4-3.fc18.src
mrtg-0:2.17.4-4.fc18.src
mrxvt-0:0.5.3-9.fc18.src
mtpaint-0:3.40-6.fc18.src
naev-0:0.5.3-2.fc18.src
nagios-0:3.4.1-3.fc18.src
nazghul-0:0.7.1-3.20120228gitb0a402a.fc18.src
ncview-0:2.1.1-4.fc18.src
nethack-vultures-0:2.1.2-8.fc18.src
netpbm-0:10.59.02-1.fc18.src
neverball-0:1.5.4-8.fc18.src
ngspice-0:23-3.fc18.src
nitrogen-0:1.5.2-5.fc18.src
nmap-2:6.01-8.fc18.src
nogravity-0:2.00-17.fc18.src
nut-0:2.6.5-6.fc18.src
nx-0:3.5.0-12.fc18.src
ocaml-camlimages-0:4.0.1-6.fc18.src
openalchemist-0:0.4-6.fc18.src
opencv-0:2.4.3-3.fc18.src
openmsx-0:0.9.0-1.fc18.src
openttd-0:1.2.2-1.fc18.src
optipng-0:0.7.4-1.fc18.src
oyranos-0:0.4.0-5.fc18.src
panoglview-0:0.2.2-11.fc18.src
paraview-0:3.14.1-4.fc18.src
pekwm-0:0.1.16-1.fc18.src
perl-Imager-0:0.93-1.fc18.src
perl-SDL-0:2.540-2.fc18.src
perl-Tk-0:804.029-9.fc18.src
petitboot-0:0.2-7.fc17.src
php-0:5.4.9-1.fc18.src
pilot-link-2:0.12.5-13.fc18.src
pinball-0:0.3.1-20.fc18.src
pingus-0:0.7.6-4.fc18.src
plee-the-bear-0:0.6.0-7.fc18.src
plib-0:1.8.5-8.fc18.src
plotutils-0:2.6-5.fc18.src
plymouth-0:0.8.8-5.fc18.src
pngcrush-0:1.7.35-1.fc18.src
pngnq-0:1.1-5.fc18.src
podofo-0:0.9.1-7.fc18.src
polybori-0:0.8.2-3.fc18.src
powermanga-0:0.90-11.fc18.src
pslib-0:0.4.5-3.fc18.src
pstoedit-0:3.61-1.fc18.src
pygame-0:1.9.1-10.fc18.src
pymol-0:1.5.0.2-5.20120218svn3982.fc18.src
python-kaa-imlib2-0:0.2.3-13.fc18.src
python-matplotlib-0:1.2.0-4.fc18.src
qemu-2:1.2.0-23.fc18.src
qrencode-0:3.3.1-4.fc18.src
qt3-0:3.3.8b-43.fc18.src
radius-engine-0:1.1-1.fc18.src
raidem-0:0.3.1-21.fc18.src
rakarrack-0:0.6.1-8.git47245c3.fc18.src
rasterview-0:1.3-5.fc18.src
rawtherapee-0:4.0.9-2.fc18.src
redeclipse-0:1.2-12.fc18.src
rrdtool-0:1.4.7-7.fc18.src
ruby-gnome2-0:0.90.4-1.9.fc18.1.src
scantailor-0:0.9.11.1-1.fc18.src
scribus-0:1.4.1-3.fc18.src
seamonkey-0:2.14-1.fc18.src
sear-0:0.6.4-0.9.g0b70ddb.fc18.src
sim-0:0.9.5-0.28.20091129svn3078rev.fc18.src
skanlite-0:0.8-4.fc18.src
slang-0:2.2.4-5.fc18.src
slashem-0:0.0.8-0.9.E0F1.fc18.src
slim-0:1.3.3-2.fc18.src
sox-0:14.4.0-2.fc18.src
speed-dreams-0:2.1.0-11.trunk_r4810.fc18.src
stage-0:4.1.1-2.fc18.src
stratagus-0:2.2.4-14.fc18.src
synfig-0:0.63.05-2.fc18.src
t4k_common-0:0.1.1-8.fc18.src
tachyon-0:0.99-0.5.b2.fc18.src
teeworlds-0:0.6.1-5.fc18.src
tellico-0:2.3.6-1.fc18.src
texlive-1:2012-8.20121115_r28267.fc18.src
thunar-vfs-0:1.2.0-7.fc18.src
thunderbird-0:17.0-1.fc18.src
thunderbird-enigmail-0:1.4.6-2.fc18.src
thunderbird-lightning-0:1.9-1.fc18.src
tkimg-0:1.4-10.fc18.src
torcs-0:1.3.3-2.fc18.src
tracker-0:0.14.4-1.fc18.src
transfig-1:3.2.5d-8.fc18.src
tucnak2-0:2.31-6.fc18.src
tumbler-0:0.1.26-1.fc18.src
tuxpaint-1:0.9.21-9.fc18.src
tuxpuck-0:0.8.2-14.fc18.src
tvtime-0:1.0.2-22.fc18.src
vavoom-0:1.33-4.fc18.src
vegastrike-0:0.5.1-4.r1.fc18.src
vigra-0:1.8.0-6.fc18.src
vtk-0:5.10.0-3.fc18.src
warmux-0:11.04.1-5.fc18.src
warzone2100-0:3.1-0.10.rc3.fc18.src
webkitgtk3-0:1.10.1-1.fc18.src
wesnoth-0:1.10.5-1.fc18.src
weston-0:1.0.0-1.fc18.src
widelands-0:0-0.33.build17.fc18.src
wine-0:1.5.18-1.fc18.src
wormux-0:0.9.2.1-8.fc18.src
wv-0:1.2.9-5.fc18.src
wxGTK-0:2.8.12-5.fc18.src
xaos-0:3.5-6.fc18.src
xautomation-0:1.07-2.fc18.src
xawtv-0:3.101-4.fc18.src
xcalc-0:1.0.3-8.fc18.src
xcftools-0:1.0.7-6.fc18.src
xemacs-0:21.5.32-1.fc18.src
xfig-0:3.2.5-33.b.fc18.src
xine-ui-0:0.99.7-2.fc18.src
xloadimage-0:4.1-12.fc18.src
xmoto-0:0.5.10-3.fc18.src
xorg-x11-apps-0:7.6-6.fc18.src
xpaint-0:2.9.8.3-4.fc18.src
xsane-0:0.998-12.fc18.src
xteddy-0:2.0.1-9.fc18.src
xtide-0:2.13-2.fc18.src
xu4-0:1.1-0.18.20120106svn2999.fc18.src
xulrunner-0:17.0.1-1.fc18.src
xzgv-0:0.9.1-6.fc18.src
zint-0:2.4.3-4.fc18.src
zita-at1-0:0.2.3-7.fc18.src
zita-rev1-0:0.2.1-6.fc18.src
zvbi-0:0.2.33-14.fc18.src
$>
Thank you in advance
--
Best regards / S pozdravem
Petr Hracek
6:17 a.m.
2013-05-17 12:20, Petr Hracek skrev:
Hi folks,
in order that BZ (https://bugzilla.redhat.com/show_bug.cgi?id=963113)
libpng library was bumped.
[snip]
Please rebuild your packages with new libpng library
Here is the list:
[snip, 306 packages]
Hi Petr,
Very cool to get updated libpng! However please hold your horses with
the new build. Rushing it in without coordination could break rawhide
for a week or longer.
The issue is that once this is in, all the 306 packages above will have
broken dependencies. And it's not just simple rebuilds that are
required; we'd need _ordered_ rebuilds in dependency order: build deps
that require the old libpng can't be installed in the koji build roots
without rebuilding them first. And this means individual package
maintainers can't fix their packages before someone has fixed things
down in the dep chain.
Please do one (or even better, both!) of the two things:
1) Find a provenpackager / releng member to work on rebuilding all the
packages quickly (in dep order)
2) Introduce a libpng15 compat package with the old soname, to satisfy
deps while the packages are being rebuilt. You'd need something
similar to:
https://bugzilla.redhat.com/show_bug.cgi?id=845110
"Review Request: libpng12 - backwards compatibility for libpng"
If you have already built the new libpng, I would strongly suggest to
retract the build for now until the issues above are figured out with:
$ koji untag-pkg f20 libpng-1.6.2-1.fc20
Hope this helps,
Kalev
6:38 a.m.
2013-05-17 13:17, Kalev Lember skrev:
The issue is that once this is in, all the 306 packages above will
have
broken dependencies. And it's not just simple rebuilds that are
required; we'd need _ordered_ rebuilds in dependency order: build deps
that require the old libpng can't be installed in the koji build roots
without rebuilding them first. And this means individual package
maintainers can't fix their packages before someone has fixed things
down in the dep chain.
... and these breakages have started showing up. For instance,
mapnik-2.0.0-14.fc20 build has failed with:
DEBUG util.py:264: Error: Package: poppler-0.22.1-3.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: 1:java-1.7.0-openjdk-1.7.0.19-2.3.9.9.fc20.x86_64
(build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-6.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: 1:qt-x11-4.8.4-17.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-6.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
DEBUG util.py:264: Error: Package: cairomm-1.10.0-6.fc19.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: cairo-1.12.14-1.fc19.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: 1:qt-x11-4.8.4-17.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: gdal-java-1.9.2-6.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: 1:java-1.7.0-openjdk-1.7.0.19-2.3.9.9.fc20.x86_64
(build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
DEBUG util.py:264: Error: Package: cairo-1.12.14-1.fc19.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
DEBUG util.py:264: Error: Package: poppler-0.22.1-3.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
http://koji.fedoraproject.org/koji/buildinfo?buildID=419827
--
Kalev
6:50 a.m.
Hello,
I have just created Review request in BZ
https://bugzilla.redhat.com/show_bug.cgi?id=964161
libpng was untagged by koji.
Thank you in advance for help.
Best regards / S pozdravem
Petr Hracek
On 05/17/2013 01:38 PM, Kalev Lember wrote:
2013-05-17 13:17, Kalev Lember skrev:
> The issue is that once this is in, all the 306 packages above will have
> broken dependencies. And it's not just simple rebuilds that are
> required; we'd need _ordered_ rebuilds in dependency order: build deps
> that require the old libpng can't be installed in the koji build roots
> without rebuilding them first. And this means individual package
> maintainers can't fix their packages before someone has fixed things
> down in the dep chain.
... and these breakages have started showing up. For instance,
mapnik-2.0.0-14.fc20 build has failed with:
DEBUG util.py:264: Error: Package: poppler-0.22.1-3.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: 1:java-1.7.0-openjdk-1.7.0.19-2.3.9.9.fc20.x86_64
(build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-6.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: 1:qt-x11-4.8.4-17.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-6.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
DEBUG util.py:264: Error: Package: cairomm-1.10.0-6.fc19.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: cairo-1.12.14-1.fc19.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: 1:qt-x11-4.8.4-17.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: gdal-java-1.9.2-6.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15()(64bit)
DEBUG util.py:264: Error: Package: 1:java-1.7.0-openjdk-1.7.0.19-2.3.9.9.fc20.x86_64
(build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
DEBUG util.py:264: Error: Package: cairo-1.12.14-1.fc19.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
DEBUG util.py:264: Error: Package: poppler-0.22.1-3.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libpng15.so.15(PNG15_0)(64bit)
http://koji.fedoraproject.org/koji/buildinfo?buildID=419827
8:58 a.m.
On Fri, May 17, 2013 at 13:17:17 +0200,
Kalev Lember <kalevlember(a)gmail.com> wrote:
2) Introduce a libpng15 compat package with the old soname, to satisfy
deps while the packages are being rebuilt. You'd need something
similar to:
https://bugzilla.redhat.com/show_bug.cgi?id=845110
"Review Request: libpng12 - backwards compatibility for libpng"
Note for the libpng jumo from 12 to 15, a lot of packages needed minor
changes, not simple rebuilds. So that change took a while to implement.
It sounds like going from 15 to 16 will be a lot less work, and hence
may not take long enough to be worth adding a compatibility package.
2:35 p.m.
On Fri, 2013-05-17 at 08:58 -0500, Bruno Wolff III wrote:
On Fri, May 17, 2013 at 13:17:17 +0200,
Kalev Lember <kalevlember(a)gmail.com> wrote:
>
> 2) Introduce a libpng15 compat package with the old soname, to satisfy
> deps while the packages are being rebuilt. You'd need something
> similar to:
> https://bugzilla.redhat.com/show_bug.cgi?id=845110
> "Review Request: libpng12 - backwards compatibility for libpng"
Note for the libpng jumo from 12 to 15, a lot of packages needed minor
changes, not simple rebuilds. So that change took a while to implement.
It sounds like going from 15 to 16 will be a lot less work, and hence
may not take long enough to be worth adding a compatibility package.
Doesn't this sound like a perfect candidate for the use of a side tag to
do all the rebuilds, then merge the whole lot back into Rawhide when
it's done?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:03 a.m.
Just a one short question.
You are talking about side tag.
Could you please describe me what are you talking about?
It seems like I am a newbie.
Best regards / S pozdravem
Petr Hracek
On 05/17/2013 09:35 PM, Adam Williamson wrote:
On Fri, 2013-05-17 at 08:58 -0500, Bruno Wolff III wrote:
> On Fri, May 17, 2013 at 13:17:17 +0200,
> Kalev Lember <kalevlember(a)gmail.com> wrote:
>> 2) Introduce a libpng15 compat package with the old soname, to satisfy
>> deps while the packages are being rebuilt. You'd need something
>> similar to:
>> https://bugzilla.redhat.com/show_bug.cgi?id=845110
>> "Review Request: libpng12 - backwards compatibility for libpng"
> Note for the libpng jumo from 12 to 15, a lot of packages needed minor
> changes, not simple rebuilds. So that change took a while to implement.
> It sounds like going from 15 to 16 will be a lot less work, and hence
> may not take long enough to be worth adding a compatibility package.
Doesn't this sound like a perfect candidate for the use of a side tag to
do all the rebuilds, then merge the whole lot back into Rawhide when
it's done?
8:43 a.m.
2013-05-20 09:03, Petr Hracek skrev:
Just a one short question.
You are talking about side tag.
Could you please describe me what are you talking about?
It seems like I am a newbie.
Koji organizes builds by labelling them with tags. There's a a tag for
f19, a tag for f19-updates, a tag for f20, and a number of others. These
decide what repository packages from a particular build end up in.
For rawhide, all packages that are built get automatically tagged with
the f20 tag, and this is what causes newly built packages to appear in
the rawhide build roots and in daily rawhide composes.
Earlier you "untagged" your libpng 1.6 build and that was enough to
remove it from the repos.
What Adam means is that it's possible to ask the koji admins to create a
new side tag + a separate build target in koji, so that the libpng 1.6
rebuilds could happen without disturbing the regular rawhide repos.
Such side build targets can be used to handle soname bumps: A library
package with a soname bump is tagged with the side tag and appears in
the side target, then all consumers are rebuilt against the new library
using the side build target, and finally once all is done, the new
builds are tagged back into the main rawhide all together.
In this case however I think it's not necessary to have a side tag. You
are already working on a compatibility libpng15 package [1] and that
removes the need to rebuild everything at once -- with that in place,
builds can happen slowly, over time. The side tag makes sense if you do
_not_ want to provide the compatibility library.
Hope this helps,
Kalev
[1] https://bugzilla.redhat.com/show_bug.cgi?id=964161
2:51 a.m.
Thank you for really deep explanation.
We had discussion how to do that issue
and we will created a side tag for that.
Compatibility package will not be needed and BZ will be closed.
Best regards / S pozdravem
Petr Hracek
On 05/21/2013 03:43 PM, Kalev Lember wrote:
2013-05-20 09:03, Petr Hracek skrev:
> Just a one short question.
>
> You are talking about side tag.
> Could you please describe me what are you talking about?
> It seems like I am a newbie.
Koji organizes builds by labelling them with tags. There's a a tag for
f19, a tag for f19-updates, a tag for f20, and a number of others. These
decide what repository packages from a particular build end up in.
For rawhide, all packages that are built get automatically tagged with
the f20 tag, and this is what causes newly built packages to appear in
the rawhide build roots and in daily rawhide composes.
Earlier you "untagged" your libpng 1.6 build and that was enough to
remove it from the repos.
What Adam means is that it's possible to ask the koji admins to create a
new side tag + a separate build target in koji, so that the libpng 1.6
rebuilds could happen without disturbing the regular rawhide repos.
Such side build targets can be used to handle soname bumps: A library
package with a soname bump is tagged with the side tag and appears in
the side target, then all consumers are rebuilt against the new library
using the side build target, and finally once all is done, the new
builds are tagged back into the main rawhide all together.
In this case however I think it's not necessary to have a side tag. You
are already working on a compatibility libpng15 package [1] and that
removes the need to rebuild everything at once -- with that in place,
builds can happen slowly, over time. The side tag makes sense if you do
_not_ want to provide the compatibility library.
Hope this helps,
Kalev
[1] https://bugzilla.redhat.com/show_bug.cgi?id=964161
3:07 a.m.
On 05/22/2013 09:51 AM, Petr Hracek wrote:
Thank you for really deep explanation.
We had discussion how to do that issue
and we will created a side tag for that.
Compatibility package will not be needed and BZ will be closed.
Best regards / S pozdravem
Petr Hracek
On 05/21/2013 03:43 PM, Kalev Lember wrote:
> 2013-05-20 09:03, Petr Hracek skrev:
>> Just a one short question.
>>
>> You are talking about side tag.
>> Could you please describe me what are you talking about?
>> It seems like I am a newbie.
> Koji organizes builds by labelling them with tags. There's a a tag for
> f19, a tag for f19-updates, a tag for f20, and a number of others. These
> decide what repository packages from a particular build end up in.
>
> For rawhide, all packages that are built get automatically tagged with
> the f20 tag, and this is what causes newly built packages to appear in
> the rawhide build roots and in daily rawhide composes.
>
> Earlier you "untagged" your libpng 1.6 build and that was enough to
> remove it from the repos.
>
> What Adam means is that it's possible to ask the koji admins to create a
> new side tag + a separate build target in koji, so that the libpng 1.6
> rebuilds could happen without disturbing the regular rawhide repos.
>
> Such side build targets can be used to handle soname bumps: A library
> package with a soname bump is tagged with the side tag and appears in
> the side target, then all consumers are rebuilt against the new library
> using the side build target, and finally once all is done, the new
> builds are tagged back into the main rawhide all together.
>
> In this case however I think it's not necessary to have a side tag. You
> are already working on a compatibility libpng15 package [1] and that
> removes the need to rebuild everything at once -- with that in place,
> builds can happen slowly, over time. The side tag makes sense if you do
> _not_ want to provide the compatibility library.
>
> Hope this helps,
> Kalev
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=964161
>
Ok, well.
It seems that libpng15 compatibility package is built in rawhide.
What are the next steps?
Tagged already built libpng(1.6) package?
I do not want to break rawhide completely and
I would like to avoid all mistakes which can be done from my side.
If I understand whole process then I can tagged libpng package again
and create a lot of bugzillas for support libpng1.6, right?
I will make a notes what to do that in the future of course.
--
Best regards / S pozdravem
Petr Hracek
3:31 a.m.
On 05/30/2013 10:07 AM, Petr Hracek wrote:
On 05/22/2013 09:51 AM, Petr Hracek wrote:
> Thank you for really deep explanation.
> We had discussion how to do that issue
> and we will created a side tag for that.
>
> Compatibility package will not be needed and BZ will be closed.
>
> Best regards / S pozdravem
> Petr Hracek
>
> On 05/21/2013 03:43 PM, Kalev Lember wrote:
>> 2013-05-20 09:03, Petr Hracek skrev:
>>> Just a one short question.
>>>
>>> You are talking about side tag.
>>> Could you please describe me what are you talking about?
>>> It seems like I am a newbie.
>> Koji organizes builds by labelling them with tags. There's a a tag for
>> f19, a tag for f19-updates, a tag for f20, and a number of others.
>> These
>> decide what repository packages from a particular build end up in.
>>
>> For rawhide, all packages that are built get automatically tagged with
>> the f20 tag, and this is what causes newly built packages to appear in
>> the rawhide build roots and in daily rawhide composes.
>>
>> Earlier you "untagged" your libpng 1.6 build and that was enough to
>> remove it from the repos.
>>
>> What Adam means is that it's possible to ask the koji admins to
>> create a
>> new side tag + a separate build target in koji, so that the libpng 1.6
>> rebuilds could happen without disturbing the regular rawhide repos.
>>
>> Such side build targets can be used to handle soname bumps: A library
>> package with a soname bump is tagged with the side tag and appears in
>> the side target, then all consumers are rebuilt against the new library
>> using the side build target, and finally once all is done, the new
>> builds are tagged back into the main rawhide all together.
>>
>> In this case however I think it's not necessary to have a side tag. You
>> are already working on a compatibility libpng15 package [1] and that
>> removes the need to rebuild everything at once -- with that in place,
>> builds can happen slowly, over time. The side tag makes sense if you do
>> _not_ want to provide the compatibility library.
>>
>> Hope this helps,
>> Kalev
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=964161
>>
>
Ok, well.
It seems that libpng15 compatibility package is built in rawhide.
What are the next steps?
Tagged already built libpng(1.6) package?
I do not want to break rawhide completely and
I would like to avoid all mistakes which can be done from my side.
If I understand whole process then I can tagged libpng package again
and create a lot of bugzillas for support libpng1.6, right?
I will make a notes what to do that in the future of course.
I have forgot that now I have to find out any proven packager
which can built up most of the packages
with that new library by fedpkg chain-build.
--
Best regards / S pozdravem
Petr Hracek
12:48 p.m.
2013-05-30 10:07, Petr Hracek skrev:
Ok, well.
It seems that libpng15 compatibility package is built in rawhide.
What are the next steps?
Tagged already built libpng(1.6) package?
I do not want to break rawhide completely and
I would like to avoid all mistakes which can be done from my side.
If I understand whole process then I can tagged libpng package again
Yes, I believe it should now be fine to tag the libpng 1.6 build back
into rawhide.
It seems to have been tagged with "trashcan" in the mean time, but if
you tag it with f20 again, koji should be smart enough to figure out
that it's in use again and will stop the garbage collection process for
that build.
http://fedoraproject.org/wiki/Koji/GarbageCollection
and create a lot of bugzillas for support libpng1.6, right?
No, I don't think you should create any bugzilla tickets at this point.
I would advise the following course of action:
1) Re-add libpng 1.6 back into rawhide.
2) There seems to be one package that requires libpng 1.5 pkgconfig
file -- gdk-pixbuf2 -- I will rebuild it.
$ repoquery --whatrequires 'pkgconfig(libpng15)'
3) Find someone (provenpackager / rel-eng) to rebuild all other
libpng15 using packages (repoquery --whatrequires libpng15). This
should be easy in the sense that it shouldn't require any build
ordering -- just fire off 500 rebuilds.
4) Give it a few days -- package maintainers need time to fix up any
failed builds.
5) Do another 'repoquery --whatrequires libpng15' to see what packages
failed to rebuild and haven't been fixed up by that time, and
possibly file bugzilla tickets then, if you want to.
6) There is likely going to be a F20 mass rebuild at a later time,
where all the remaining packages hopefully get rebuilt.
7) Retire the libpng15 package (or keep it alive for F20 and retire in
F21, if it turns out there are still packages needing it).
Hope this helps,
Kalev
6:26 a.m.
On 05/30/2013 07:48 PM, Kalev Lember wrote:
2013-05-30 10:07, Petr Hracek skrev:
> Ok, well.
> It seems that libpng15 compatibility package is built in rawhide.
> What are the next steps?
> Tagged already built libpng(1.6) package?
>
> I do not want to break rawhide completely and
> I would like to avoid all mistakes which can be done from my side.
>
> If I understand whole process then I can tagged libpng package again
Yes, I believe it should now be fine to tag the libpng 1.6 build back
into rawhide.
It seems to have been tagged with "trashcan" in the mean time, but if
you tag it with f20 again, koji should be smart enough to figure out
that it's in use again and will stop the garbage collection process for
that build.
http://fedoraproject.org/wiki/Koji/GarbageCollection
> and create a lot of bugzillas for support libpng1.6, right?
No, I don't think you should create any bugzilla tickets at this point.
I would advise the following course of action:
1) Re-add libpng 1.6 back into rawhide.
2) There seems to be one package that requires libpng 1.5 pkgconfig
file -- gdk-pixbuf2 -- I will rebuild it.
$ repoquery --whatrequires 'pkgconfig(libpng15)'
3) Find someone (provenpackager / rel-eng) to rebuild all other
libpng15 using packages (repoquery --whatrequires libpng15). This
should be easy in the sense that it shouldn't require any build
ordering -- just fire off 500 rebuilds.
4) Give it a few days -- package maintainers need time to fix up any
failed builds.
5) Do another 'repoquery --whatrequires libpng15' to see what packages
failed to rebuild and haven't been fixed up by that time, and
possibly file bugzilla tickets then, if you want to.
6) There is likely going to be a F20 mass rebuild at a later time,
where all the remaining packages hopefully get rebuilt.
7) Retire the libpng15 package (or keep it alive for F20 and retire in
F21, if it turns out there are still packages needing it).
Hope this helps,
Kalev
Hello Kalev,
well on the Monday I will tag libpng 1.6 back again into rawhide.
If possible I will make some rebuilds either with help of some proven
packager or with rel-eng.
I do not want to do that before weekend.
--
Best regards / S pozdravem
Petr Hracek
7:11 a.m.
On 06/13/2013 01:26 PM, Petr Hracek wrote:
On 05/30/2013 07:48 PM, Kalev Lember wrote:
> 2013-05-30 10:07, Petr Hracek skrev:
>> Ok, well.
>> It seems that libpng15 compatibility package is built in rawhide.
>> What are the next steps?
>> Tagged already built libpng(1.6) package?
>>
>> I do not want to break rawhide completely and
>> I would like to avoid all mistakes which can be done from my side.
>>
>> If I understand whole process then I can tagged libpng package again
> Yes, I believe it should now be fine to tag the libpng 1.6 build back
> into rawhide.
>
> It seems to have been tagged with "trashcan" in the mean time, but if
> you tag it with f20 again, koji should be smart enough to figure out
> that it's in use again and will stop the garbage collection process for
> that build.
>
> http://fedoraproject.org/wiki/Koji/GarbageCollection
>
>
>> and create a lot of bugzillas for support libpng1.6, right?
> No, I don't think you should create any bugzilla tickets at this point.
> I would advise the following course of action:
>
> 1) Re-add libpng 1.6 back into rawhide.
>
> 2) There seems to be one package that requires libpng 1.5 pkgconfig
> file -- gdk-pixbuf2 -- I will rebuild it.
>
> $ repoquery --whatrequires 'pkgconfig(libpng15)'
>
> 3) Find someone (provenpackager / rel-eng) to rebuild all other
> libpng15 using packages (repoquery --whatrequires libpng15). This
> should be easy in the sense that it shouldn't require any build
> ordering -- just fire off 500 rebuilds.
>
> 4) Give it a few days -- package maintainers need time to fix up any
> failed builds.
>
> 5) Do another 'repoquery --whatrequires libpng15' to see what packages
> failed to rebuild and haven't been fixed up by that time, and
> possibly file bugzilla tickets then, if you want to.
>
> 6) There is likely going to be a F20 mass rebuild at a later time,
> where all the remaining packages hopefully get rebuilt.
>
> 7) Retire the libpng15 package (or keep it alive for F20 and retire in
> F21, if it turns out there are still packages needing it).
>
>
> Hope this helps,
> Kalev
Hello Kalev,
well on the Monday I will tag libpng 1.6 back again into rawhide.
If possible I will make some rebuilds either with help of some proven
packager or with rel-eng.
I do not want to do that before weekend.
Finally I have tagged libpng (with 1.6 version) again into rawhide.
There is already libpng15 compatibility package.
--
Best regards / S pozdravem
Petr Hracek
3:39 a.m.
On Fri, May 17, 2013 at 12:17 PM, Kalev Lember <kalevlember(a)gmail.com> wrote:
2013-05-17 12:20, Petr Hracek skrev:
> Hi folks,
>
> in order that BZ (https://bugzilla.redhat.com/show_bug.cgi?id=963113)
> libpng library was bumped.
>
[snip]
>
> Please rebuild your packages with new libpng library
> Here is the list:
[snip, 306 packages]
Hi Petr,
Very cool to get updated libpng! However please hold your horses with
the new build. Rushing it in without coordination could break rawhide
for a week or longer.
The issue is that once this is in, all the 306 packages above will have
broken dependencies. And it's not just simple rebuilds that are
required; we'd need _ordered_ rebuilds in dependency order: build deps
that require the old libpng can't be installed in the koji build roots
without rebuilding them first. And this means individual package
maintainers can't fix their packages before someone has fixed things
down in the dep chain.
The way it was done last time on the 1.5 upgrade was to have a
compat-libpng package that had the 1.5 release so that nothing broke
while things were rebuilt and then once the vast majority of the
rebuild happened it was then dropped to avoid this problem.
Peter
4:01 a.m.
On 05/22/2013 10:39 AM, Peter Robinson wrote:
On Fri, May 17, 2013 at 12:17 PM, Kalev Lember
<kalevlember(a)gmail.com> wrote:
> 2013-05-17 12:20, Petr Hracek skrev:
>> Hi folks,
>>
>> in order that BZ (https://bugzilla.redhat.com/show_bug.cgi?id=963113)
>> libpng library was bumped.
>>
> [snip]
>> Please rebuild your packages with new libpng library
>> Here is the list:
> [snip, 306 packages]
>
> Hi Petr,
>
> Very cool to get updated libpng! However please hold your horses with
> the new build. Rushing it in without coordination could break rawhide
> for a week or longer.
>
> The issue is that once this is in, all the 306 packages above will have
> broken dependencies. And it's not just simple rebuilds that are
> required; we'd need _ordered_ rebuilds in dependency order: build deps
> that require the old libpng can't be installed in the koji build roots
> without rebuilding them first. And this means individual package
> maintainers can't fix their packages before someone has fixed things
> down in the dep chain.
The way it was done last time on the 1.5 upgrade was to have a
compat-libpng package that had the 1.5 release so that nothing broke
while things were rebuilt and then once the vast majority of the
rebuild happened it was then dropped to avoid this problem.
Peter
well but when side tag is used then no compatibility package is needed
Rawhide will not be broken in that case.
I think that there are two ways how to handled that issue:
- create side tag and after finishing merge changes into the rawhide
- create a compatibility package in rawhide and when migration will be
done that compatibility package will be dropped.
From my point of view side tag is better to handlling.
--
Best regards / S pozdravem
Petr Hracek
1:58 p.m.
On Wed, 2013-05-22 at 11:01 +0200, Petr Hracek wrote:
>> The issue is that once this is in, all the 306 packages
above will have
>> broken dependencies. And it's not just simple rebuilds that are
>> required; we'd need _ordered_ rebuilds in dependency order: build deps
>> that require the old libpng can't be installed in the koji build roots
>> without rebuilding them first. And this means individual package
>> maintainers can't fix their packages before someone has fixed things
>> down in the dep chain.
> The way it was done last time on the 1.5 upgrade was to have a
> compat-libpng package that had the 1.5 release so that nothing broke
> while things were rebuilt and then once the vast majority of the
> rebuild happened it was then dropped to avoid this problem.
>
> Peter
well but when side tag is used then no compatibility package is needed
Rawhide will not be broken in that case.
I think that there are two ways how to handled that issue:
- create side tag and after finishing merge changes into the rawhide
- create a compatibility package in rawhide and when migration will be
done that compatibility package will be dropped.
From my point of view side tag is better to handlling.
Either works. The drawback of a side tag is that it's slightly more
complex to work with. The drawback of a compat library is the lack of
motivation to complete the migration: there's a danger when you
introduce a compat library that there isn't sufficient motivation for
people to migrate their packages to the new library, because hey,
everything works, right? What's the big rush?
I think we've got into situations in the past where we've had to retire
a compat library before everything was migrated off it, just to force
people to _actually migrate things off it_.
But both approaches work, and both are massively better than just
breaking half of Rawhide :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:28 p.m.
On Wed, 22 May 2013 11:58:16 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
Either works. The drawback of a side tag is that it's slightly
more
complex to work with. The drawback of a compat library is the lack of
motivation to complete the migration: there's a danger when you
introduce a compat library that there isn't sufficient motivation for
people to migrate their packages to the new library, because hey,
everything works, right? What's the big rush?
I think we've got into situations in the past where we've had to
retire a compat library before everything was migrated off it, just
to force people to _actually migrate things off it_.
But both approaches work, and both are massively better than just
breaking half of Rawhide :)
another few drawbacks of side tags:
- Each one we make means it needs to run regular newrepos on it, which
means (since koji only does a few at a time) that newrepos are slower
for everyone.
- If you take too long to do things in the side tag, your builds get
stale and causes problems. Ie, you build foo-1.0-2 in the side tag
against your new library, take a week rebuilding things and finally
you are ready to tag those builds back in, but in the mean time the
maintainer build foo-1.0-3 to fix something. Now you need to rebuild
it again. So, a side tag is a thing you think you can get done pretty
quickly, imho.
kevin
3:23 a.m.
On Wed, May 22, 2013 at 7:58 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2013-05-22 at 11:01 +0200, Petr Hracek wrote:
> >> The issue is that once this is in, all the 306 packages above will have
> >> broken dependencies. And it's not just simple rebuilds that are
> >> required; we'd need _ordered_ rebuilds in dependency order: build deps
> >> that require the old libpng can't be installed in the koji build roots
> >> without rebuilding them first. And this means individual package
> >> maintainers can't fix their packages before someone has fixed things
> >> down in the dep chain.
> > The way it was done last time on the 1.5 upgrade was to have a
> > compat-libpng package that had the 1.5 release so that nothing broke
> > while things were rebuilt and then once the vast majority of the
> > rebuild happened it was then dropped to avoid this problem.
> >
> > Peter
>
> well but when side tag is used then no compatibility package is needed
> Rawhide will not be broken in that case.
> I think that there are two ways how to handled that issue:
> - create side tag and after finishing merge changes into the rawhide
> - create a compatibility package in rawhide and when migration will be
> done that compatibility package will be dropped.
>
> From my point of view side tag is better to handlling.
Either works. The drawback of a side tag is that it's slightly more
complex to work with. The drawback of a compat library is the lack of
motivation to complete the migration: there's a danger when you
introduce a compat library that there isn't sufficient motivation for
people to migrate their packages to the new library, because hey,
everything works, right? What's the big rush?
You still need a compat package with the old API in the side tag as
well as you still need to have the old soname around until at least
all the packages in the core build root can install.
I think we've got into situations in the past where we've had
to retire
a compat library before everything was migrated off it, just to force
people to _actually migrate things off it_.
Yea, ultimately the compat package is there primarily to get all the
core build systems stuff built against the new soname so that things
will work and then there's not much point in keeping it around because
it ultimately allows procrastination.
Peter
8:29 a.m.
On 05/23/2013 10:23 AM, Peter Robinson wrote:
On Wed, May 22, 2013 at 7:58 PM, Adam Williamson
<awilliam(a)redhat.com> wrote:
> On Wed, 2013-05-22 at 11:01 +0200, Petr Hracek wrote:
>
>>>> The issue is that once this is in, all the 306 packages above will have
>>>> broken dependencies. And it's not just simple rebuilds that are
>>>> required; we'd need _ordered_ rebuilds in dependency order: build
deps
>>>> that require the old libpng can't be installed in the koji build
roots
>>>> without rebuilding them first. And this means individual package
>>>> maintainers can't fix their packages before someone has fixed things
>>>> down in the dep chain.
>>> The way it was done last time on the 1.5 upgrade was to have a
>>> compat-libpng package that had the 1.5 release so that nothing broke
>>> while things were rebuilt and then once the vast majority of the
>>> rebuild happened it was then dropped to avoid this problem.
>>>
>>> Peter
>> well but when side tag is used then no compatibility package is needed
>> Rawhide will not be broken in that case.
>> I think that there are two ways how to handled that issue:
>> - create side tag and after finishing merge changes into the rawhide
>> - create a compatibility package in rawhide and when migration will be
>> done that compatibility package will be dropped.
>>
>> From my point of view side tag is better to handlling.
> Either works. The drawback of a side tag is that it's slightly more
> complex to work with. The drawback of a compat library is the lack of
> motivation to complete the migration: there's a danger when you
> introduce a compat library that there isn't sufficient motivation for
> people to migrate their packages to the new library, because hey,
> everything works, right? What's the big rush?
You still need a compat package with the old API in the side tag as
well as you still need to have the old soname around until at least
all the packages in the core build root can install.
That's my
misunderstanding. I thought that in side tag compat package
will not be needed.
All packages will be build up against new libpng package in side tag.
Why compat package will be needed? Is there any reason?
Proven packager will rebuild affected packages against the newest libpng.
It is really not so clear for me.
After merging to the rawhide we will have only the newest libpng package
and all packages will be build up against new libpng.
Another question:
Let's say that in rawhide I will create libpng compat package.
What is the good time to make them deprecated?
> I think we've got into situations in the past where we've had to retire
> a compat library before everything was migrated off it, just to force
> people to _actually migrate things off it_.
Yea, ultimately the compat package is there primarily to get all the
core build systems stuff built against the new soname so that things
will work and then there's not much point in keeping it around because
it ultimately allows procrastination.
Peter
--
Best regards / S pozdravem
Petr Hracek
8:44 a.m.
On Thu, May 23, 2013 at 15:29:07 +0200,
Petr Hracek <phracek(a)redhat.com> wrote:
That's my misunderstanding. I thought that in side tag compat
package
will not be needed.
All packages will be build up against new libpng package in side tag.
Why compat package will be needed? Is there any reason?
I think what Peter is suggesting is that there is no good order to do the
rebuilds in because libpng is needed by the packages used to rebuild
packages. So as soon as the new libpng is being used (with a compat version),
the build root won't be installable, so you won't be able to do any more
builds. With many libraries this wouldn't be the case.
10:05 a.m.
On Wed, May 22, 2013 at 09:39:06 +0100,
Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Fri, May 17, 2013 at 12:17 PM, Kalev Lember
<kalevlember(a)gmail.com> wrote:
The way it was done last time on the 1.5 upgrade was to have a
compat-libpng package that had the 1.5 release so that nothing broke
while things were rebuilt and then once the vast majority of the
rebuild happened it was then dropped to avoid this problem.
The last time a lot of packages needed patches to use 1.5. So it was expected
to take a while to clean up all of the packages that used 1.2. I get the
impression, that this time around simple rebuilds are expected to work
in most cases.
10:56 a.m.
On Wed, May 22, 2013 at 4:05 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Wed, May 22, 2013 at 09:39:06 +0100,
Peter Robinson <pbrobinson(a)gmail.com> wrote:
>
> On Fri, May 17, 2013 at 12:17 PM, Kalev Lember <kalevlember(a)gmail.com>
> wrote:
>
> The way it was done last time on the 1.5 upgrade was to have a
> compat-libpng package that had the 1.5 release so that nothing broke
> while things were rebuilt and then once the vast majority of the
> rebuild happened it was then dropped to avoid this problem.
The last time a lot of packages needed patches to use 1.5. So it was
expected to take a while to clean up all of the packages that used 1.2. I
get the impression, that this time around simple rebuilds are expected to
work in most cases.
The problem is that a lot of the core packages in the build root
depend on libpng so you can't bump the soname without having the
compat one around because you can't rebuild a whole bunch of packages
that need to be installed to rebuild them so you end up in a chicken
and egg senario.... bump libpng soname ...... can't install build
chain to rebuild other packages because a required soname dependency
has disappeared :-)
Peter
8:48 a.m.
On Fri, May 17, 2013 at 12:20:03 +0200,
Petr Hracek <phracek(a)redhat.com> wrote:
Hi folks,
in order that BZ (https://bugzilla.redhat.com/show_bug.cgi?id=963113)
libpng library was bumped.
Was this just in rawhide? Every package you listed looked like it was
in f18. If you ran the list against f18 assuming it would be the same
in rawhide, then that probably isn't a completely accurate list, as stuff
may have been added or removed since then.
Doing this on a Friday without pre-announcing it might not have been the
best timing.
This also affects enough packages, that a side tag might have been a better
way to handle the change.
1:57 a.m.
No the list was taken from Fedora 18 (my desktop).
You are right, that some packages were added / removed and therefore
list is not
completed.
Best regards / S pozdravem
Petr Hracek
On 05/17/2013 03:48 PM, Bruno Wolff III wrote:
On Fri, May 17, 2013 at 12:20:03 +0200,
Petr Hracek <phracek(a)redhat.com> wrote:
> Hi folks,
>
> in order that BZ (https://bugzilla.redhat.com/show_bug.cgi?id=963113)
> libpng library was bumped.
Was this just in rawhide? Every package you listed looked like it was
in f18. If you ran the list against f18 assuming it would be the same
in rawhide, then that probably isn't a completely accurate list, as
stuff may have been added or removed since then.
Doing this on a Friday without pre-announcing it might not have been
the best timing.
This also affects enough packages, that a side tag might have been a
better way to handle the change.
3964
days inactive
3995
days old
24 comments
6 participants
participants (6)
-
Adam Williamson -
Bruno Wolff III -
Kalev Lember -
Kevin Fenzi -
Peter Robinson -
Petr Hracek