Same here. Ran "pkexec do-release-upgrade -m desktop -f
DistUpgradeViewKDE" and this crashed after a short time, with the above
exception in /var/log/dist-upgrade
Annoyingly, the tool had already made sufficient changes (to the
sources.dist?), so re-running the upgrade, even from the command line
I would like to humbly quote from someone who once made a very
passionate argument for diversity, openness, and knowing how to embrace
different ideas from the contributor and user community in a project:
> This is a critical juncture for the leadership of Gnome. I’ll state
> plainly that I feel t
I have the same problem on my Gentoo system, using kernel 2.6.37. For
searching reference, this is an Asus P8P67-LE motherboard, with a
Marvell 88SE9120 SATA 6 Gb/s + PATA controller. I've researched this by
looking at the driver sources and the Linux kernel changelogs.
The problem here is that th
Hello; just checking to see if someone had had the chance to pick up on
this.
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to python-qt4 in ubuntu.
https://bugs.launchpad.net/bugs/561303
Title:
PyQt4 applications crash at exit
--
kubuntu
Thank you. I had opened bug #694541 in the meantime, to track the Lucid-
specific part. Please feel free to close that if you believe it best to
solve the problem here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launc
Public bug reported:
Binary package hint: python-qt4
python-qt4 (PyQt4) is broken on Lucid Lynx. This has been reported in
bug #561303 and a fix was issued for Maverick, but the bug was closed
without fixing the problem on Lucid, which is a long term support
release. I am opening this bug to trac
The problem still exists in Lucid Lynx, which is a long term support
release. Will the problem be fixed in Lucid as well, or will those of us
who use the long term support release have to give up on any
expectations of support?
--
You received this bug notification because you are a member of Kub
Confirmed on KUbuntu 8.04.
** Changed in: compiz (Ubuntu)
Status: New => Confirmed
--
compiz update 1:0.7.4-0ubuntu7 doesn't include compiz-kde update
https://bugs.launchpad.net/bugs/242438
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Thank you for your responses, dAniel and Luke. I appreciate the
clarification.
Of course I did not believe this to be the norm in a great distribution
like Ubuntu, and I am happy to contribute to such a worthy project. I
was frustrated with what happened, though, especially since I did not
hear an
No answer, I see. Is this really how things work at Ubuntu? It would
have been polite, not to mention proper, to at least name the person who
found the problem, corrected it and bothered to send the solution to
you. So the patch and even the changelog entry are good enough to use,
but not the name
Hmm, no attribution to the bug reporter/patch creator?
--
[patch] fix broken --stdin-stdout option that writes to stdin
https://bugs.launchpad.net/bugs/121458
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing
Understood. I have reported the bug to Debian, it can be seen on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429885 (as is
incidentally now indicated in the bug status above)
--
[patch] fix broken --stdin-stdout option that writes to stdin
https://bugs.launchpad.net/bugs/121458
You received
** Tags added: patch
--
[patch] fix broken --stdin-stdout option that writes to stdin
https://bugs.launchpad.net/bugs/121458
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Public bug reported:
Binary package hint: httptunnel
The --stdin-stdout option is broken, both in the client (htc) and the
server (hts). When used, the program writes its output to stdin instead
of stdout. This breaks anything calling htc or hts with --stdin-stdout,
unless stdin happens to be som
Patch to fix the problem (caused by a broken check in the source).
ChangeLog entry:
2007-06-20 Israel G. Lugo <[EMAIL PROTECTED]>
* common.c (handle_tunnel_input): really write to stdout if fd == 0.
** Attachment added: "Patch to fix the problem (caused by a broken check in
Just an update to note that the fix I submitted upstream was accepted (
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3991#c2 ):
--- Additional Comment #2 From Ulrich Drepper 2007-02-16 07:58
[reply] ---
Should indeed be possible. Applied to the trunk.
This is included in my p
I took a quick look at the program's source code, and they are doing a
lot of definitions of system constants by themselves. For example, in
socket.h line 79, they have:
#define SOCK_STREAM 0
This file is included from netuser.h:38, which is included from
tcp.h:26, which is included from iface.h:
** Attachment added: "Proposed fix for the problem"
http://librarian.launchpad.net/6340736/glibc-cleanup_assert.patch
--
[patch] assert and assert_perror macros contain unreachable code
https://launchpad.net/bugs/83811
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.u
** Description changed:
This bug affects libc6-dev 2.4-1ubuntu12.3 (and, presumably, all
previous versions as well).
The assert and assert_perror macros, defined in /usr/include/assert.h,
contain unreachable code in the failure case. To reproduce, do the
following:
$ cat > test-a
Public bug reported:
This bug affects libc6-dev 2.4-1ubuntu12.3 (and, presumably, all
previous versions as well).
The assert and assert_perror macros, defined in /usr/include/assert.h,
contain unreachable code in the failure case. To reproduce, do the
following:
$ cat > test-assert.c <<_EOF
#inc
20 matches
Mail list logo
