[Bug 754622] Re: GLib-GObject-CRITICAL **: g_value_get_object: assertion `G_VALUE_HOLDS_OBJECT (value)' failed

2012-07-24 Thread David Benjamin
Still happens on 11.10. If you use G_DEBUG=fatal-criticals and catch the
error with gdb, this bug comes from dbusmenu.

** Also affects: libdbusmenu (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to eog in Ubuntu.
https://bugs.launchpad.net/bugs/754622

Title:
  GLib-GObject-CRITICAL **: g_value_get_object: assertion
  `G_VALUE_HOLDS_OBJECT (value)' failed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/754622/+subscriptions

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 329410] Re: does not set configured resolutions at GNOME startup any more

2011-06-11 Thread David Benjamin
Someone want to verify if this patch is at all still needed? The linked
upstream bug has been closed obsolete, so it should probably be dropped.

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gnome-settings-daemon in Ubuntu.
https://bugs.launchpad.net/bugs/329410

Title:
  does not set configured resolutions at GNOME startup any more

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-control-center/+bug/329410/+subscriptions

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 491483] Re: Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is used. (low graphics mode error)

2009-12-10 Thread David Benjamin
I am aware of this; I know the details of this problem, having
discovered it independently in the days I spent figuring out why Ubuntu
failed to boot on my laptop into either X or single-user mode.

If kdm was used, then this bug also occurred in single-user mode because
the configuration check occurs before the single-user check and returned
a non-zero exit status. The failsafe-x init script lacks a sanity check
to not run when booting into single-user mode, like kdm and gdm do have.
While it is true that this bug cannot currently be triggered, this
package is *failsafe* X. If care cannot be taken to make sure it doesn't
kill the system due to driver problems, extreme care should at least be
taken to ensure it does not break existing, more fail-proof, failsafe
methods.

If the gdm script ever accidentally returns a non-zero exit status from
a future change for whatever reason, this bug will happen again and we
will attempt to launch failsafe-x on single-user mode. This is
especially unfortunate; presumably if I'm booting into recovery mode, it
means that failsafe X already failed and launching it again only risks
further disabling the user's machine. It would be good engineering to,
for instance, add a check in failsafe-x's script. If not by listening
for the starting-dm event, at least do the same /proc/cmdline check that
gdm does.

Perhaps change the start on rule to

start on (stopped gdm EXIT_STATUS=[!0] and starting-dm)

But I don't know upstart particularly well, and I cannot test this on my
machine; any attempt to bring up failsafe X results in killing it.

-- 
Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is 
used. (low graphics mode error)
https://bugs.launchpad.net/bugs/491483
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gdm in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 491483] Re: Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is used. (low graphics mode error)

2009-12-09 Thread David Benjamin
This bug also affected single-user mode. While it no longer occurs after
the fix, the script for failsafe-x should be disabled when booting with
kernel option single. It is otherwise extremely ironic that this so-
called failsafe-x has the potential to (and in fact did) cause the real
failsafe boot option to fail.

gdm and kdm currently check for this. A similar check should be added.

Likewise, kdm's init config should get the similar patch, to avoid this
problem from occurring in a possible future kdm-based failsafe X to
complement the one that current depends on gdm.

-- 
Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is 
used. (low graphics mode error)
https://bugs.launchpad.net/bugs/491483
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gdm in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 491483] Re: Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is used. (low graphics mode error)

2009-12-09 Thread David Benjamin
Actually, can failsafe-x be set up to never run unless starting-dm has been 
emitted? I see a 
initctl emit starting-dm DM=kdm
and a similar line in gdm.conf. I don't know how upstart works, but presumably 
one can configure it to only consider running if starting-dm has occurred. That 
seems like a more reasonable fix to failsafe X's propensity to start unwanted 
and hang machines.

-- 
Since failsafe-x was enabled in karmic it starts if gdm is disabled and kdm is 
used. (low graphics mode error)
https://bugs.launchpad.net/bugs/491483
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gdm in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 162950] Totem crashes on close in gutsy with X error

2007-11-15 Thread David Benjamin
Public bug reported:

Binary package hint: totem

In Gutsy, totem crashes on close.

Steps to Reproduce:
1. Open totem from a terminal
2. Do anything... or nothing
3. Close totem

Results:
The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 277 error_code 8 request_code 141 minor_code 13)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Running through a debugger doesn't give anything useful, and I see no
additional package to download the stripped debug symbols. (Might be
useful to consider providing such packages if possible. They're useful
for a lot of things.)

My guess is that this is related to the video overlay as Gutsy also
seems to have considerable problems with that. (The contrast setting
gets set to zero, and I have to manually eyeball it to find the correct
setting. Will file a report when I narrow down the exact triggers of the
problem.)

My graphics device is an integrated Intel chip:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 
945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML 
Express Integrated Graphics Controller (rev 03)

I am running an up-to-date Gutsy install that was upgraded from Feisty
with no totem or graphics-related modifications.

This error did not occur in Ubuntu Feisty.

** Affects: totem (Ubuntu)
 Importance: Undecided
 Status: New

-- 
Totem crashes on close in gutsy with X error
https://bugs.launchpad.net/bugs/162950
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug contact for totem in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 156765] Re: GIMP 2.4's new print dialog is disabled

2007-10-25 Thread David Benjamin
Could it then be at least in backports for those of us who'd like a more
functional GIMP and don't want to wait for Hardy?

I could compile it myself, sure, but it'd be nice for it to integrate
nicely into the package manager. And Linux is hardly attractive to the
Windows crowd if they have to compile from source or {update,wait for
the next version of} their distro just to get a feature that's supposed
to be _in the current release_ much less a new version.

I don't understand why most users should have to wait that long. It
shouldn't take much to test the code. There's very little of it, and a
lot is the same as every other app that uses the GtkPrint API. I'd be
several security upgrades that do get pushed have a larger quantity of
untested code. Like Firefox revisions.

And this doesn't even replace any code that may have worked before.
Gutenprint seems to be happy to co-exist with the new plugin, so people
can always just use the old plugin.

What does it take to test the print plugin and have it be deemed worthy
of getting into Gutsy? I'd be happy to help test it if no one else will.


( Perhaps it's worth slightly rethinking the upgrade policy? Several people 
I've suggested Linux to complain that Ubuntu makes it difficult to get new 
versions of some program they like to use. In comparison, in Windows one can 
just go and install the new version. Whereas I couldn't play with the GIMP 2.4 
rc's because the package in Feisty was a bugfix and maintenance version behind. 
Would it be sensible/feasible to have something sort of in between the current 
stable and grabbing the alphas and betas of the next release? A 
repository/release-schedule for those who aren't on systems that must be up 
150% of the time and can handle code that's only been tested for a few weeks as 
opposed to 6 months if it means we can get reasonably up-to-date packages and 
have our packages supported with the upstream bugfixes. )

-- 
GIMP 2.4's new print dialog is disabled
https://bugs.launchpad.net/bugs/156765
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug contact for gimp in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 156765] GIMP 2.4's new print dialog is disabled

2007-10-24 Thread David Benjamin
Public bug reported:

Binary package hint: gimp

GIMP 2.4 now uses GTK+'s print dialog. (See http://gimp.org/release-
notes/gimp-2.4.html ) This is very nice as the gimp-print plugin's
dialog is very confusing and sometimes acts weird with respect to CUPS.

The build in Ubuntu appears to not be compiled with support for the new
print dialog and only prints with gutenprint. I can confirm that the
nicer dialog exists in -rc3 from a build of it I made on my other
machine a while back. I'm pretty sure that build was compiled with
default configure options, but I don't have it recorded anywhere to
confirm. (I couldn't do it in Feisty because the repositories did not
wish to update from GTK+ 2.10.11 to 2.10.13 and GIMP 2.4 depends on the
latter due to bugs in the one shipped in Feisty.)

Anyway, could the package be compiled to include support for the new
dialog? It's a much more convenient and easy to use dialog than the
original messy gutenprint/gimp-print one.

(Incidentally, now that the final stable version of GIMP 2.4 is
released, will Ubuntu Gutsy get an updated package? The changes are just
bugfixes and the Release Candidate on the splash screen looks really
unpolished and unprofessional.)

** Affects: gimp (Ubuntu)
 Importance: Undecided
 Status: New

-- 
GIMP 2.4's new print dialog is disabled
https://bugs.launchpad.net/bugs/156765
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug contact for gimp in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 138338] man page out-of-date

2007-09-08 Thread David Benjamin
Public bug reported:

Binary package hint: file-roller

The man page of file-roller is out of date.

Compare man file-roller to file-roller --help

(The source tarball does not (I think) provide a man page, so I presume
this is an issue with the package.)

** Affects: file-roller (Ubuntu)
 Importance: Undecided
 Status: New

-- 
man page out-of-date
https://bugs.launchpad.net/bugs/138338
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug contact for file-roller in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 117808] Re: totem-mozilla does not replay videos when stopped in the middle

2007-07-01 Thread David Benjamin
I use totem-gstreamer. (I presume this is the default? I do not remember
ever messing with the settings.)

The link to the video is the thumbnail. Sorry for not mentioning it
before.

The problem occurs on every site which links to a video that I can find (which, 
admittedly, isn't all that many), including:
http://www.fsf.org/resources/formats/playogg (The video is the You can then 
test to see that... bit of the VLC-related section)
http://macslow.thepimp.net/?p=110 The problem occurs on both the ogg file and 
the avi.

-- 
totem-mozilla does not replay videos when stopped in the middle
https://bugs.launchpad.net/bugs/117808
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug assignee.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs


[Bug 117808] totem-mozilla does not replay videos when stopped in the middle

2007-05-30 Thread David Benjamin
Public bug reported:

Binary package hint: totem-mozilla

The totem-mozilla plugin seems to have difficulties playing a video if
you stop its downloading in a middle and then reopen the video.

Steps to Reproduce:
- Open Firefox
- Go to 
http://community.linux.com/community/07/05/17/1640207.shtml?tid=41tid=12
- Middle-click the link to the video
- A few seconds in, close the tab
- Middle-click the link again
- Restart Firefox
- Click the link again
- Let the video go to completion (sorry the test case is kinda long)
- Close the tab and re-open the video

Expected Results:
The video plays in all four attempts.

Actual Results:
The video does not play in the second attempt, when one opens a video again 
after closing the tab once.

Reproducible:
I have managed to reproduce this in all tests so far

I am using Ubuntu Feisty Fawn, and have the latest versions of all the
packages available in the repository. To the best of my knowledge, I
have no third-party packages that relate to totem-mozilla installed.

** Affects: totem (Ubuntu)
 Importance: Undecided
 Status: Unconfirmed

-- 
totem-mozilla does not replay videos when stopped in the middle
https://bugs.launchpad.net/bugs/117808
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is a bug contact for totem in ubuntu.

-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs