Jonathan,
thanks for the pointers. For some reason the MONO_LOG_* stuff didn't
show me which lib was being loaded, always listed it as ./
libsqlite3.so.0 instead of the real path. However doing a locate i
noticed that i had a copy in /usr/lib and the new one i built was in /
usr/local/lib, s
Hello,
There was a discussion today on IRC about Winforms and Pango, and I
was wondering if this patch ever got committed, and in general what was
the status of using Pango for GDI+
> Sorry for the long delay. I don't have write access to svn, so I'll
> need someone to commit it for me, or
Below is a small patch for xbuild that causes vcproj files to be ignored.
Unless I'm missing out on some huge secret, vcproj files aren't actually
valid msbuild project files anyway, so ignoring them should do no harm (and
will do a lot of good in the case of solutions that contain both csproj and
> 1. If today's assemblies are noarch and tomorrow's are not, why not
> conform to noarch guidelines today and conform to arch dependent
> guidelines when the time comes?
We would not introduce mysterious bugs by lack of communication.
But as a Fedora folk, do whatever you feel is appropriate f
I never liked my idea so if there is a better way, then by all means lets go
with that.
>>>
A better approach would be to remove the requirement that the .so be in the
same directory as the CIL, and instead probe architecture-specific directories
for the AOT'd code, e.g. ${_libdir}/mono/aot/[??
Hi,
>> File not found: /home/paul/Programming/Sudoku/
>>
>> I've not seen that one before - any ideas on the cause or if it's a
>> known problem?
>
> It's a bug in vbnc, I just filed a bug for it (#502971) with a work
> around.
>
> I've also updated vbnc to give the correct source code locat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arne Claassen wrote:
> I'm trying to get phxsoftware's System.Data.SQLite managed-only dll
> working under mono. The readme claims i should just need the binary in
> the same directory and it works for mono. It does work for windows, i
> just dro
Hi,
1. If today's assemblies are noarch and tomorrow's are not, why not
conform to noarch guidelines today and conform to arch dependent
guidelines when the time comes?
2. The problem is broader than Mono's assemblies. My original question
is based on ndesk-dbus. It is a fine managed only impl
Miguel de Icaza wrote:
> Hello,
>
>> The noarch difficulty:
>> * According to the FHS, if CIL files are architecture independent they
>> should live under /usr/share/ instead of under /usr/lib.
>
> Even if today Mono's assemblies are noarch, we have always reserved the
> right to make them arch s
On Tue, 2009-05-12 at 07:36 -0400, Vladimir Giszpenc wrote:
> It really bothers me that Red Hat/Fedora considers CIL packages not to
> be noarch. I would like to propose using the config file to allow
> relocating the aot-ed file to some arch dependent location. The
> problem they have is that th
On Mon, 2009-05-11 at 23:08 -0700, Arne Claassen wrote:
> I'm trying to get phxsoftware's System.Data.SQLite managed-only dll
> working under mono. The readme claims i should just need the binary in
> the same directory and it works for mono. It does work for windows, i
> just drop sqlite3.dl
Hello,
> 1) Casting: which one is correct?
>
> a)
>
> x = ((int)GetPropertyValue ()).ToString ();
>
> b)
>
> x = ((int) GetPropertyValue ()).ToString ();
No strong opinion on the space after the cast.
> 2) Generics: which one is correct?
>
> a)
>
> x = new List ();
>
> b)
>
> x = new List ();
Hello,
> Along the journey so far I've found a handful of bugs in mono that
> I've reported
> and submitted patches to. Nothing odd about that. One "bug" is really
> problematic to me however since I know now that it won't be fixed in
> mono, see
> Bug 502115. In a way I understand your positi
Hello,
> I'm trying to get phxsoftware's System.Data.SQLite managed-only dll
> working under mono. The readme claims i should just need the binary in
> the same directory and it works for mono. It does work for windows, i
> just drop sqlite3.dll in the dir and it works. However, i try the same
> w
Hello,
> The noarch difficulty:
> * According to the FHS, if CIL files are architecture independent they
> should live under /usr/share/ instead of under /usr/lib.
Even if today Mono's assemblies are noarch, we have always reserved
the right to make them arch specific if needed.
Miguel.
__
On Tue, 12 May 2009 05:43:24 -0700
Toshio Kuratomi wrote:
> I'd love for this to be figured out upstream as we presently have to
> patch things that install in /usr/lib to go to %{_libdir} (although
> the prospect of patching things to go to %{_datadir} instead isn't
> anymore appetizing.)
++ On
Vladimir Giszpenc wrote:
> The following was taken from https://fedoraproject.org/wiki/Packaging/Mono
>
> * *
>
> *File Locations***
>
> Mono packages should install assemblies to %{_libdir} rather than
> /usr/lib or %{_datadir}. In most cases the preference is
> for %{_libdir}/PACKAGENAME. We u
The following was taken from
https://fedoraproject.org/wiki/Packaging/Mono
File Locations
Mono packages should install assemblies to %{_libdir} rather than
/usr/lib or %{_datadir}. In most cases the preference is for
%{_libdir}/PACKAGENAME. We use %{_libdir} because we do not consider
mono pac
Hi,
> Hi,
>
> I'm using vbnc (from the mono-2.4 releases).
>
> While trying to compile some code, MD is reporting a vbnc error
>
> File not found: /home/paul/Programming/Sudoku/
>
> I've not seen that one before - any ideas on the cause or if it's a
> known problem?
It's a bug in vbnc, I just
19 matches
Mail list logo
