Package: monogame
Followup-For: Bug #765120
Alright. So, monogame 2.5.1 (from 2012) doesn't build at all against
Monodevelop 5. A new upstream version, Monogame 3.2, doesn't build against the
version of tao-framework in Jessie (also from 2012, project deprecated in
favour of libopentk, for
Ok. I can now reproduce this too, but *only* if Do is set to show on
startup (which I didn't have).
I wonder if this is related to the GMutex unpleasantness recently. I'll
investigate.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe.
Oooh, wow. That's unexpected!
Can you be more specific than ‘freezes’?
ie:
*) Does the mouse pointer still move?
*) Can you VT switch away from X and back?
*) If you VT switch to a terminal, kill gnome-do, and then VT switch
back to X is it unfrozen?
If you can VT switch away, kill Do, and VT
Hm. That looks like a pretty normal startup trace.
My guess would be that Do has grabbed input but not managed to show
itself (does hitting esc unfreeze the desktop?)
I'll give it at try in a GNOME Shell environment to see if I can
reproduce.
--
To UNSUBSCRIBE, email to
Ah, yes.
The old “glib changes mutex semantics” gambit.
I'll prepare an upload and run the pkg-cli-apps sponsoring gauntlet :)
Thanks for the patch! I'll commit this upstream and do a new upload
soon.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
reassign 705906 mono-gac
forcemerge 570181 705906
thanks
This is no longer an fsharp bug. You've encountered bug #570181, which
you can work around by installing mono-runtime (or mono-runtime-common,
in experimental) first.
Clearly it's time to fix that longstanding problem :)
signature.asc
I've got the infrastructure required to make this work correctly in
branches of cli-common-dev and mono.
They should be uploadable in the next week or so.
signature.asc
Description: This is a digitally signed message part
Hm. I wonder why I didn't see this in testing.
I think I see the problem; it looks like I need to fix the packaging
helpers to install some extra F# specific metadata.
signature.asc
Description: This is a digitally signed message part
Yup, that's it. It's failing to find FSharp.Core.sigdata and
FSharp.Core.optdata; if you copy them
to /usr/lib/mono/gac/FSharp.Core/FSharp.Core/4.3.0.0__b03f5f7f11d50a3a/
you should find that fsharpi works. I clearly had those lying around
from a previous dirty install.
I think we'll need to
tags pending
thanks
I don't believe this would affect other applications; colord in Debian
is run as the colord system user, rather than as root.
This is fixed in colord 0.1.15, which should be uploaded soon. Tagging
as such.
signature.asc
Description: This is a digitally signed message
Huh. addgroup is only expected to fail in a couple of ways, none of
which we should be able to hit with that line.
About the only documented way I could see that happening is if you've
already got a non-system group called ‘scanner’. Does that describe
your system?
Can you remove the --quiet
Hm. It looks like this is a problem with the mono.addins plugin manager
rather than specifically a Files Folders plugin issue.
I'll have a look at that code and see where this is falling over. I'll
get back to you if I need more information, or something tested.
Chris
signature.asc
On Sat, 2010-06-12 at 13:59 +0200, Julien Cristau wrote:
Package: mesa
Version: 7.8.1-2
Severity: serious
mesa in experimental ftbfs on kfreebsd and hurd:
https://buildd.debian.org/pkg.cgi?pkg=mesamaint=dist=experimental
gcc -c -I. -I../../../src/gallium/include
14 matches
Mail list logo
