Suggest increasing the importance of this bug, considering it has a CVE
assignment? I realize that it's a DoS, which is low on the
"vulnerability" totem pole; but especially with buffer overruns I tend
to suspect that "DoS" is code for "might allow code execution but no
one's bothered to prove
I've supplied a debdiff to address the fix for this CVE, based on
upstream Debian's fix.
** Patch added: "Debdiff, adapted from Debian 1:1.3.1-11"
https://bugs.launchpad.net/ubuntu/+source/libjpeg-turbo/+bug/1385903/+attachment/5009069/+files/libjpeg-turbo.diff
--
You received this bug
I can confirm this issue in Trusty (libnl3 version 3.2.21-1), relative to
Precise (3.2.3-2ubuntu2). I can install the Precise binaries for:
libnl-3-200
libnl-3-dev
libnl-genl-3-200
libnl-genl-3-dev
libnl-route-3-200
libnl-route-3-dev
onto a Trusty system, and the issue goes away.
To
I've confirmed that the issue is fixed in Utopic (3.2.24-2) (I didn't
know whether Utopic-built binaries work directly - I built from the
Utopic source package). Looks like a backport is what's called for.
Obviously, I won't be opening upstream bugs after all, since it's
already been fixed for
I can confirm this issue in Trusty (libnl3 version 3.2.21-1), relative to
Precise (3.2.3-2ubuntu2). I can install the Precise binaries for:
libnl-3-200
libnl-3-dev
libnl-genl-3-200
libnl-genl-3-dev
libnl-route-3-200
libnl-route-3-dev
onto a Trusty system, and the issue goes away.
To
I've confirmed that the issue is fixed in Utopic (3.2.24-2) (I didn't
know whether Utopic-built binaries work directly - I built from the
Utopic source package). Looks like a backport is what's called for.
Obviously, I won't be opening upstream bugs after all, since it's
already been fixed for
No argument of any sort was made in #8, specious or otherwise; only an
observation.
And placing profiley stuff into bashrc slows down the shell (as if
it's not slow enough already!)
Adding things to PATH that you want access to in all your interactive
shells, belongs in the file sourced by
FWIW, the workaround I've been using for some time now is:
if [ \( x$COLORTERM = xgnome-terminal -o x$COLORTERM = xTerminal -o
x$COLORTERM = xxfce4-terminal \) -a x$TERM = xxterm ]
infocmp xterm-256color /dev/null 21; then
TERM=xterm-256color
fi
in my .bashrc or what have you. The
(the line wrapped for the first if line; that needs to be a single
line to work)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/778801
Title:
TERM unconditionally set to xterm, regardless of config
Continues to be a problem under 13.04. Running Xubuntu.
(Looked into using xkb, but oddly while it offers the option I desire,
to set capslock as an extra escape, it does not appear that it offers
the option to set escape as an extra capslock; at least, not that I
found documented in
Public bug reported:
Binary package hint: xfce4-terminal
Xubuntu 11.04 Natty Narwhal
xfce4-terminal 0.4.7-0ubuntu1
libvte9 0.27.90
I wish to enable 256-color support in apps running under xfce4-terminal;
but even though I've set TERM to this value in the config (and verified
it in
Er, vte_pty_set_term isn't callable, since the pty object doesn't exist
before __vte_pty_spawn. The user-callable fn is
vte_terminal_set_emulation.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/778801
** Bug watch added: Xfce Bugzilla #7178
http://bugzilla.xfce.org/show_bug.cgi?id=7178
** Also affects: xfce4-terminal via
http://bugzilla.xfce.org/show_bug.cgi?id=7178
Importance: Unknown
Status: Unknown
** Bug watch added: GNOME Bug Tracker #640940
According to the discussion on the Gnome VTE bug linked, calling
vte_terminal_set_emulation won't work either, unless it happens to be
recognized as a supported emulation mode. xterm-256color isn't, so
this solution wouldn't work.
There doesn't seem to be an obvious, clean way to fix the problem
Added vte, until it's clearer which of xfce4-terminal and vte should fix
this (as I said, though, it looks to me like only vte _can_ fix it,
though upstream seems unwilling).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Note that gnome-terminal isn't effected, since gnome-terminal doesn't
give the user the option to specify the TERM value to begin with. This
is generally a desirable feature to have, though.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I strongly disagree with that idea. Reading from /etc/environment means
that user-specific proxy settings are lost.
Not letting apt receive the environment properly from its parent also
means that you can't set up a temporary environment where all web
fetches ought to go through a proxy, when you
Public bug reported:
Binary package hint: binutils
This is on Lucid, binutils 2.20.1-3ubuntu7.
The problem is that
debian/patches/151_arm_opt_merge_exidx_entries.dpatch gets applied to a
_generated_ file (which is nonetheless part of the dist), and doesn't
cleanly unpatch.
This file is
Attachment of fixed dpatch, for convenience. NOTE: probably still need
to add the correct $(MAKE) -C ... headers line for debian/rules's build-
static-stamp target.
** Attachment added: 151_arm_opt_merge_exidx_entries.dpatch
Bah, never mind; for some reason that patch failed to apply (despite the
fact that I used dpatch-edit-patch to create it). Instead, I just
removed the chunk from the original diff file that was against bfd-
in2.h. Do that instead.
** Patch removed: 151_arm_opt_merge_exidx_entries.dpatch
** Bug watch added: Debian Bug tracker #614714
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614714
** Also affects: bash (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614714
Importance: Unknown
Status: Unknown
** Bug watch added: Debian Bug tracker #614718
Public bug reported:
Binary package hint: bash
This is on Ubuntu 10.10. It very likely still remains in Natty.
I use bash with a prompt that is derived from the current backgrounded
jobs (the script I use to do this is at
http://micah.cowan.name/hg/promptjobs/ - you just source the file and it
This patch fixes the graphical display glitch.
In some instances, it seems that when I type /, it still may not show
up in some circumstances, so that would be a separate and remaining bug
that still needs looking to, but the history search itself consistently
and correctly shows the lines
Er, there's a bug in that diff, in that it can use the same va_list
twice, which isn't defined behavior. That might be why the / still
doesn't show up. I'll fix that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Here's a patch that uses the double-vasnprintf call correctly. / still
doesn't show up in all circumstances, but the code looks right to me,
and does what it's supposed to.
** Patch added: dynamic-msg_buf.diff
The fix is now in place for the Ubuntu Natty, and it looks like upstream
is going to include it for future versions of vte. Nice to finally be
able to use gnome-terminal with screen and tmux without glitchy graphics
:)
Note: at least one person had difficulty reproducing this on their
system
It looks to me like apt-avahi-discover is broken for IPv6, as it tries
to parse out the IP address, and then sets its results to $IP:$PORT.
For IPv6, it should be [$IP]:$PORT. Not sure if my implementation is
the ideal way to detect IPv4 versus IPv6, but here's a diff attempting
to fix this. Try
(Please note: the debdiff above is now out-of-date; but can still be
used, and then just replace the file in debian/patches.)
(There is also now a merge proposal against https://bazaar.launchpad.net
/~ubuntu-desktop/vte/ubuntu/changes, which does use the updated patch.)
--
You received this bug
Minor fix to patch; addresses the same problem in a few cases apparently
not exercised by the automated script.
** Patch added: Revised patch.
https://bugs.launchpad.net/ubuntu/+source/vte/+bug/246701/+attachment/1759318/+files/lp246701_scroll_region_updates.patch
--
You received this bug
Found the source of the problem. The vte_terminal_process_incoming
function from vte.c keeps track of a bounding box of cells to be
invalidated, and uses that to invalidate cells at points such as after
all input has been processed, or when a large enough cursor jump is made
(to avoid letting the
** Patch added: debdiff against Maverick's vte
https://bugs.launchpad.net/ubuntu/+source/vte/+bug/246701/+attachment/1750780/+files/vte_0.26.0-0ubuntu3.debdiff
--
Change Scroll Region and display glitch
https://bugs.launchpad.net/bugs/246701
You received this bug notification because you
The message given in the dpkg terminal log indicates that the problem is
with debconf, in that two processes were apparently trying to access the
same file at the same time; this would normally only happen if two
installs(/configures), or possibly an install and a remove, are taking
place at the
tput setaf is the appropriate check to use, and was already present in
my initial recommendation (via the first comment to this report), and in
fact is what's currently being used (at least in Lucid) in
/etc/skel/.bashrc (if force_color_prompt is set).
There's no way to do an echo/check stdout
Dustin, I'm aware of that. However, if a user gets the message screen
needs to be run setuid, and then sets /usr/bin/screen (which is really
the profiles wrapper) to setuid, and still gets that message, they'll be
confused. I've seen that happen before; I suspect that's what happened
here.
--
Some versions of Ubuntu had a package called screen-profiles that
installed a wrapper around screen; it may be that, that has the suid bit
set. Look for another binary in /usr/bin whose name starts with screen
(screen.real? Can't remember), and suid that one.
Newer Ubuntus have that package as
Again, opiepasswd does _not_ check the user id and act appropriately, so
it should _not_ be made setuid, unless that issue is addressed, as it
would allow any user to modify any other user's keys, AFAICT.
However, to address Thomas's comment: opiepasswd modifies an individual
user's opie keys,
Again, opiepasswd does _not_ check the user id and act appropriately, so
it should _not_ be made setuid, unless that issue is addressed, as it
would allow any user to modify any other user's keys, AFAICT.
However, to address Thomas's comment: opiepasswd modifies an individual
user's opie keys,
David, Wget 1.12 does download links parsed from HTML or CSS. Please
provide the specific example that's causing you problems. Note that the
URL given above in the original example does not work because at the
time of writing, it doesn't actually contain any links to CSS (or
anything else). It
Really? Hm. I've had huge success (finally) with this (now including the
Four by three option). And yes, they'd be much smaller, due to lower
framerate (which you may want to adjust to 30 in some circumstances),
and lower resolution (to one supported by PSP).
I'm running the latest firmware on my
Daniel G. Taylor wrote:
When I was first researching the PSP options I noticed that each
firmware version is a crapshoot about what formats, resolutions and
features are supported. When testing video conversions please always
update to the latest available firmware for your PSP and you'll have
The problem seems to occur only when a non-English locale is being used
(might not be triggered by all locales). I can trigger the abort by
running LC_ALL=pt_BR.utf8 LANGUAGE=pt info (with the Portuguese
language packs installed).
The problem seems to be in command documentation strings like:
I was unable to ever get the presets to work for me. I had to do a lot
of digging to find anything remotely, and I still don't see anything
official, but this page seems to have very helpful advice on resolution
and frame rate: http://www.pqdvd.com/support/psp_settings_video.html.
I tweaked the
** Changed in: gnus (Ubuntu)
Assignee: Micah Cowan (micahcowan) = (unassigned)
--
smtpmail.elc can't work
https://bugs.launchpad.net/bugs/50689
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu
Confirmed. Installed language-pack-pt and set environment to match
reporter's, saw the same problem.
The issue is a translation one... sort of. The wget source that deals
with the progress bar is poorly written (I'm the upstream Wget
maintainer, but didn't write that part), and assumes that the
Same issue on a Compaq CQ60. Only missing the brightness keys, no
others; were working fine in Jaunty. No messages from xev or
acpi_listen.
--
[Karmic] Brightness fn keys lost functionality (multiple laptops)
https://bugs.launchpad.net/bugs/406515
You received this bug notification because you
Public bug reported:
Steps to reproduce:
1. Open a fresh gnome-terminal. There must be lines below the prompt to which
text has never yet been written.
2. Enter the command: $ printf '\033[L'
(the INSERT LINE sequence will be sent to gnome-terminal)
3. gnome-terminal crashes.
My
Because Won't Fix implies that it's a wget bug, but we've decided not
to address it, rather than a real bug with some other
package/infrastructure.
--
The timeout is no longer correct
https://bugs.launchpad.net/bugs/473024
You received this bug notification because you are a member of Ubuntu
Matthieu,
Since you've indicated that this isn't a problem with wget, it's
probably best to leave wget set to Invalid, or assign this to a more
appropriate package (or more likely, mark it as a duplicate of the core
issue's bug report).
You may also want to check behavior if you use
So, in summary, wget _is_ taking the full 5 seconds before timing out,
and the timeouts are caused by slow IPv6 lookups? (If so, one workaround
would be to add -4 to wget's options).
--
The timeout is no longer correct
https://bugs.launchpad.net/bugs/473024
You received this bug notification
Thanks, all.
Dimitrios, Teej, I had thought that Steve's steps were the ones I'd
outlined; but I guess I was a bit too convoluted in my explanation.
Thanks for your patience.
I'm surprised that wget is doing the right thing with respect to ?
versus %3F; I guess I must have fixed it earlier than
Sorry, I missed the query.
Yes, this is still reproducible in 0.12~pre2.dfsg0-1ubuntu1 (Jaunty).
Didn't check -1ubuntu2 (Karmic), but reproducing it is trivial. Simply
providing an html file with frame elements pointing at non-existent
files should produce the problem.
FWIW, the problematic
To be abundantly clear: the problem is just that elinks names the wrong
file as Not a file or directory.
--
Reports wrong URI for No such file or directory.
https://bugs.launchpad.net/bugs/122499
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Teej, I'm afraid you're missing the point: until you ensure that the
links _are_ incorrect (and they must be file:// links), then you're not
testing it. Please break the links, and check the error message. If it
says the origin page is missing, rather than the frame-sourced pages,
then it's still
To be abundantly clear: the problem is just that elinks names the wrong
file as Not a file or directory.
--
Reports wrong URI for No such file or directory.
https://bugs.launchpad.net/bugs/122499
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Sorry, I missed the query.
Yes, this is still reproducible in 0.12~pre2.dfsg0-1ubuntu1 (Jaunty).
Didn't check -1ubuntu2 (Karmic), but reproducing it is trivial. Simply
providing an html file with frame elements pointing at non-existent
files should produce the problem.
FWIW, the problematic
Teej, could you please verify that the fdoxnews.com/index.html contained
links to non-existent files (or malformed links)? ...or just replace the
frame links with ones to obviously invalid files? ...if the html file
shows no problems at all, then it doesn't sound to me like you're
reproducing it
This has been fixed as of Wget 1.12, which isn't yet available in
Ubuntu. I imagine it will be in Ubuntu 10.04 (Lucid).
** Changed in: wget (Ubuntu)
Status: New = Fix Committed
--
wget not downloading stylesheets (CSS) when using -p/--page-requisites
Teej, I'm afraid you're missing the point: until you ensure that the
links _are_ incorrect (and they must be file:// links), then you're not
testing it. Please break the links, and check the error message. If it
says the origin page is missing, rather than the frame-sourced pages,
then it's still
Kamus, I see absolutely nothing in Thomas Dickey's comments that even
remotely hint at a violation of the Code of Conduct, so maybe you could
consider dialing your sensitivity down a bit?
Thomas, I think the (previous) Incomplete status was due to the
question as to whether it was still
The instructions I gave (modify the postinst script and do a dpkg
--configure --pending) should work, until the next time wget itself, or
any package whatsoever with an info page, is updated.
A more long term solution seems pretty obvious: change your path (in
/etc/environment), or move your
Yeah; a reinstall will re-unpack the .deb file, including the
postinstall script. That's why if you edit it, you need to make sure you
start from the configuration step, skipping the unpack.
Obviously, another workaround is to ensure that /usr/sbin/install-info
comes first in the path. This
*** This bug is a duplicate of bug 444917 ***
https://bugs.launchpad.net/bugs/444917
** This bug has been marked a duplicate of bug 444917
package wget 1.11.4-2ubuntu1.1 failed to install/upgrade: subprocess
post-installation script returned error exit status 1
--
package wget
*** This bug is a duplicate of bug 444917 ***
https://bugs.launchpad.net/bugs/444917
** This bug has been marked a duplicate of bug 444917
package wget 1.11.4-2ubuntu1.1 failed to install/upgrade: subprocess
post-installation script returned error exit status 1
--
Setting up
Note: I wouldn't make the debhelper-bug case if it were just that
/usr/local/texlive/2008/bin/i386-linux//install-info was on the path:
that's obviously a departure from the normal settings for
/etc/environment, and possibly is asking for trouble. However, the fact
that it's also on
This issue has been addresssed in the recently-released Wget 1.12. It's
currently in Debian unstable, so I imagine it will be made available in
Lucid Lynx.
** Changed in: wget (Ubuntu)
Status: Triaged = Fix Committed
--
wget does not handle IDN domains
Wget 1.12 released late last month. Will probably appear in Lucid Lynx.
Meantime, it's already in Debian unstable, so you may be able to use the
package from there.
--
wget --quite --background leaves a wget.log file
https://bugs.launchpad.net/bugs/135063
You received this bug notification
Nothing in here indicates a bug in Ubuntu's wget, particularly since the
reporter's OS was FreeBSD.
** Changed in: wget (Ubuntu)
Status: New = Invalid
--
wget https://launchpad.net fails with certificate error
https://bugs.launchpad.net/bugs/74315
You received this bug notification
Upstream Wget 1.12 has fixed this. It's in Debian unstable now, will
probably find it's way to Ubuntu in Lucid Lynx.
** Changed in: wget (Ubuntu)
Status: Confirmed = Fix Committed
--
wget should prefer IPv6 over IPv4
https://bugs.launchpad.net/bugs/274409
You received this bug
This has been fixed in Wget 1.12, which is currently in Debian unstable.
It'll probably find its way to Ubuntu in Lucid Lynx.
** Changed in: wget (Ubuntu)
Status: New = Fix Committed
--
--content-disposition doesn't work with HTTP authentication.
https://bugs.launchpad.net/bugs/299221
Hi Dominik, thanks very much.
Actually, I need you to type:
dpkg -S `which install-info`
not
dpkg -S which install-info
But so far I can say this: the output from your install-info --version
is different from what it ought to be. Jaunty's install-info is dpkg's
(and from the dpkg -S output
Removing Confirmed status from wget, since the bug won't be with the
wget package. Someone might argue that the wget.postinst script should
hard-code the path to install-info, but even making that case, the bug
would be with debhelper, since that's what generated the script. But
let's not open a
** Changed in: wget (Ubuntu)
Status: Incomplete = Confirmed
** Changed in: wget (Ubuntu)
Assignee: Dominik Wujastyk (wujastyk) = (unassigned)
--
package wget 1.11.4-2ubuntu1.1 failed to install/upgrade: subprocess
post-installation script returned error exit status 1
** Also affects: dpkg (Ubuntu)
Importance: Undecided
Status: New
--
package wget 1.11.4-2ubuntu1.1 failed to install/upgrade: subprocess
post-installation script returned error exit status 1
https://bugs.launchpad.net/bugs/444917
You received this bug notification because you are a
Gah, launchpad threw out my comments to the status change.
This is conceivably a problem in dpkg (where install-info comes from),
rather than wget. In fact, since coreutils.postinst has exactly the same
scriptlet, and wget's is will not have changed since 2ubuntu1, I suspect
that's the case.
dpkg-1.14.24ubuntu1 seems not to have the string No dir file specified
in it.
GNU's install-info does. But GNU's install-info isn't installed as
install-info on Jaunty (I believe it is on Karmic, though). You're
certain this is 9.04, and not 9.10? Are you using any non-standard
repositories?
I'm having similar difficulties (not precisely the same, but similar
enough that for now I'll assume it's the same bug).
I'm using Jaunty. My connection is disassociated immediately (I never
see the four bars). It works fine in 2.6.28-14 (I'm using it right this
moment), and must have been
Strange, I didn't encounter any problems.
The postinstall script is quite short, and straightforward; also I don't
think it has changed since 1.11.4-2ubuntu1 (no .1). It just invokes
install-info.
Please verify that the script is continuing to have problems, by first
running sudo dpkg
In your version of Ubuntu, /usr/bin/screen actually belongs to a package
called screen-profiles, which provides a wrapper around screen.real.
They've gotten rid of the wrapper for future versions of Ubuntu.
In the meantime, you should try chmodding /usr/bin/screen.real, instead.
** Package
I'm currently using these three, as unsetting just GPG_AGENT_INFO no
longer seems sufficient.
unset GPG_AGENT_INFO
unset SSH_AUTH_SOCK
unset GNOME_KEYRING_SOCKET
(Not all of these necessarily relate to seahorse? I dunno, I just fix
what breaks for me. :)
--
Passphrase dialog doesn't
So, this _really_ isn't a screen bug. Screen is a terminal
mutliplexer, and would have absolutely nothing to do with the video
display/boot issues the user described.
Of course, dpkg _is_ choking on the screen package... but that's still
not a screen bug. Rather, it's a corrupted file download,
(Upstream maintainer) I simply cannot reproduce this bug. The output
indicates that Wget is unable to parse the size information from the
list (perhaps it is not available), and then (apparently?) loops forever
on some of these files.
I can obviously reproduce that Wget will try to download the
Actually, that's a feature, not a bug. It is not appropriate (nor
secure) for any web-authenticating tool to assume that the appropriate
authentication mechanism to use is HTTP Basic, which always sends
barely-obfuscated, cleartext passwords. Previous behavior doing so was
in violation of relevant
** Changed in: coreutils (Ubuntu)
Status: Confirmed = Fix Released
** Changed in: dpkg (Ubuntu)
Status: Confirmed = Fix Committed
--
man pages suggest info pages that don't exist.
https://bugs.launchpad.net/bugs/38538
You received this bug notification because you are a member of
I'm only using Jaunty, and can't seem to find a install-info package
there; but given that the core issue (documentation not matching
reality) is resolved already, and based on this new statement, I'd
consider it closed. (Also, the coreutils bit should probably already
have been closed, right?)
I'm not sure I understand: is the problem gone now that you've fixed
your $TERM? If so, this bug should be closed out.
It's a bad idea to lie to screen and tell it it's running under screen
when it's not (despite the fact that this piece of poor advice is
apparently all over the web).
I'm not at
Wuff --- Wuff is the vbell message; to disable it, put vbell off in
your ~/.screenrc.
The broken backspace thing... hit the backspace key a few times while
running cat within screen for clues to its source. A common cause is a
broken terminfo description (usually on xterm-color, I think), that
** Changed in: screen (Ubuntu)
Status: Incomplete = Invalid
** Changed in: screen (Ubuntu)
Assignee: greenmoss (ktyubuntu) = (unassigned)
--
A subset of input keys temporarily stop working
https://bugs.launchpad.net/bugs/349636
You received this bug notification because you are a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
So, as the documentation seems to be one of the biggest remaining
obstacles to a 4.1.0 release of GNU Screen, and as it's been this way a
very long time, I've taken one step towards trying to ease the prospect
of getting this work done.
I've gone
Could it possibly be the same bug, or at least related to
https://savannah.gnu.org/bugs/?26742 ?
The fact that the backend crashes strongly suggests to me that it's not
screen-profiles's/byobu's fault (though it may have generated the config
that triggers the bug in screen). Even if
No, everyone's busy with other stuff :\
However, as you wrote that, I was (am) in the middle of writing an
outline of exactly what doc work needs to be done before a release can
happen. There are also a few small showstopper bugs that would need to
be fixed, but the doc work is by far the more
This is usually a symptom of a broken terminfo description for whatever
terminal you happen to use screen from (specifically, the ti/te
capabilities). A workaround would probably be to place
termcapinfo foo ti@:te@
in your ~/.screenrc; where foo is the name your terminal identifies
itself as
(I'll just add here that FWIW Ubuntu does not in fact ship with
.bash_profile at all, just the .bashrc)
--
newly opened gnome-terminal windows don't have .bash_profile sourced
https://bugs.launchpad.net/bugs/17962
You received this bug notification because you are a member of Ubuntu
Bugs, which
As an end user, then, you should add ~/bin/ to your path from within
.bashrc, rather than .bash_profile. It has long been historical practice
for xterms and the like not to spawn login shells by default. For this
reason, people have for many years followed the practice of placing
anything
*** This bug is a duplicate of bug 360950 ***
https://bugs.launchpad.net/bugs/360950
Note that wget never uses MSG_PEEK anywhere.
Last I heard, it sounded like this bug was in the kernel, and has been
fixed in upstream (kernel)? Unfortunately, I have no references to
substantiate this: if
*** This bug is a duplicate of bug 360950 ***
https://bugs.launchpad.net/bugs/360950
Aha! :)
--
TCP(wget:3084): Application bug, race in MSG_PEEK
https://bugs.launchpad.net/bugs/389043
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Nonconventionally Creative wrote:
Public bug reported:
Binary package hint: wget
From the man page:
Use of -O is not intended to mean simply use the name file
instead of the one in the URL; rather, it is analogous to shell redirection:
wget -O file http://foo
is
*** This bug is a duplicate of bug 66104 ***
https://bugs.launchpad.net/bugs/66104
Arne, well, this issue report is now a duplicate, so I don't believe you can
resolve this report.
This issue will be resolved when the core report is resolved; at this time, the
problem still exists as of
Still experiencing this on Intrepid. I hadn't been worrying about it
because I wasn't using SCIM often enough to make it worth having
enabled; however, I've been needing it again lately, and the symptoms
are severe and annoying, to the point that the desktop is on the border-
line of usable. Even
*** This bug is a duplicate of bug 66104 ***
https://bugs.launchpad.net/bugs/66104
** This bug has been marked a duplicate of bug 66104
[Gutsy] scim: input freezes in various applications under XIM mode
--
Input ignored when switching workspaces, closing windows...
*** This bug is a duplicate of bug 66104 ***
https://bugs.launchpad.net/bugs/66104
Thanks for the swift response, Arne.
I managed to find the core report, which at least has some suggested
workarounds. Switching from scim to scim-immodule seems to have
fixed it for so far (for 30 seconds'
1 - 100 of 915 matches
Mail list logo
