Re: [HEADS UP] rpm-4.12.90 in rawhide
On 07/25/2015 11:18 AM, Remi Collet wrote:
Le 24/07/2015 15:49, Florian Festi a écrit :
The freshly released rpm-4.12.90 aka rpm-4.13.0-alpha is going to hit
rawhide soon. The two major new features are:
* Boolean (aka rich) dependencies to support more complicated relation
between packages
* File Triggers - run scripts if files get installed in given paths -
possibly to replace most of the regular - per package - scriptlets at
some point in the future.
But for now and for Fedora this update is more about testing and
stabilizing the many smaller changes as far as they have not been ported
back already.
See the draft release notes for details: http://rpm.org/wiki/Releases/4.13.0
It seems we have a regression (thanks Koschei)
See https://kojipkgs.fedoraproject.org/work/tasks/4402/10474402/build.log
In spec (which is quite common, I think)
%doc imagick-3.1.2/{CREDITS,TODO,INSTALL}
During %doc
+ cp -pr imagick-3.1.2/CREDITS imagick-3.1.2/TODO imagick-3.1.2/INSTALL
/builddir/build/BUILDROOT/php-pecl-imagick-3.1.2-3.fc24.i386/usr/share/doc/php-pecl-imagick
+ exit 0
RPM build errors:
error: File not found:
/builddir/build/BUILDROOT/php-pecl-imagick-3.1.2-3.fc24.i386/usr/share/doc/php-pecl-imagick/{CREDITS,TODO,INSTALL}
File not found:
/builddir/build/BUILDROOT/php-pecl-imagick-3.1.2-3.fc24.i386/usr/share/doc/php-pecl-imagick/{CREDITS,TODO,INSTALL}
Do you want me to file a bug ?
Remi
Hi,
there is another change involving %doc. A piece of libdvdread.spec: "
%files
%defattr(-,root,root,-)
%doc AUTHORS COPYING NEWS README
%{_libdir}/libdvdread.so.*
%files devel
%defattr(-,root,root,-)
%doc ChangeLog TODO
...
"
With old rpm, files ChangeLog and TODO were included in both
libdvdread.rpm and libdvdread-devel.rpm. With this new rpm, koji build
fails with: "
Installed (but unpackaged) file(s) found:
/usr/share/doc/libdvdread/ChangeLog
/usr/share/doc/libdvdread/TODO
"
Which behavior is correct? I guess both are wrong. Should bugzillas be
filed?
Have a nice day,
Fero
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libcdio-0.93 license changed to GPLv3+
Hi, libcdio license changed to GPLv3+ in version 0.93. Cdrkit (GPLv2) in Fedora reverted to use old cdda-paranoia instead of libcdio-paranoia. I am not aware of any other legal issues. Dependent packages will need a rebuild after the rebase. Fero -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Non-responsive maintainer: Deji Akingunola (fas: deji)
On 06/26/2014 10:31 PM, Kevin Fenzi wrote: On Wed, 25 Jun 2014 18:19:32 +0200 Sandro Mani wrote: Hi, Given that no-one seems to know how to contact deji, I'd like to request the takeover of scotch. as a fesco member I can ack this. We will be orphaning his packages and you can pick up scotch. kevin Hi. In the past Deji always responded after a few weeks (and maybe some severe threats). Losing his packages would be extremely unlucky. If it comes to orphaning, I will take care of atlas. Fero -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LibRaw: possible license issues
On 11/26/2012 08:29 PM, Chris Adams wrote: Once upon a time, Ralf Corsepius said: Well, dlopen'ed modules/plugins aren't directly linked, i.e. there is only an indirect dependency. AFAICT (IANAL), this is what makes the legal key-difference. IANAL either, but neither is what matters in the legal sense; "derived work" is what matters. Linking is just an indicator (that is not 100%) of a derived work. As for when the linking is done, (static at build, dynamic at load, dynamic during run), that makes zero difference as to whether something is a derived work. Hi. It might be meaningful to ask this question broadly: How can be two programs related and still not violate the "derivative work under copyright law" thing? (law of US/EU/international/any important country) When are they independent and when a new combined work emerges? Two distinct files dynamically linked together violate, yet one Fedora iso file bundling both does not violate - why? As stated before, linking is probably irrelevant. Bits in symbol table originating from the other file are references - references are generally permitted. AFAIK copyright law does not care about functionality. Just text, translation and modification. Please, enlighten me. Frantisek Kluknavsky -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
sox lpc10 license
Hi list, package sox contains bundled lpc10 library. License of lpc10 is unknown to me and unknown to sox upstream. Probably nobody (probably including lpc10 authors) bothered too much about licensing. My questions: - Does anyone know its licensing status or original developers? Andy J. Fingerhut, previously associated with wustl.edu? - Does any package strictly require lpc10 functionality (linear predictive voice coder)? Can I tear it out of sox? repoquery --whatrequires --alldeps sox DVDAuthorWizard anki asterisk-voicemail dvd-slideshow festival-freebsoft-utils freewrl imagination licq mlt mozplugger openshot psi reinteract sox-plugins-freeworld terminatorX xwax - Can the whole issue be ignored? - Does Fedora contain other implementations of lpc10? Thank you very much. Frantisek Kluknavsky -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
cdrkit ported from cdparanoia to libcdio-paranoia
Hi, cdrkit-1.1.11-18 just entered rawhide, patched to use libcdio-paranoia instead of cdparanoia. Most affected subpackages are probably wodim and icedax. Dirsplit, libusal and genisoimage not that much. This change can break popular burning frontends (k3b, brasero, ...) if done poorly. Please test. Thank you very much. Frantisek Kluknavsky -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: slowing down the development schedule for a release.
On 08/21/2013 03:35 PM, Ralf Corsepius wrote: there are no f20 mock configurations on released Fedora releases in place Is fedpkg mock-config problematic? Either vanilla or after editing from baseurl=http://kojipkgs.fedoraproject.org//repos/f20-build/315000/x86_64 to baseurl=http://kojipkgs.fedoraproject.org//repos/f20-build/latest/x86_64 ? Thank you very much. Frantisek Kluknavsky -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: slowing down the development schedule for a release.
On 08/21/2013 04:16 PM, Ralf Corsepius wrote: On 08/21/2013 04:01 PM, Frantisek Kluknavsky wrote: On 08/21/2013 03:35 PM, Ralf Corsepius wrote: there are no f20 mock configurations on released Fedora releases in place Is fedpkg mock-config problematic? No. fedpkg mockbuild for f20 and mock -r fedora-20-XXX are the problem. Ralf Maybe I misunderstand the purpose of "fedpkg mock-config". I mean workflow like: 1. fedpkg switch-branch f20 2. fedpkg mock-config > fedora-20-x86_64.cfg 3. (maybe edit fedora-20-x86_64.cfg ?) 4. sudo mv fedora-20-x86_64.cfg /etc/mock 5. fedpkg mockbuild where steps 2-4 are needed only once after branching. Is fedpkg mockbuild for f20 still problematic after that? I did it today, so now I am sincerely concerned about the trouble I am in (did not notice any). Fero -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Atlas update
Hi list, Atlas currently bundles Lapack. I want to update Atlas to 3.10.1 and unbundle Lapack as well. This will require rebuild of dependent packages and maybe adding explicit dependency on Lapack. Would anyone object to that? If I understand things correctly, Lapack in Fedora uses Atlas and not its own Blas implementation. Frantisek Kluknavsky PS: DSDP MUMPS MUMPS-openmpi Macaulay2 R-RScaLAPACK SuperLU apbs armadillo arpack cp2k cp2k-mpich cp2k-mpich2 cp2k-openmpi cp2k-smp csdp csdp-tools ergo freefem++ freefem++-glx freefem++-mpi ga-mpich2 ga-openmpi grass-libs gretl gsl iml jblas lapack levmar libghemical linbox mpqc ncl numpy ocaml-lacaml octave octave-control octave-odepkg octave-optim pocketsphinx psfex python-cvxopt python-scikit-learn python3-cvxopt python3-numpy python3-scipy qrupdate scilab scipy sextractor sphinxbase sphinxbase-libs sphinxtrain suitesparse wannier90 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Atlas update
On 09/13/2013 03:44 PM, Orion Poplawski wrote: On 09/13/2013 06:26 AM, Susi Lehtola wrote: On Fri, 13 Sep 2013 15:24:28 +0300 Susi Lehtola wrote: On Fri, 13 Sep 2013 14:16:46 +0200 Frantisek Kluknavsky wrote: Atlas currently bundles Lapack. I want to update Atlas to 3.10.1 and unbundle Lapack as well. This will require rebuild of dependent packages and maybe adding explicit dependency on Lapack. I'd think twice about debundling. For instance OpenBLAS actually replaces some LAPACK routines with more efficient implementations, and because of this OpenBLAS also includes a bunch functions from the lapack package. So, please check with ATLAS upstream whether you can safely unbundle LAPACK. Actually, this is stated pretty clearly on the ATLAS page: "At present, it provides C and Fortran77 interfaces to a portably efficient BLAS implementation, as well as a few routines from LAPACK." So, if you remove LAPACK from ATLAS, you'll also prevent compiling LAPACK dependent packages against ATLAS. I think you can do -latlas -llapack. The problem with the current atlas is that it wants the lapack *source* not just the library as the current version did. It would been a bundling exception. Might be okay since lapack doesn't change much, probably not many security concerns. If two packages in two different git repositories use the same source tarball, is there a (semi)autmatic way to keep them in sync or at least notify forcefully? Do I have to remember and watch for Lapack rebases? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
thread count
Another question. It seems that number of threads is still set at build time, adaptive number of threads might come in the future. Fedora right now uses the default - the number of cpu cores of builder machine. Which number is appropriate? Is it meaningful to ship such a parallel library at all? Which packages use/plan to use parallel version of Atlas? Fero -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[HEADSUP] Atlas changed libraries
Hi, Atlas in rawhide is rebased to 3.10.1. It now builds monolithic shared libraries libsatlas.so and libtatlas.so (serial and threaded, otherwise identical) which include former lapack, blas and atlas libraries. Dependent packages need to link -lsatlas or -ltatlas instead of -latlas -lcblas -llapack. I am sorry, have a nice day and happy rebuilding. Frantisek Kluknavsky PS: DSDP MUMPS MUMPS-openmpi Macaulay2 R-RScaLAPACK SuperLU apbs armadillo arpack cp2k cp2k-mpich cp2k-mpich2 cp2k-openmpi cp2k-smp csdp csdp-tools ergo freefem++ freefem++-glx freefem++-mpi ga-mpich2 ga-openmpi grass-libs gretl gsl iml jblas lapack levmar libghemical linbox mpqc ncl numpy ocaml-lacaml octave octave-control octave-odepkg octave-optim pocketsphinx psfex python-cvxopt python-scikit-learn python3-cvxopt python3-numpy python3-scipy qrupdate scilab scipy sextractor sphinxbase sphinxbase-libs sphinxtrain suitesparse wannier90 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/23/2013 02:46 PM, Susi Lehtola wrote: Well, it's not too hard to understand why ATLAS does things the way it does. It's already in the acronym: Automatically Tuned Linear Algebra Software. You generate a library that is optimal for your processor. In comparison, GotoBLAS (OpenBLAS) has been hand-tuned in assembly for every supported CPU. On the other hand, I'm not sure why they don't just take their tool and pregenerate lists of optimal parameters for every available CPU. That way you could compile everything in the same package and do runtime CPU detection. Currently binary distributions have to do some hackaround to generate a reasonably efficient one-size-fits-all library. Atlas has hand-tuned assembler kernels as well. Build-time tuning searches mainly for optimal block size to minimize cache misses. How does OpenBlas handle blocking? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/22/2013 05:33 AM, Orion Poplawski wrote: Any guidelines or suggestions as to whether to link to the serial or threaded library? For some not yet known reason, threaded library built in koji does not work (fails at pthread_create). My local mockbuild works without any problem. Use serial for now. In the future: If your app does the parallelization, use serial. In single-process single-threaded apps use parallel Atlas. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/22/2013 09:32 PM, Susi Lehtola wrote: I might mention that OpenBLAS (successor to GotoBLAS) is in Fedora, which is often 2x faster than ATLAS. But, it's only available on ix86 and x86_64. It does have runtime CPU detection, though for the 20-odd CPUs supported. Could you please add more details? I can hardly imagine a situation where properly tuned Atlas is below 50% of maximum possible floating point performance. Packaged Atlas tuned on a completely different machine can of course be slow. The theory goes that if you are into serious high-performance computing, you are willing and able to rebuild a few packages. Plus there is a high chance that you are using some more exotic architecture than those power-hungry x86_64. On the other hand pre-packaged Atlas is probably the second worst alternative for desktop use cases (the worst being canonical Blas). For the record: atlas-3.10.1-1.fc21.armv7hl.rpm is available. I do not have any Arm machine to test except the Fedora builders, any feedback is welcome. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/22/2013 09:27 PM, Richard W.M. Jones wrote: G. Please don't [to ATLAS upstream, not Susi] do this. It breaks all sorts of scenarios, especially virtual machine migration or simply moving hard disks from one physical machine to another. Arrange your code so it chooses the best available routines when the program starts up, and compile every feasible alternative into the binary. Or use kernel vdso/user-helper functions when that is applicable. Rich. Atlas aims for a relatively narrow set of use cases. No virtualization. No migration. Just the best possible performance on one given machine. Virtual machines are notoriously known for varying performance. One can not tune without exact benchmarking. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/23/2013 08:02 PM, Kevin Kofler wrote: Of course, this means that it is a very poor choice for our de-facto default LAPACK/BLAS. (Only the reference implementation is worse. Yet, we build some stuff even against that!) I'd suggest filing a Change to make OpenBLAS the default for F21 (when hopefully the armv7 port will also be usable, so all our primary architectures, even the silly one, will be covered) and working on building everything in the distribution that uses LAPACK and/or BLAS against it. Even if we keep the other BLAS/LAPACK implementations around, the target should be that everything in the distro uses OpenBLAS, similarly to how we made spellchecking use Hunspell throughout the distro (see https://fedoraproject.org/wiki/Releases/FeatureDictionary). (I take it that in this case, the application code should normally not need adjustments, so this should be even easier than FeatureDictionary, and not end in a fiasco such as the failed attempt at standardizing cryptography on NSS.) Kevin Kofler People with interest in secondary architectures might oppose that. Perhabs if we ensure binary compatibility then we can make them freely interchangeable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/25/2013 09:47 PM, Kevin Kofler wrote:
Frantisek Kluknavsky wrote:
People with interest in secondary architectures might oppose that.
Which architectures are the problem? OpenBLAS currently supports:
| 2. Supported Architecture
|
|X86 : Pentium3 Katmai
|Coppermine
| Athlon (not well optimized, though)
| PentiumM Banias, Yonah
| Pentium4 Northwood
|Nocona (Prescott)
| Core 2 Woodcrest
| Core 2 Penryn
| Nehalem-EP Corei{3,5,7}
| Atom
| AMD Opteron
| AMD Barlcelona, Shanghai, Istanbul
| VIA NANO
|
| X86_64: Pentium4 Nocona
| Core 2 Woodcrest
| Core 2 Penryn
| Nehalem
| Atom
| AMD Opteron
| AMD Barlcelona, Shanghai, Istanbul
| VIA NANO
|
| IA64 : Itanium2
|
| Alpha : EV4, EV5, EV6
|
| POWER : POWER4
| PPC970/PPC970FX
| PPC970MP
| CELL (PPU only)
| POWER5
| PPC440 (QCDOC)
| PPC440FP2(BG/L)
| POWERPC G4(PPC7450)
| POWER6
|
| SPARC : SPARC IV
| SPARC VI, VII (Fujitsu chip)
|
| MIPS64/32: Sicortex
| Additional support CPU:
| x86/x86-64:
| * Intel Xeon 56xx (Westmere): Used GotoBLAS2 Nehalem codes.
| * Intel Sandy Bridge: Optimized Level-3 BLAS with AVX on x86-64.
| * Intel Haswell: Optimized Level-3 BLAS with AVX on x86-64 (identical to
| Sandy Bridge).
| * AMD Bobcat: Used GotoBLAS2 Barcelona codes.
| * AMD Bulldozer: x86-64 S/DGEMM AVX kernels. (Thank Werner Saar)
| * AMD PILEDRIVER: Used Bulldozer codes.
| MIPS64:
| * ICT Loongson 3A: Optimized Level-3 BLAS and the part of Level-1,2.
| * ICT Loongson 3B: Experimental
(and as I said, ARM is being worked on as we speak, so it's not listed yet,
but will be very soon).
Perhabs if we ensure binary compatibility then we can make them freely
interchangeable.
I also like the binary compatibility approach (used for ATLAS in the past:
you build against reference BLAS/LAPACK and then get whatever one you want
pulled in at runtime), but Susi Lehtola wrote that it is not supported (or
for ATLAS, not anymore) by upstream.
Kevin Kofler
https://fedoraproject.org/wiki/Architectures says PowerPC and s390x.
S390x is unsupported according to this list. Our PowerPCs are Power7 if
I remember correctly. Is that a problem? Does OpenBlas recognize Power7?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/26/2013 05:33 AM, Kevin Kofler wrote: Susi Lehtola wrote: OpenBLAS, ATLAS, ACML and MKL only ship one monolitchic library, so this is not really an option. FYI, the author of netlib-java filed an issue with OpenBLAS for that: https://github.com/xianyi/OpenBLAS/issues/296 Unfortunately, upstream is reluctant to change this because they're worried about people trying to mix their LAPACK with another BLAS which doesn't provide the symbols their optimized LAPACK needs. There ought to be a better solution for that problem. Do you know why ATLAS changed to monolithic libraries? For the same reason? Kevin Kofler https://sourceforge.net/p/math-atlas/mailman/message/28515215/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
On 09/26/2013 09:36 AM, Dan Horák wrote: Missing support for s390/s390x is a problem for us (with my red hat on). Is there no fallback implementation? Does is OpenBLAS fail completely when CPU not listed above is found? Because for Power7 and up anything written for Power < 7 will work. Dan Atlas 3.10 has serious problems on s390(x) as well. I did not solve them yet but I believe they are solvable. I would love to get rid of Atlas completely if a less problematic option appears but not at the expense of shrinking the supported set of hardware. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
Hi, Please correct me if I am wrong: Packagers do not have any real possibility to build and test packages on aarch64. Arm-koji is 32-bit arm. Packagers (some/many) do not even know their packages are supposed to work on aarch64. I decided to believe the bug report and contacted upstream. It was a shame. Aarch64 already supported (and yes, newest upstream tarball in f19). To say it shortly and politely, upstream was not happy to discuss a non-issue with with someone unwilling to even try the feature he requests. Spare me such incidents. Pretty please. How much time passed between discovery and filing of these bugs? Thank you very much. Frantisek Kluknavsky -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On 03/29/2013 11:22 AM, Peter Robinson wrote: What was the package? GMP with configure 2.69 (apparently). Autoreconf -fi in use for a long time. Thank you for the confirmation. What is the right course of action expected from every affected packager? Add autoreconf -vfi and defer contacting upstream until we are competent? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
refactoring alternatives
Hi,
I have a packaging question. Package gnuplot contained binary
/usr/bin/gnuplot-wx. Subpackage gnuplot-qt contained binary
/usr/bin/gnuplot-qt with roughly the same functionality using different
GUI. Now it is time to declare qt default and wxGTK obsolete.
/usr/bin/gnuplot-qt should be in default package gnuplot,
/usr/bin/gnuplot-wx in subpackage gnuplot-wx.
My question is about alternatives. Both packages do something like
http://fedoraproject.org/wiki/Packaging:Alternatives suggests:
%preun
if [ $1 = 0 ]; then
%{_sbindir}/alternatives --remove gnuplot %{_bindir}/gnuplot-wx || :
fi
Now the name of the binary in package 'gnuplot' changes during an
update. But the package is not removed and the %preun scriptlet thinks
that old alternative should be left untouched.
What is the correct way to do this? My best idea so far is to increase
priority of new alternative. Old alternative will remain rotting but a
regular unknowing user will not notice broken symlinks after update.
Thank you very much and have a nice day.
Fero
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22
Hi, a list of things that usually break with each new gcc (like fortran modules) would be nice to avoid a lot of pain with debugging. Does it already exist? WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.4,compatible with 2.6)" and it is checked at runtime. C++ ABI is supposed to be unchanged in Fedora 22. This string changed anyway because __GXX_ABI_VERSION in gcc changed. Is this expected/correct? Each freshly rebuilt wx application will crash now. After wxGTK is rebuilt, each old application will crash. A provenpackager should probably step in. Have a nice day, Fero -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
