Package: src:linux
Followup-For: Bug #850780
I've tried booting the current kernels, and the current
linux-image-4.9.0-2-amd64 (version 4.9.13-1) is able to boot on this system.
Thank you.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (900, 'testing'), (600,
Control: severity 851545 serious
On second thought, this bug should probably be release-critical, since
it utterly breaks upgrades on at least many systems, even if not all.
Worst part might be that now my system's package management is probably
permanently hosed, since there's no obvious way to
Den 10. jan. 2017 05:00, skrev Ben Hutchings:
>> I tried using "earlyprintk=vga" like suggested in #841850, but it had no
>> effect. Maybe that option doesn't work if grub2 boots in graphics mode,
>> but I'm not sure how to disable that without causing other boot errors.
>> Maybe you have some
Package: src:linux
Version: 4.8.15-2
Severity: critical
Justification: breaks the whole system
I'm still stuck with linux 4.6 on this laptop. Both the current 4.7 and
4.8 images just hangs on "Loading initramfs". There aren't any further
messages.
It has similarities to #841883, but I'm
Source: libclc
Version: 0.2.0+git20150813-3
Severity: normal
I cannot install mesa-opencl-icd:i386 on my amd64 system, because it depends on
libclc-amdgcn and libclc-r600, which are "Architecture: all", but they do not
declare "Multi-Arch: foreign".
According to bug #722880, needing "Multi-Arch:
Package: gir1.2-gee-1.0
Version: 0.6.8-2
Severity: normal
I'm pretty sure libgee has nothing to do with Telepathy, and the long
description doesn't mention it, so it's not clear why the short description for
gir1.2-gee-1.0 mentions Telepathy...
-- System Information:
Debian Release:
Package: libz3-dev
Version: 4.4.0-5
Severity: serious
Justification: Policy 8.1
The libz3-dev package currently contains a shared library, libz3.so.4.
According to Debian policy, such a library must be in a package "whose name
changes whenever the SONAME of the shared library changes", normally
Package: anjuta
Version: 2:3.18.2-1
Severity: normal
About half the time I save any source file from within Anjuta, this pops up:
The file "filename" on the disk is more recent than the current buffer.
Do you want to reload it?
That's a little annoying, given that I like to save often, and
Den 21. des. 2013 16:50, skrev Andreas Cadhalpun:
Hi Ove,
at least for me, Code::Blocks still has icons in the Gnome 3 dock and
the application list. I have pretty much the same setup as you (Debian
testing, codblocks 12.11-3), so I don't see, what could cause the problem.
Do you still
Package: codeblocks
Version: 12.11-3
Severity: normal
After some upgrade, Code::Blocks no longer have an icon in the Gnome 3 dock and
application list. (There's still an icon in the Alt-Tab popup.) Since the dock
only shows icons and not program names, it's essentially invisible there, and I
keep
Package: gnome-shell
Version: 3.8.4-5
Severity: important
After upgrading to gnome-shell 3.8, the top panel no longer accepts touchscreen
input. I.e. trying to tap or hold-press Applications, or the calendar, the
systray, or the user menu doesn't work. Whatever I'm poking at does get the
Package: xfce4-terminal
Version: 0.4.8-1+b1
Severity: normal
This problem does not always happen. The most reliable way to
reproduce that I've found is:
- In xfce4-terminal, log into another host using mosh.
- If necessary, use clear, so that the cursor is not at the bottom
- Choose a
On 10. aug. 2012 06:42, Yves-Alexis Perez wrote:
On ven., 2012-08-10 at 06:36 +0200, Ove Kåven wrote:
This only seems to happen with the combination mosh+xfce4-terminal.
It doesn't happen with regular ssh, and it doesn't happen with
gnome-terminal or xterm. The mosh version is 1.2.2-1
On 03/28/2012 04:49 PM, Ivan Baldo wrote:
Hello Ove!
I appreciate your work and time, what follows is just a constructive
opinion for your consideration.
Many of the things you mention are really upstream bugs and considering
your limited time it would be best just to delegate that work to
Hi. Apologies for not having the time to follow up on everything I should.
Studying leaves you with less free time than you'd think, and the
accelerated plan I'm following just makes it worse, and when you also
need a paid job and stuff in order to be able to afford it all, you
inevitably get
Den 18. aug. 2011 10:44, skrev Julian Taylor:
As I understand this is partly intentional due to the existing circular
dependencies.
Circular dependencies in shared libraries are not a very good practice, can
these circles be broken somehow?
Not likely. Upstream designed these libraries to be
Den 18. aug. 2011 23:09, skrev Julian Taylor:
it turns out the issue can be solved by simply reordering
the links on the commandline.
If possible, I'd prefer that issues such as this be resolved by changing
how SimGear libraries are linked. The rules governing what libraries
SimGear
If you wanted to know what your *actual* problem might be, see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638867
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 08/01/2011 02:38 PM, Niels Thykier wrote:
Hi,
flightgear appears to be FTBFS on several architectures with the following:
I suppose they need to be built against simgear-dev = 2.0.0-3, not
simgear-dev 2.0.0-2. Will it be necessary to upload new flightgear just
to force the build-dep
Den 16. mai 2011 17:53, skrev Alessio Treglia:
any news on this?
I've been more busy than I thought, and won't have much time for the
next 3 weeks.
It might happen sooner if Stephen Kitt were to write the get-orig-source
rule for wine-gecko for me, so I wouldn't have to spend time on that
Den 27. april 2011 13:51, skrev Jairot Llopis:
Ove kindly sponsored my mingw-w64 packages; one of them is already in
unstable, the other two are waiting in NEW. Once they're all in he
will be
able (at last!) to start working on new versions of wine.
I just wanted to
Do you have any kind of evidence that any of this is actually
FlightGear's fault? If you are running bleeding-edge versions of the
open source DRI drivers (which it looks like you are), I think you might
want to contact the DRI developers first. Perhaps you have installed
mismatched versions of
Den 12. jan. 2011 05:11, skrev Nobuhiro Iwamatsu:
forwarded 572428
https://sourceforge.net/tracker/?func=detailaid=3156021group_id=26352atid=387125
thanks
Hi,
This problem does not fix 2.0.0.
I updated this patch and BTS for upsteam with bts-link.
Note that your patch was/is in direct
Den 12. jan. 2011 11:40, skrev Nobuhiro Iwamatsu:
OK,
I made the patch which supported SuperH only.
I attach it. Could you check this patch?
According to my web searches, there may be some SuperH toolchains out
there (like GNUPro, it seems) which define __LITTLE_ENDIAN__, but not
On 10. jan. 2011 06:19, Gerardo Esteban Malazdrewicz wrote:
I was able to compile it after rebuilding simgear with the attached patch.
That patch isn't a proper fix and shouldn't even make a difference, the
missing symbol isn't in libdl. (And the thing builds fine on my machines
without any
25 matches
Mail list logo
