Well… Switching to another window manager doesn't solve the “any 3D/GLX
app would crash” issue…
In my case I would have preferred to use the nouveau driver from the
beginning, except that for ancient cards like the 6150SE it makes the
whole system freeze after only a few minutes…
Finally, I was
FYI, after a kernel upgrade the NVIDIA driver was unusable again. This
time was because of the DKMS mechanism which, for whatever reason I
didn't investigate yet (could it be because of the apt-pinning??),
didn't success to build and install the nvidia_304.ko module for the new
kernel.
If that
Sorry for the typos and long-lines… Can't find a way to edit back my
posts… :-/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1639180
Title:
no login possible after update to nvidia 304.132
To
In my case I have a GeForce 6150SE so I really need this 304.131 and
can't higher version like 340.xx.
For people needing to downgrade, this is one (among others) correct way to do
so with Ubuntu 16.04:
- first create a file named /etc/apt/preferences.d/local-nvidia-quirks
with the following
Since this problem greatly affects usability (no graphic login anymore),
may be it's worth (in the users' point of view) creating a “fake
version” security-upgrade like "304.132-0ubuntu0.16.04.2+really304.131"
to fill the gap while waiting for Nvidia to provide a fix for 304.132,
IMHO.
--
You
** Bug watch added: Debian Bug tracker #840342
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840342
** Also affects: nvidia-graphics-drivers-legacy-304xx (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840342
Importance: Unknown
Status: Unknown
--
You received
A debdiff between the packages shows the difference is mainly a version
upgrade from 304.131 to 304.132.
And it seems a lot of people are experiencing problems with version
304.132, cf
https://devtalk.nvidia.com/search/more/sitecommentsearch/304.132/
A specific thread retained my attention:
FYI, downgrade “solved” the problem for me too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1639180
Title:
no login possible after update to nvidia 304.132
To manage notifications about this bug
Same here with Evince not being able to lauch the browser when you clic
on a link inside a PDF:
apparmor="DENIED" operation="capable"
profile="/usr/bin/evince//sanitized_helper" pid=16137 comm="chromium-
browse" capability=21 capname="sys_admin"
** Also affects: evince (Ubuntu)
Importance:
I confirm the Python scopes are now, after having applied the pygobject
update, working on a Xenial 64-bit system and still working (= no
regression) on a 32-bit one. Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
After having installed 2 identical VM (PXE + preseed), with the only
difference being the architecture (32-bit vs 64-bit), I can now confirm
that the Python scopes are working on a 32-bit install and crashing on a
64-bit install, with exactly the same requests made on both sides
(calc:1+1,
Not sure if this helps but it appears this problem only occurs on a
64-bit system. I did a Xenial 32-bit installation recently and the
Python scopes (I tested calc: and manpages:) worked properly. On a
Xenial 64-bit installation, even with the very last updates (especially
the recent
I forgot to mention: I rely on on the Python scopes infrastructure to
work as expected to endorse the deployment of this Xenial LTS over 400
computers in the NGO I'm working for… Since I love Ubuntu and advocate
for it at work, if you need any more tests, it will be my pleasure to
volunteer!
--
On my side, the error only shows once per session, yes, but… my request
also never works as expected, ever.
I just want to use the unity-scope-calculator as usual — “Dashing” for
calc:1+2 — but it doesn't work, neither the first time nor the next
ones. Is this scope obsolete? Or is it supposed to
For those who wonder (because of the lack of informative comments for
standard _users_...) the fix has been released in upstream version
0.8.8.
Ref. : https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p
=apt-cacher-ng/apt-cacher-
Same problem in Trusty.
** Also affects: preseed (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678694
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Trying a 14.04 netboot today still fails the same way.
I had to do this to allow the installation to continue:
- switch to the 2nd console (alt+f2)
- press enter to get a command prompt
- type these commands:
chroot /target
rm /initrd.img*
dpkg --configure -a # it runs the
Changing my netboot preseed configuration from "d-i pkgsel/upgrade
select full-upgrade" to "d-i pkgsel/upgrade select none" was enough to
get around this problem.
Hopefully the installation process still apply the security updates. It
seems to do it later in time so it's probably why it doesn't
According to the Debian bug #786779, upgrading to v42loopback 0.9.0
should solve this issue as it compile properly with newer Linux kernels
(including 4.0).
** Bug watch added: Debian Bug tracker #786779
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786779
** Also affects: v4l2loopback
FYI, debuild'ing the last Debian package on Trusty solved the problem
for me.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1455791
Title:
v4l2loopback-dkms 0.8.0-1: v4l2loopback kernel module
I confirm on my side that the gsetting suggestion from Ted Gould
(comment #8) is working for a user with his homedir over NFS. I have now
put it in my default Ubuntu deployment strategy.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi,
Thanks mainly to Jonathan and jhorak work, I've come to find an easy
solution to manage this problem without patching/recompiling anything.
We just need to intercept the gconf_client_get_string call using
LD_PRELOAD to make it answer nicely on a search containing a '+' symbol.
You will find
FYI, on my side I ensure the interface stays awaken (and not up, it
can not stay up, in the Unix meaning of this term, once the system has
shut down) by putting these two lines in /etc/default/halt :
NETDOWN=no # to not shutdown the interfaces
ethtool -s eth0 wol g # to activate the wake-on-lan
Thanks Alexander!
I've investigated your patches and find them very interesting, clearly
based on the same model of portmap/portmap-wait.
Still, I was looking for the less intrusive possible modification in the
time being (while this bug is being investigated thoughtfully, I hope,
by Canonical
Hi guys!
First thanks for your analysis
I'm in the process to let deploy more than 400 computers using the
current LTS with NFSv4 (and autofs here too) and I'm stuck at randomly
facing exactly the same problem of idmapd failing to start, here because
of the late rpc_pipefs start:
Feb 28
@pavolzetor This traceback is _not_ related to the indicator applet
support problem.
It's about a wrong number of columns in an SQL instruction while writing
in the log database.
I suppose that may be because of a log database structure change and a
problem with database migration (or no
Does my proposed solution (moving away pstopdf.convs) works in your
case?
BTW, how are you converting your PPT into PDF? Doesn't OpenOffice have a
direct PDF rendering function (totally independent from CUPS) which
could be used for that?
--
loosing %Title info = cups-pdf save as _stdin_
It appears _there actually is_ some wrong/bad consequences when
activating capslock, especially when going in/out the rdesktop window.
It then sometimes makes the capslock modifier apparently stuck
(permanently active) in the GNOME environment which alter a lot of
keyboard and mouse actions.
It's
Thanks for the directions. Starting to learn how to use debdiff...
--
rdesktop works bad with several keyboard layouts
https://bugs.launchpad.net/bugs/251709
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
** This bug has been marked a duplicate of bug 251709
rdesktop works bad with several keyboard layouts
** This bug is no longer a duplicate of bug 251709
rdesktop works bad with several keyboard layouts
--
rdesktop shift / caps lock problem with keymap fr (and others?)
*** This bug is a duplicate of bug 251709 ***
https://bugs.launchpad.net/bugs/251709
@Daniel, yes it's a workaround, but at least it lets CapsLock being
usable again!
The CapsLock synchronization between inside and outside is another
matter, which is not as important as just being able to
This problem is still present in Jaunty and Karmic RC (whatever US or
French keyboard).
I'm going to try Michael's patch above.
--
rdesktop works bad with several keyboard layouts
https://bugs.launchpad.net/bugs/251709
You received this bug notification because you are a member of Ubuntu
Bugs,
Ok.
After some wide investigations (checking raw keyboard scan codes with
showkey, checking Xorg key codes with xev, checking GNOME keyboard
selection, checking/removing SCIM/iBus keyboard alteration in the way, checking
console keyboard choice in /etc/default/console-setup) and after trying
But Karmic is bringing OOo 3.1.1... shouldn't this package be available
at the same version as OOo?
--
hunspell-hu, hunspell-vi and probably others hunspell-* conflict with
thunderbird (unversioned)
https://bugs.launchpad.net/bugs/409813
You received this bug notification because you are a
Anyway, having hunspell-vi (and others hunspell-*) conflicting with any
(unversioned) Thunderbird is really blocking hard against getting
Vietnamese language support in Ubuntu (since we can't spellcheck it in
OpenOffice, Firefox or Thunderbird without this package)...
So, please find a way (and
Same problem with hunspell-vi...
hunspell-fr and hunspell-en-us have correct version'd conflict
dependencies on Thunderbird 2.0.0.1 but not a few others like those we
need here...
--
hunspell-hu conflicts with thunderbird (unversioned)
https://bugs.launchpad.net/bugs/409813
You received this
Arne, I have assigned this bug to you since you were assigned to the bug
#227711 which is exactly the same.
** Changed in: openoffice.org-dictionaries (Ubuntu)
Assignee: (unassigned) = Arne Goetje (arnegoetje)
--
hunspell-hu conflicts with thunderbird (unversioned)
** Summary changed:
- hunspell-hu conflicts with thunderbird (unversioned)
+ hunspell-hu hunspell-vi conflict with thunderbird (unversioned)
--
hunspell-hu hunspell-vi conflict with thunderbird (unversioned)
https://bugs.launchpad.net/bugs/409813
You received this bug notification because you
** Summary changed:
- hunspell-hu hunspell-vi conflict with thunderbird (unversioned)
+ hunspell-hu, hunspell-vi and probably others hunspell-* conflict with
thunderbird (unversioned)
--
hunspell-hu, hunspell-vi and probably others hunspell-* conflict with
thunderbird (unversioned)
I've just tested the use of the current hunspell-vi package (forcing its
installation) in Jaunty and it works perfectly with Thunderbird (and
Firefox too).
--
hunspell-hu, hunspell-vi and probably others hunspell-* conflict with
thunderbird (unversioned)
https://bugs.launchpad.net/bugs/409813
Same test in Hardy (forced hunspell-vi installation) and it works
perfectly with Thunderbird too.
--
hunspell-hu, hunspell-vi and probably others hunspell-* conflict with
thunderbird (unversioned)
https://bugs.launchpad.net/bugs/409813
You received this bug notification because you are a member
Ahem... The previous comment was meant to be about Karmic, not Hardy... :-P
I didn't test in Hardy. It works in Jaunty and Karmic (beta + every updates as
of now).
--
hunspell-hu, hunspell-vi and probably others hunspell-* conflict with
thunderbird (unversioned)
to
report any other bugs you may find.
Ok, it's the usual way, but there is something unusual here...
This is what I get when going on https://bugs.launchpad.net/bugs/441694
:
Not allowed here
Sorry, you don't have permission to access this page.
You are logged in as Jean Christophe André
It has been fixed upstream already, see the bug URL I've just linked.
Could anybody ensure this fix will be integrated for the Karmic final release?
BTW, since this bug was because of an API change in the python-indicate
package, developers ask for a way to get a module version number (from
Public bug reported:
Binary package hint: cups
1) Ubuntu release: Ubuntu 9.04 (Jaunty)
2) Package version: cups 1.3.9-17ubuntu3.2
3) What did I expect: PDF generated from printing through cups-pdf saved using
the document title (from %Title in Postscript) as the file name ; it was
working this
I also think that f-u-s-a is either misnamed or overdoing.
Currently it manages presence, user switching and session ending.
Because of this, it's becoming a very useful applet and people are
interested in using it, of course. Also, it seems to me that it could
become the de-facto standard in the
I would say this check-boxes display problem has been corrected in
poppler 0.10.3, available in Jaunty.
Ref.: https://bugs.freedesktop.org/show_bug.cgi?id=19359#c3
I am using Intrepid and I have just installed poppler 0.10.3 straight
from Jaunty (without even rebuilding since it's a new version
Mhhh... Did I do something wrong when linking to Gnome bug tracking
system? Because first I didn't see the status change from Unknown to
New, and now the bug is solved (fixed) already on Gnome's side but it's
still shown as Unknown here. :-/
--
missing utf-8 input decoding in the Python Console
FYI, there is some Spanish people having already worked on PMB's
(unofficial?) packaging.
See: https://lliurex.net/projects/valencia/lliurex-pool-ng/browser
/ubuntu-wnpp/trunk/pmb
--
[needs-packaging] PMB (PhpMyBibli) - integrated library system (ILS)
https://bugs.launchpad.net/bugs/262609
You
Done and linked to this bug (correctly, I hope).
Thank you for having pointed that. :-)
Anything else to do?
** Bug watch added: GNOME Bug Tracker #558149
http://bugzilla.gnome.org/show_bug.cgi?id=558149
** Also affects: gedit via
http://bugzilla.gnome.org/show_bug.cgi?id=558149
Public bug reported:
Binary package hint: gedit
Some friend found a problem with the Python Console plugin in gedit
2.22.3-0ubuntu1, coming with Ubuntu 8.04(.1).
When inputing some utf-8 encoded text, it's evaluated as a byte string
instead, meaning it's not decoded as it should and as it
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/18224893/Dependencies.txt
** Attachment added: ProcMaps.txt
http://launchpadlibrarian.net/18224894/ProcMaps.txt
** Attachment added: ProcStatus.txt
http://launchpadlibrarian.net/18224895/ProcStatus.txt
** Attachment
Public bug reported:
Binary package hint: python-gtk2-doc
Trying to run pygtk-demo from python-gtk2-doc 2.12.1-0ubuntu1 on
Ubuntu 8.04(.1), I get an error about /usr/bin/python2.4 not found, but
I can get it run using python /usr/bin/pygtk-demo.
Inspecting the /usr/bin/pygtk-demo script, we can
** Description changed:
Binary package hint: python-gtk2-doc
+
+ Note: this bug is not present anymore in Intrepid, but still it might be
+ considered for Hardy since it's a LTS.
Trying to run pygtk-demo from python-gtk2-doc 2.12.1-0ubuntu1 on
Ubuntu 8.04(.1), I get an error about
** Description changed:
Binary package hint: gedit
+
+ Note: this bug is still present in Intrepid beta version.
Some friend found a problem with the Python Console plugin in gedit
2.22.3-0ubuntu1, coming with Ubuntu 8.04(.1).
When inputing some utf-8 encoded text, it's evaluated
I have remastered the Hardy beta LiveCD after having updated this
package and I do confirm we can now see Ho Chi Minh as the default
timezone choice for Vietnam in Ubiquity. So this bug can now be closed.
Many thanks!
--
Where are you? SAIGON should be named Ho Chi Minh City
I have remastered the Hardy beta LiveCD after having installed the scim-
m17n package to test m17n-db bugs corrections and I do confirm that
Telex is now working appropriately (no more backspace or aff bugs) !
So this bug can now be closed. Many thanks!
--
Correction in m17n vi-telex.mim
I have remastered the Hardy beta LiveCD after having updated the gtk+2.0
package and I do confirm that VIQR is not anymore activated by default
for Vietnamese locale!
I have also installed the scim-m17n package to test m17n-db bugs
corrections and I do confirm that Telex is now working
Answer to Sebstien Bacher:
Sorry for current delay in my answers: I'm currently busy working longer than
planed in Hồ Chí Minh City and have no time to do the requested test... Could
somebody else test it please?
But I'm not sure every Vietnamese people subscribed to this bug and
interested
Forgot to answer on one point to Sebastien Bacher:
This change is about disabling Vietnamese typing by default in GTK+,
independently of the distribution, so is suitable for upstream, IMHO.
But, we ask for this to be included in Hardy to help us promote Ubuntu
deployment using a LTS with
FYI...
I've post a closing answer to this thread. Summary here:
1) no more ask for switch to Hanoi in tzdata ;
2) no more ask for Hanoi link in tzdata ;
3) confirmed the necessity to switch from Saigon to Ho_Chi_Minh.
It seems that 3) is being considered by tzdata maintainers, so we'll
probably
FYI...
Following indication from Clint Adams (see Debian's bug link at top of
this page) I'm discussing this at the source:
http://thread.gmane.org/gmane.comp.time.tz/2122
As Martin Pitt already said, people from tzdata have good arguments to
keep going with current rules, which define time zone
I can hardly understand the too long argument when
Asia/Ho_Chi_Minh_City is only 21 characters long but you can find
other time zone specification as long as 30 characters, eg
America/North_Dakota/New_Salem...
Note also that, after tzdata source inspection, I can see multiple
translations of
We could organize intensive testing for Vietnamese, but I'm afraid we
won't be able to test every single language provided by m17n-db... :-/
About the language-support-input-vi metapackage, I do confirm that
adding scim-m17n is enough and does work from Hardy Alpha 6 (I've just
tested it). It was
I do confirm the correction asked for line 234.
There is only one instance of (insert aff) in this file which really should
be corrected to (insert af).
You can find a second confirmation of this here:
http://en.wikipedia.org/wiki/Telex_(IME)
To write a tone marking key as a normal
not really a scim problem, and a fixed has been done for m17n-db to get
a minimal working environment
** Changed in: m17n-db (Ubuntu)
Sourcepackagename: scim = m17n-db
Status: Confirmed = Fix Committed
--
Bad default choices for Vietnamese installation
Version 1.4.0 or later is also required for free typing in Vietnamese
which is what people are used to here in Vietnam.
And about the Debian update: https://bugs.launchpad.net/ubuntu/+source
/m17n-db/+bug/191451/comments/22
** Changed in: m17n-db (Ubuntu)
Status: Invalid = New
--
Please
(not sure about what is the exact meaning of Fix Committed in term of
bug management...)
** Changed in: m17n-db (Ubuntu)
Status: Fix Committed = In Progress
--
Bad default choices for Vietnamese installation
https://bugs.launchpad.net/bugs/191451
You received this bug notification
** Bug watch added: Debian Bug tracker #434043
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434043
** Also affects: m17n-db (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434043
Importance: Unknown
Status: Unknown
--
Please update to 1.5
Thanks Ming Hua for you summary which is absolutely exact.
Your patch seems quite appropriate too, at least for the previous known GTK+
behavior.
Can somebody generate a .deb from this? Else I'll try through my PPA, but I'm
not sure to have time for this today...
--
Bad default choices for
Answer to Sebastien Bacher:
Problem summary:
When choosing some Vietnamese locale like vi_VN, GTK is activating its VIQR
input method automatically (because of im-module hint) which leads to
unexpected typing (for most Vietnamese people, not used to this input method)
and even loss of
[More Hardy Alpha6 Vietnamese support tests]
It seems it's not exactly what I supposed... I see a strange GTK behavior here!
When running a gnome-terminal, the default GTK input method is system and
VIQR is *not* activated.
When running ubiquity, the default GTK input method is also system but
Thanks for this!
About which SCIM method to select, no problem. As soon as all required
Vietnamese input methods are available, it's alright. I also think it's
better to have no default for this for political reasons (classic
North/South conflicts). ;-)
The m17n 1.4.0 is not absolutely required,
Wait is always acceptable if we get what we want right in time! ;-)
Do you think he could do it soon enough to let it in Hardy?
If not, I've attached what is needed to correct the backspace issue.
** Attachment added: Correct Vietnamese Telex backspace issue in m17n-db 1.3.1
I've just tested Hardy Alpha6 and here are my comments about Vietnamese support:
- default keyboard is now US at boot, in Xorg and Ubiquity, thanks to Colin
Watson
- default GTK input method is system which still activate VIQR by default
because of the im-viqr.so im-module hint for vi
About SCIM (and everything else), look at my first comment on February
26, 2008, detailing all requirements.
--
Bad default choices for Vietnamese installation
https://bugs.launchpad.net/bugs/191451
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Ok. I've just check the console-setup package content and now I can see
where it does apply. But yet I'm not sure to understand when the
console-setup debconf options are configured during the installation. Is
it from gfxboot or later from ubiquity?
In fact we face problem as soon as we choose
Ok... Let's precise a few points! ;-)
First of all this bug report really should have been split into two or even
three ones (not sure about the dependence between the first and second one):
- one about the default keyboard choice for Vietnamese in gfxboot, currently VN
but we need US
Oh, and to answer Colin about console-setup (which is about console
mode, isn't it?), in fact there are problems there too but far less
important (IMHO) than in boot and graphic mode. This is because
Vietnamese people are used to type without accents and so can deal with
it if required.
But
I've just discovered this bug report and reading it with interest. :-)
I have a Linuterm, which is also based on the ThinCan DBE61.
I'm trying to let it run LTSP on a Ubuntu Gutsy basis.
Bartman, I've just downloaded and installed your packages.
The Xorg server is able to start without crash or
Oh... We can't attach more than one file at a time??
** Attachment added: Xorg.0.log
http://launchpadlibrarian.net/11120605/Xorg.0.log_20080103_0026.txt.bz2
--
amd driver fails to autoconfigure
https://bugs.launchpad.net/bugs/140051
You received this bug notification because you are a member
** Attachment added: xwininfo
http://launchpadlibrarian.net/11120631/xwininfo-root_20080103_0026.txt
--
amd driver fails to autoconfigure
https://bugs.launchpad.net/bugs/140051
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
Great!
I'm able to use Xorg at 1280x1024x16 without any trouble! :-)
I just had to tune a few things manually, like:
- HorizSync VertRefresh to allow full screen size
- DefaultDepth to get 16 bits depth
- Modes in SubSection Display to get the size I wanted
But we should be able to get most of
It's an interesting idea...
We may simply spread the word (along with the CD) to first press F2 to
select the language at boot, or... we may totaly change the first image
displayed at boot!
Something like: every available languages displayed in the first frame
in their own writing (like if we
*** This bug is a duplicate of bug 57153 ***
** Description changed:
Binary package hint: xserver-xorg-core
My video card was running correctly until version 1:1.0.2-0ubuntu10.1
- but is not anymore detected since the today upgrade to version
- 1:1.0.2-0ubuntu10.3. Downgrading to
*** This bug is a duplicate of bug 57153 ***
Sorry for this duplicate... I should just have checked before creating this
ticket...
Anyway, version 1:1.0.2-0ubuntu10.4 (without PCI patch, downloaded from
Rodrigo's link) is working just fine.
--
video card no detected anymore
May be the shortest way to manage this problem is to extract the file
saving part from the whole process to a save file helper, then make
only this being setuid root and well secured by going setuid to the
final user as soon as it starts. Just my 2¢...
--
PDF Printer does no not show up in
87 matches
Mail list logo
