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
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
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
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)
On Fri, May 17, 2013 at 13:17:17 +0200, Kalev Lember kalevlember@gmail.com wrote:
- 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.
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@gmail.com wrote:
- 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?
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@gmail.com wrote:
- 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?
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
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
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
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.
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
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.
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
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:
Re-add libpng 1.6 back into rawhide.
There seems to be one package that requires libpng 1.5 pkgconfig file -- gdk-pixbuf2 -- I will rebuild it.
$ repoquery --whatrequires 'pkgconfig(libpng15)'
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.
Give it a few days -- package maintainers need time to fix up any failed builds.
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.
There is likely going to be a F20 mass rebuild at a later time, where all the remaining packages hopefully get rebuilt.
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.
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:
Re-add libpng 1.6 back into rawhide.
There seems to be one package that requires libpng 1.5 pkgconfig file -- gdk-pixbuf2 -- I will rebuild it.
$ repoquery --whatrequires 'pkgconfig(libpng15)'
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.
Give it a few days -- package maintainers need time to fix up any failed builds.
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.
There is likely going to be a F20 mass rebuild at a later time, where all the remaining packages hopefully get rebuilt.
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.
On Fri, May 17, 2013 at 12:17 PM, Kalev Lember kalevlember@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
On 05/22/2013 10:39 AM, Peter Robinson wrote:
On Fri, May 17, 2013 at 12:17 PM, Kalev Lember kalevlember@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.
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 :)
On Wed, 22 May 2013 11:58:16 -0700 Adam Williamson awilliam@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
On Wed, May 22, 2013 at 7:58 PM, Adam Williamson awilliam@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
On 05/23/2013 10:23 AM, Peter Robinson wrote:
On Wed, May 22, 2013 at 7:58 PM, Adam Williamson awilliam@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
On Thu, May 23, 2013 at 15:29:07 +0200, Petr Hracek phracek@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.
On Wed, May 22, 2013 at 09:39:06 +0100, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, May 17, 2013 at 12:17 PM, Kalev Lember kalevlember@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.
On Wed, May 22, 2013 at 4:05 PM, Bruno Wolff III bruno@wolff.to wrote:
On Wed, May 22, 2013 at 09:39:06 +0100, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, May 17, 2013 at 12:17 PM, Kalev Lember kalevlember@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
On Fri, May 17, 2013 at 12:20:03 +0200, Petr Hracek phracek@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.
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@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.