FYI: taglib-sharp update
by Christian Krause
Hi,
In order to update banshee to 1.5.4 it is necessary to update
taglib-sharp as well. According to repoquery 3 packages depend on it:
- cowbell (requires the unversioned package taglib-sharp and works even
after the update)
- banshee (will be updated to a new release anyway)
- beagle (needs to be rebuilt)
Juan, if there are no objections from you side, I'll just do the
necessary rebuild of beagle myself. For F13 I will request a buildroot
override for taglib-sharp and push then taglib-sharp, beagle and banshee
as one update into updates-testing later on.
Best regards,
Christian
14 years, 1 month
NAnt boostrapping
by Christian Krause
Hello Tom,
there is currently some uncertainty about bootstrapping NAnt correctly
and since you've done is a couple of times I thought it would be a good
idea just to ask. ;-)
https://bugzilla.redhat.com/show_bug.cgi?id=562729
If I understood this correctly, it should be done like this:
1. build nant with bootstrap=1, get it tagged into buildroot
2. build log4net, mono-sharpcvslib, get both tagged into buildroot
3. finally build nant with bootstrap=0
4. push all new builds
I'm also unsure whether mono-nunit22 must be built and tagged in step 2
as well.
Please can you shed some light on this process? ;-)
Thank you very much in advance!
Best regards,
Christian
14 years, 1 month
nant broken in F12
by Kalev Lember
Hello,
In F-12 nant is broken and fails to run with the following message:
** (/usr/lib64/NAnt/bin/NAnt.exe:2969): WARNING **: Could not load file
or assembly 'log4net, Version=1.2.10.0, Culture=neutral,
PublicKeyToken=2a6b8347ed52b694' or one of its dependencies.
This is caused by latest log4net update which was signed with a
different .snk file than the previous build. Could anyone be so kind and
do the "bootstrap, rebuild, override buildroots, debootstrap, rebuild"
to get nant working again in F-12?
I would be willing to do it myself, but in that case I need to ask Paul
to accept me as nant's co-maintainer.
Ticket for this:
https://bugzilla.redhat.com/show_bug.cgi?id=562729
Thanks!
--
Kalev
14 years, 1 month
Bug in beagle package (only x86_64)
by Christian Krause
Hi Juan,
I've just went through a couple of the abrt mono bug reports and it
looks like that there is a problem with the x86_64 package of beagle:
When the DocExtractor.exe is executed, it can't find the
libbeagleglue.so library.
The root cause is, that the shared library is just referenced by
DllImport as "libbeagleglue" and so without any further information the
mono runtime tries to search it in the standard search paths like
/usr/lib64 etc.
However, the file really resides in /usr/lib64/beagle/ .
Most other mono-based programs like gtk-sharp2, gsf-sharp, gnome-sharp
etc. solve this by installing the glue libs like libgtksharpglue-2.so
directly into %{_libdir}/
Additionally the *.config file should map the generic library name used
in the source code (e.g. "libbeagleglue" to a versioned! library name
like "libbeagleglue.so.1")
All information can be found in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=558548
I've marked all mono bugs which referred also to DocExtractor.exe in the
x86_64 version of beagle and which also had a similar backtrace as
duplicates.
So right now this bug has 22 people on its CC list.
The following bugs may also be the same, bug I'm not 100% sure.
https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&short_desc=...
Please can you have a look at this problem? Thanks!
Best regards,
Christian
14 years, 1 month