Bug#345681: x-window-system-core incorrectly requires both xfonts-75dpi and xfonts-100dpi
Package: x-window-system-core Version: 6.9.0.dfsg.1-1 The x-window-system core package currently depends on both xfonts-75dpi and xfonts-100dpi. In the package description for xfonts-75dpi, there is the note: This package and xfonts-100dpi provide the same set of fonts, rendered at different resolutions; only one or the other is necessary, but both may be installed. xfonts-100dpi contains a mirror of the same sentence. These packages are thus in disagreement with one another about what dependencies exist. I suspect that the font packages are correct. I suggest changing the relevant part of the x-window-system-core dependency list from xfonts-100dpi, xfonts-75dpi to xfonts-100dpi | xfonts-75dpi. For the record, although it is unlikely to matter: this is with kernel 2.6.11.2, compiled myself this past March from the kernel source packages provided (according to memory which may be faulty) by Debian. I'm tracking sid, mostly, although I'm far behind the upgrade curve in some places. I have libc6 2.3.5-8.1. In the equally unlikely event that more information is needed, please do not hesitate to contact me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388861: apt-listchanges: consistently fails with traceback in DebianControlParser.py line 19
Package: apt-listchanges
Version: 2.63
Severity: grave
Justification: renders package unusable
For some time now, every time I install a package via apt-get,
apt-listchanges does not pop up its display of changelogs. Instead, I
get the following (immediately after Retrieving bug reports... Done):
Traceback (most recent call last):
File /usr/bin/apt-listchanges, line 210, in ?
main()
File /usr/bin/apt-listchanges, line 65, in main
status.readfile('/var/lib/dpkg/status')
File /usr/share/apt-listchanges/DebianControlParser.py, line 47, in
readfile
self.stanzas += [DebianControlStanza(x) for x in open(file,
'r').read().split('\n\n') if x]
File /usr/share/apt-listchanges/DebianControlParser.py, line 19, in
__init__
field, value = line.split(':', 1)
ValueError: need more than 1 value to unpack
This is followed by the (Reading database ... line as usual.
I can provide further details upon request, once I know what details may
be needed.
(For the record, the technical parts of this report were generated by
reportbug, but it timed out sending the mail so I'm doing it by hand.)
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to en_US.UTF-8)
Versions of packages apt-listchanges depends on:
ii apt 0.6.45 Advanced front-end for dpkg
ii debconf [debconf-2.0] 1.5.3 Debian configuration
management sy
ii debianutils 2.17 Miscellaneous utilities
specific t
ii python2.4.3-11 An interactive high-level
object-o
ii python-apt0.6.19 Python interface to libapt-pkg
ii python-support0.4.3 automated rebuilding
support for p
ii ucf 2.0014 Update Configuration File:
preserv
Versions of packages apt-listchanges recommends:
ii postfix [mail-transport-agent 2.2.10-1 A high-performance mail
transport
-- debconf information:
* apt-listchanges/confirm: true
* apt-listchanges/email-address:
* apt-listchanges/which: both
* apt-listchanges/frontend: pager
* apt-listchanges/save-seen: false
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388861: apt-listchanges: consistently fails with traceback in DebianControlParser.py line 19
Pierre Habouzit wrote:
Le sam 23 septembre 2006 02:50, The Wanderer a écrit :
Package: apt-listchanges
Version: 2.63
Severity: grave
Justification: renders package unusable
For some time now, every time I install a package via apt-get,
apt-listchanges does not pop up its display of changelogs. Instead,
I get the following (immediately after Retrieving bug reports...
Done):
Traceback (most recent call last):
File /usr/bin/apt-listchanges, line 210, in ?
main()
File /usr/bin/apt-listchanges, line 65, in main
status.readfile('/var/lib/dpkg/status')
File /usr/share/apt-listchanges/DebianControlParser.py, line 47, in
readfile
self.stanzas += [DebianControlStanza(x) for x in open(file,
'r').read().split('\n\n') if x]
File /usr/share/apt-listchanges/DebianControlParser.py, line 19, in
__init__
field, value = line.split(':', 1)
ValueError: need more than 1 value to unpack
please send me your /var/lib/dpkg/status (not to the bts because of
its size).
If you still need that after the below, just let me know and I'll pass
it along with no further fuss. (I ordinarily hate bug reporters who
refuse to follow instructions, especially requests for information, and
I don't like the idea of being one - but in this instance I think I may
know just enough about what's going on to avoid having to send a
multi-megabyte file through the mail.)
it seems you have some odd thing in there, and I've no clue of what
is happening.
technically, it can only happen if you have a line that does not
starts with a space, nor is empty, and has no ':' in it.
so either there is a \t starting line or so, and I need to deal with
that (but that would be quite suprising) or you have some
ill-formatted file. well, with that file I could have a clue.
Yep - that seems to be the cause. I grepped out lines which fit those
three criteria, and the three lines remaining all begin with tabs - they
appear in the description of gnome-system-tools 0.26.1-1 (which I do not
actually have installed, its status is 'deinstall ok config-files'). I'm
not sure of how to correctly clear that out, since editing the file by
hand to insert the appropriate spaces does not seem remotely correct;
any suggestions?
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429064: linux-libc-devel: linux/types.h conflicts with sys/ustat.h
Another month and more with no activity. Is anyone even paying attention to this bug? I am *still* postponing upgrades, including security updates, over this breakage. I reiterate: If this bug is important enough to be marked Serious, then it is too important to be left sit untouched this long, particularly when there is an apparently simple fix at hand. If the fix proposed is acceptable, it should be applied and the bug closed; if it is not acceptable, then it should be explicitly rejected with an explanation, so that an attempt at a better one can be made. I would take this up with the maintainer directly, except that there does not seem to be any such person... -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429064: linux-libc-devel: linux/types.h conflicts with sys/ustat.h
It has now been a full month since the patch was posted. Is there any progress towards getting it, or some other fix, applied? If not, is there any chance of an explanation of just why this patch is not considered acceptable, so that an alternate fix could potentially be proposed? This bug is blocking updates on 454 different packages for me, and blocking me from installing a number of additional packages I really want to have now that I finally have a use for them. The workaround/solution of installing linux-libc-dev and then applying the patch by hand does not sit well with me, in no small part since if I'm not mistaken I would then have to remember to re-patch by hand every time there was an update to the package. If this bug is not in fact important enough to warrant not upgrading packages because it has not been fixed, then it should not be marked as Serious. If it *is* that important, then it should not go this long without being addressed, particularly not when an apparently viable fix is as simple as the posted patch. I have been postponing package upgrades - including some security fixes - for close to the full two-month time this bug has been open, and am becoming decidedly uncomfortable with the situation. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429064: (no subject)
Would it then be (more) correct, or at least more acceptable, to add '#ifndef __KERNEL__' or similar to the glibc header file? How would that interact with the earlier statement from Aurelien Jarmo earlier in the discussion that The definition of the structure ustat in sys/ustat.h is associated with the C function ustat() since glibc 2.0 and in HP-UX. You can't simply remove it and standard. ? The core of the disagreement here seems to me to be the conflict between the statements linux-libc-dev should not directly export a kernel structure. Either remove it or use #ifdef __KERNEL__, but don't bother us with that. and it is no bug in the kernel to export its userspace interface. I have not seen anyone respond directly to either of these, but any solution acceptable to both sides will probably have to find some way to resolve this first. (For the record: I am assuming that other libcs will not necessarily provide the same structure in the same place, because otherwise I cannot see how your comment about glibc not being the only one provided by Debian is at all relevant to the issue at hand.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369405: kdrill: exits immediately with Warning: Unable to load any usable ISO8859 font\nError: Aborting: no font fond
) = 0xb7fe8000
write(1, kdrill 6.4: by Philip Brown -- p..., 49kdrill 6.4: by Philip
Brown -- [EMAIL PROTECTED]
) = 49
write(1, Starting up kdrill... please wai..., 43Starting up kdrill...
please wait a while.
) = 43
time(NULL) = 1148913433
brk(0) = 0x82da000
brk(0x82fb000) = 0x82fb000
open(/etc/mtab, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=721, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fe7000
read(3, /dev/hde3 / ext3 rw,errors=remou..., 4096) = 721
close(3)= 0
munmap(0xb7fe7000, 4096)= 0
open(/proc/meminfo, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fe7000
read(3, MemTotal: 515408 kB\nMemFre..., 1024) = 670
close(3)= 0
munmap(0xb7fe7000, 4096)= 0
uname({sys=Linux, node=pegasus, ...}) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
uname({sys=Linux, node=pegasus, ...}) = 0
uname({sys=Linux, node=pegasus, ...}) = 0
connect(3, {sa_family=AF_FILE, path=/tmp/.X11-unix/X0}, 19) = 0
uname({sys=Linux, node=pegasus, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
access(/home/wanderer/.Xauthority, R_OK) = 0
open(/home/wanderer/.Xauthority, O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=404, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fe7000
read(4, \1\0\0\7pegasus\0\0010\0\22MIT-MAGIC-COOKIE..., 4096) = 404
read(4, , 4096) = 0
close(4)= 0
munmap(0xb7fe7000, 4096)= 0
writev(3, [{l\0\v\0\0\0\22\0\20\0\0\0, 12}, {MIT-MAGIC-COOKIE-1,
18}, {\0\0, 2}, {*\2656h0\225\222\3037+\33\301!\317PH, 16}], 4) = 48
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
read(3, \1\0\v\0\0\0\23\2, 8) = 8
read(3, \200\35,\4\0\0\240\1\377\377\37\0\0\1\0\0\24\0\377\377...,
2124) = 2124
write(3, 7\0\5\0\0\0\240\1\31\1\0\0\10\0\0\0\377\377\377\0b\0\5...,
64) = 64
read(3, \1\0\2\0\0\0\0\0\1\203\0\0\24\0\0\0\24\0\0\0\0\0\0\0\0..., 32)
= 32
read(3, \1\0\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\30\0\0\0\0\0\0...,
32) = 32
write(3, \203\0\1\0, 4) = 4
read(3, \1\0\4\0\0\0\0\0\377\377?\0\4\0\0\0\4\0\0\0\220\1\0\0\0...,
32) = 32
writev(3, [{b\0\5\0\t\0\240\1, 8}, {XKEYBOARD, 9}, {\0\0\0, 3}],
3) = 20
read(3, \1\0\5\0\0\0\0\0\1\227p\260\24\0\0\0\24\0\0\0\220\1\0\0...,
32) = 32
write(3, \227\0\2\0\1\0\0\0, 8) = 8
read(3, \1\1\6\0\0\0\0\0\1\0\0\0\260e\210\10\32\0\0\0\10\0\0\0..., 32)
= 32
write(3, \20\0\5\0\v\0\0\0Custom Init\0, 20) = 20
read(3, \1\0\7\0\0\0\0\0F\1\0\0\0\0\0\0\24\0\0\0\24\0\0\0\220\1...,
32) = 32
write(3, \20\0\5\0\v\0\0\0Custom Data\0, 20) = 20
read(3, \1\0\10\0\0\0\0\0G\1\0\0\0\0\0\0\24\0\0\0\24\0\0\0\220..., 32)
= 32
open(/home/wanderer/.Xdefaults, O_RDONLY) = -1 ENOENT (No such file or
directory)
write(3, \20\1\6\0\20\0\0\0SCREEN_RESOURCES, 24) = 24
read(3, \1\0\t\0\0\0\0\0i\0\0\0\0\0\0\0\30\0\0\0\30\0\0\0\220\1...,
32) = 32
write(3, \24\0\6\0\31\1\0\0i\0\0\0\37\0\0\0\0\0\0\0\0\341\365\5...,
24) = 24
read(3, \1\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\30\0\0\0\220\1...,
32) = 32
uname({sys=Linux, node=pegasus, ...}) = 0
open(/home/wanderer/.Xdefaults-pegasus, O_RDONLY) = -1 ENOENT (No such
file or directory)
open(/home/wanderer/.Xdefaults, O_RDONLY) = -1 ENOENT (No such file or
directory)
open(/usr/share/X11/locale/locale.alias, O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=75126, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fe7000
read(4, #\t$XdotOrg: xc/nls/locale.alias,..., 4096) = 4096
read(4, 4\t\t\t\tbr_FR.ISO8859-14\nbr_FR.ISO-..., 4096) = 4096
read(4, en.ISO-8859-1\t\t\t\t\ten_US.ISO8859-..., 4096) = 4096
read(4, -1\t\t\t\tes_ES.ISO8859-1\nes_ES.iso8..., 4096) = 4096
read(4, _CA.iso885915\t\t\t\tfr_CA.ISO8859-1..., 4096) = 4096
read(4, _IT.88591.en\t\t\t\t\tit_IT.ISO8859-1..., 4096) = 4096
read(4, [EMAIL PROTECTED]..., 4096) = 4096
read(4, T.UTF-8\nsk\t\t\t\t\t\tsk_SK.ISO8859-2\n..., 4096) = 4096
read(4, \t\t\twa_BE.ISO8859-1\nwa_BE\t\t\t\t\t\twa..., 4096) = 4096
read(4, locale names\nISO8859-1\t\t\t\t\ten_U..., 4096) = 4096
read(4, G.koi8r:\t\t\t\t\tbg_BG.KOI8-R\nbe_BG, 4096) = 4096
read(4, -8\nGER_DE.8859:\t\t\t\t\tde_DE.ISO885..., 4096) = 4096
read(4, O-8859-1:\t\t\t\tes_CR.ISO8859-1\nes_..., 4096) = 4096
read(4, 8\nfr:\t\t\t\t\t\tfr_FR.ISO8859-1\nfr_BE..., 4096) = 4096
read(4, HU.ISO-8859-2:\t\t\t\thu_HU.ISO8859-..., 4096) = 4096
read(4, mk_MK.MICROSOFT-CP1251:\t\t\t\tmk_MK..., 4096) = 4096
read(4, o_RO.utf8:\t\t\t\t\tro_RO.UTF-8\nru:\t\t..., 4096) = 4096
read(4, 859-1\nts_ZA.utf8:\t\t\t\t\tts_ZA.UTF-..., 4096) = 4096
read(4, 8859-8\nhrvatski:\t\t\t\t
Bug#369405: kdrill: exits immediately with Warning: Unable to load any usable ISO8859 font\nError: Aborting: no font fond
Philip Brown wrote: On Mon, May 29, 2006 at 12:06:02PM -0400, The Wanderer wrote: kdrill 6.4: by Philip Brown -- [EMAIL PROTECTED] Starting up kdrill... please wait a while. Warning: Unable to load any usable ISO8859 font Error: Aborting: no font found I am uncertain as to precisely what is going wrong; I have not been able to discover even what specific thing kdrill is trying to do - say, open a file containing a particular font - which is failing. (My last attempt to do so culminated in my upgrading libxaw7, which removed a segfault but did not fix the problem.) The error you are seeing, does not come from kdrill. it comes from the low-level libraries. (libxaw). ...somehow that doesn't surprise me. (I *knew* I should have left out that strace log...) I dont think this is a bug in kdrill. That's entirely possible... at best, it would seem to be a package-dependency problem, such that a particular font which kdrill needs to be installed isn't. What this sort of error usually comes from, is when the X libraries cannot even load the basic font fixed or some such. ...where would that font be found? The only things I find by 'locate -i fixed | grep -i font' are /usr/share/consolefonts/grfixed.psf.gz and eight various /usr/share/qte3/lib/fonts/fixed_*.qpf, none of which look like anything I'd recognize as being X-font-related; I'm not sure what I'd want to search on in order to find out what package would be expected to contain the relevant font(s), much less where I'd have to put them in order to have them load properly. (For that matter, is there an explanation anywhere of what exactly the various -*-*-font-* style font names mean, and what files they're talking about? I've never been able to make the least bit of sense out of them, and this time it looks like it's actually preventing me from understanding what's going on somewhere.) I'd kind of expect that if the X libraries were unable to load even the most basic of fonts, other programs (say, xterm?) might not work correctly - and everything else I've tried certainly seems to be functioning as expected... but I imagine I'm just making an unwarranted assumption somewhere. I dont see how kdrill could stop that from happening. You might want to remove $HOME/.kdrill, though, just to avoid any old resource definition conflicts Did that (and, temporarily, did the same with /etc/X11/app-defaults/KDrill, where the font defaults are specified), with no visible change. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369405: kdrill: exits immediately with Warning: Unable to load any usable ISO8859 font\nError: Aborting: no font fond
Okay, I figured it out. This is indeed not a bug in kdrill; it is yet another problem with the xorg transition to 7.x, in that the symlink /usr/lib/X11/fonts was not updated to point to /usr/share/fonts/X11 rather than the old location of /usr/X11R6/lib/X11/fonts/ (IIRC, I had to move or copy or some such fonts from the old location to the new to fix an unrelated problem); changing the symlink by hand fixed the problem. Feel free to mark the bug as done (since I presume I can't do it myself, and see no way to try anyway); the symlink issue probably does need to be dealt with somewhere, but this is not the correct place to do it. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#566268: angband: Fails to start in X11 mode without xfonts-base
Package: angband Version: 1:3.1.1.1626-1 Severity: important *** Please type your report below this line *** Angband has multiple display modes, selectable at runtime with the '-m' command-line option. By default, it runs with the X11 mode. Angband also installs a fair selection of fonts, in /var/games/angband/xtra/font/. In the two non-X11 display modes, it seems to load and use these fonts on its own. In X11 display mode, however, Angband does not load the fonts which it installs; instead, it relies on the fonts it needs being provided by the X server. The fonts needed by Angband's X11 mode are present in the xfonts-base package. It is apparently possible to install the angband package without having this package be installed. If I install Angband - any version I've tested, including both the latest version available via Debian and the one obtained by compiling a quite recent upstream source tree - and try to run it with no arguments on a machine which does not have the xfonts-base package installed, it exits with an error message about not being able to load a needed font. (I no longer have immediate access to such a machine, so I cannot readily report the exact message.) If I then install xfonts-base and restart X, the fonts are now present in /usr/share/fonts/X11/misc and are detected during X load, and Angband runs fine. Since it is possible to use Angband successfully in the other two display modes, or to manually add the Angband font directory to the X font search path, xfonts-base is not a hard dependency for the angband package. However, since xfonts-base is necessary for the game to run properly in its default mode, I would suggest that the angband package include a 'Recommends: xfonts-base' line. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages angband depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libncurses5 5.7+20090803-2 shared libraries for terminal hand ii libsdl-image1.2 1.2.10-1 image loading library for Simple D ii libsdl-mixer1.2 1.2.8-6+b1 mixer library for Simple DirectMed ii libsdl-ttf2.0-0 2.0.9-1ttf library for Simple DirectMedia ii libsdl1.2debian 1.2.13-5 Simple DirectMedia Layer ii libx11-6 2:1.3.2-1 X11 client-side library angband recommends no packages. angband suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547260: (no subject)
In the latest development version, I see that spelling used in two other places: * In the Display options menu, the one-line description for the view_yellow_lite option reads Use special colors for torch lite. * In object.txt, there's the parenthetical aside always true for lites. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518027: Dependence on configuration?
Is this bug still actually open, or is it just that no one has bothered to formally close it yet? It looks to me, from the discussion, that this has been completely unreproducible for anyone but the original reporter, and that the original reporter seems to have found a satisfactory resolution. If the original report points to a bug which could have other effects and needs to be fixed, then it's appropriate to still have a bug report covering that; if, however, the problem is a one-off, then there doesn't seem much point in leaving this open any longer. Even if the problem is not a one-off and the underlying bug could have other effects - according to a comment in the post which gave the bug report its current title, that actual bug if any is in dpkg-gensymbols, which seems to be part of dpkg-dev. If that's the case, wouldn't it be appropriate to have the bug be filed against dpkg-dev, rather than against libc6? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541477: enlightenment: configuration lost in update to e16
Package: enlightenment Version: 1:0.16.7.2-5.1 Severity: important -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages enlightenment depends on: ii enlightenment-data1:0.16.7.2-5.1 Enlightenment Window Manager Run T ii libaudiofile0 0.2.6-7Open-source version of SGI's audio ii libc6 2.9-24 GNU C Library: Shared libraries ii libesd0 0.2.41-5 Enlightened Sound Daemon - Shared ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libimlib2 1.4.2-5powerful image loading and renderi ii libsm62:1.1.0-2 X11 Session Management library ii libx11-6 2:1.2.2-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l Versions of packages enlightenment recommends: ii esound0.2.41-5 Enlightened Sound Daemon - Support ii menu 2.1.41 generates programs menu for all me Versions of packages enlightenment suggests: ii e16keyedit0.6-1 a keybinding editor for the enligh pn e16menuedit none (no description available) ii enlightenment-theme-blues 1:0.16.7.2-5.1 Hunchback's BlueSteel theme for E pn epplets none (no description available) ii eterm [x-terminal-emulato 0.9.5-2Enlightened Terminal Emulator ii xterm [x-terminal-emulato 244-1 X terminal emulator -- no debconf information I had written out many more details here, but that got lost when I had to kill reportbug when it tried to send the mail using my old E-mail address. (Then I typo'ed in ~/.reportbugrc and had to send the mail manually after re-writing it...) Essentially: I noticed that the enlightenment package is no longer available in unstable, and that packages which formerly depended on or recommended it now seem to depend on or recommend e16 instead. I inferred that e16 is 'replacing' enlightenment, so I installed e16 (which removed enlightenment) as a matter of course. When restarting X afterwards, startx complained that it couldn't find the program 'enlightenment' (referred to by ~/.xinitrc), and after I fixed that by adding what I guessed to have been a forgotten symlink to e16, I found out that it was looking in a new location (~/.e16/ instead of ~/.enlightenment/) for its config files - which themselves seemed to be laid out differently, so that simply copying the original directory over wouldn't work very well - and had therefore completely dropped my customized configuration. It may perhaps be necessary to make that sort of change from time to time, but it should never be done without at least providing a prominent warning in advance that things may well break and that manual conversion may be necessary (preferably with instructions on how to do so reliably); ideally, the conversion would be handled automatically, so that the switch is completely transparent from the user's perspective. Fortunately I was able to remove e16 and reinstall enlightenment from my local package cache (since it's not available through the repository in the usual fashion anymore), but not everyone who is likely to be making this type of update is going to be in a position to do that, and in any case remaining at an out-of-date version instead of tracking more recent fixes is not generally a good idea. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541477: closed by Marco Rodrigues goth...@sapo.pt (Package enlightenment has been removed from Debian)
On 08/22/2009 01:53 PM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the enlightenment package: #541477: enlightenment: configuration lost in update to e16 It has been closed by Marco Rodrigues goth...@sapo.pt. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Marco Rodrigues goth...@sapo.pt by replying to this email. It is indeed unsatisfactory. You filled the bug http://bugs.debian.org/541477 in Debian BTS against the package enlightenment. I'm closing it at *unstable*, but it will remain open for older distributions. For more information about this package's removal, read http://bugs.debian.org/492508. That bug might give the reasons why this package was removed and suggestions of possible replacements. Don't hesitate to reply to this mail if you have any question. As it happens, I had found that particular bug report myself in the last few days. It does not seem to provide the reasons for the package being removed (it simply states that that is the case), and the possible replacement which it indirectly suggests - e16 - is not viable, for the reasons I gave in my own bug report and which I elaborate on below. I am aware that the enlightenment package has been removed from Debian; that is precisely the problem, or at least part of it. According to the bug report you linked to, the enlightenment package has been replaced by the e16 package; however, according to what I have been told in response to my own bug report, there is no upgrade path from enlightenment to e16. It is therefore not viable to simply uninstall enlightenment and install e16, as I would expect to be the procedure for a replacement update; further configuration is needed. What's more, as far as I was able to tell when I inadvertently made the experiment, simply copying the ~/.enlightenment directory to ~/.e16 would not work; at a glance, the directories and the files they contain seem to have different formats. It does not appear to be possible to upgrade cleanly from enlightenment to e16 without losing configuration settings. e16 is stated to be the replacement for enlightenment (though apparently this is not advertised in ay way which would bring the fact to the attention of people who might need to make the switch). This seems to me to be a very obvious and very serious problem, which is in serious need of fixing before the removal of enlightenment can be made truly final. I understand if it is not possible (within the package guidelines) to automatically convert ~/.foobar config settings between packages, for technical and policy reasons. However, I would expect that if those settings will be lost, there would at least be a prominent alert message at install time (e.g. via apt-listchanges or simply the curses-based configuration dialogs) that these settings will have to be migrated by hand, with either an explanation of how to do so or a link to a place to find such an explanation. That would not be truly satisfactory, but it would be sufficient if no better solution is practical. Thank you for your contribution to Debian. You're quite welcome. I'd prefer to contribute more (and more practically) than I have, but I haven't had much time, and what I have has been taken up by other interests. Just because I'm less than happy in this case shouldn't be taken to mean that I'm unhappy with Debian; I like it very much, and that's precisely why it bothers me that a problem like this is being dismissed the way this one seems to be. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541477: closed by Marco Rodrigues goth...@sapo.pt (Package enlightenment has been removed from Debian)
On 08/23/2009 03:04 AM, Laurence J. Lane wrote: e16 is essentially forked code and a new package based on enlightenment. e16 isn't a drop-in replacement for enlightenment 0.16x. It's actually intended to not interfere with enlightenment. I would, in that case, have argued that the enlightenment package should not be removed until either such a replacement or an automated migration mechanism could be provided - but I can see how doing it that way could have been difficult, and in any case, what's past is done. The configuration files are not compatible, but some of the menus are. There's a README with some notes on migrating. It's temporarily not in the e16 1.0.0-x packages, but you can see it here: http://trac.enlightenment.org/e/browser/trunk/E16/e/docs/README Thank you for the link. Is there any chance of a notice about this change, and possibly a pointer to that file, being provided when installing e16 and having enlightenment already installed? Without something like that, I would expect that other people will trip over the change unexpectedly in much the same way I did, and not necessarily be able to revert the way I was (even for just the short term). From the description in that file, it seems as if it would be simple enough to write a dumb script to be run by hand to convert a given user's ~/.enlightenment to a ~/.e16 in an automated fashion; dependong on how dumb would be acceptable, I could write one myself. With a bit more smarts (e.g. a prompt to compare before replacing existing files, such as is used by apt-get when a config file has been changed), might it not be a good idea to provide such a script along with the e16 package - or perhaps in a transitional dummy enlightenment package? (And possibly also symlink the enlightenment executable to e16 at install time, if no file or symlink with that name already exists in the appropriate location?) The transition you seek is actually a change from enlightenment DR 0.16 to enlightenment DR 0.17. Various people from the e17 packaging team pestered me give up the enlightenment package. I eventually abandoned it and moved to e16, but the e17 packaging team decided not to use the enlightenment package. Okay. (For what it's worth, I actually support in principle the name 'e16' over 'enlightenment', I just don't like the lack of a migration path.) I've been interested in e17 in the past, but haven't switched for a variety of reasons, not least that it looks to be considerably heavier than e16. Should I plan to go that route, or are the changes from e16 to e17 big enough that I would be likely to prefer staying with e16 for the time being? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505938: (no subject)
It's been nearly three months, and the last activity on this that I know of was an acknowledgement over at the MySQL bug that this should be fixed, which came back in December. I'm hesitant to upgrade this package until the bug is resolved. Should we at least ping the MySQL people to ask whether this has been forgotten? -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580220: xserver-xorg-input-evdev: Logitech G500 mouse detected as 'USB HID v1.1 Keyboard'
Package: xserver-xorg-input-evdev Version: 1:2.3.2-4 Severity: important On my laptop, when I install xserver-xorg-input-evdev version 1:2.3.2-6 (now in testing), the next time I re-connect my Logitech G500 USB mouse it gets misdetected as a USB keyboard instead - and, naturally enough, completely fails to work as a mouse. Downgrading to version 1:2.3.2-4, from my local package cache, makes things work fine again. What information can I provide to help track down this problem? (Unfortunately, the automatically-appended Xorg.0.log is a bit of a mess; it's got multiple suspend-to-disk/resume cycles in it, and all the cruft from when I was testing the mouse to track down the problem. Sorry about that.) -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Dec 30 08:25 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1877984 Apr 19 13:20 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series] /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 1357 Apr 23 20:58 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: #Section Monitor # Identifier aticonfig-Monitor[0]-0 # Option VendorName ATI Proprietary Driver # Option ModelName Generic Autodetecting Monitor # Option DPMS true #EndSection # EDID version 1 revision 3 Section ServerLayout Identifier aticonfig Layout Screen 0 aticonfig-Screen[0]-0 0 0 EndSection Section Files ModulePath /usr/lib/xorg/modules/extensions ModulePath /usr/lib/xorg/modules EndSection Section Module Load glx EndSection Section Monitor # Block type: 2:0 3:fe # Block type: 2:0 3:0 # Block type: 2:0 3:fe # Block type: 2:0 3:0 # DPMS capabilities: Active off:no Suspend:no Standby:no # Block type: 2:0 3:fe # Block type: 2:0 3:0 Identifier LGD:6602 VendorName LGD ModelNameLGD:6602 ModeLine 1366x768 69.3 1366 1398 1430 1486 768 770 774 782 -hsync -vsync ModeLine 1366x768 69.3 1366 1398 1430 1486 768 770 774 782 -hsync -vsync Option DPMS true EndSection Section Device Identifier aticonfig-Device[0]-0 Driver fglrx BusID PCI:1:0:0 EndSection Section Screen # Monitoraticonfig-Monitor[0]-0 Identifier aticonfig-Screen[0]-0 Device aticonfig-Device[0]-0 MonitorLGD:6602 DefaultDepth 24 SubSection Display Viewport 0 0 Depth 24 EndSubSection EndSection Kernel version (/proc/version): Linux version 2.6.32-3-amd64 (Debian 2.6.32-9) (m...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-8) ) #1 SMP Wed Feb 24 18:07:42 UTC 2010 Xorg X server log files on system: -rw-r--r-- 1 root root 38714 May 4 09:34 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.6 Release Date: 2010-03-17 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-4-amd64 x86_64 Debian Current Operating System: Linux aqualung 2.6.32-3-amd64 #1 SMP Wed Feb 24 18:07:42 UTC 2010 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-3-amd64 root=UUID=f561648f-c790-477a-a08a-a19ad34f5d67 ro Build Date: 05 April 2010 02:21:15PM xorg-server 2:1.7.6-2 (Timo Aaltonen tjaal...@ubuntu.com) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Fri Apr 30 18:01:17 2010 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout aticonfig Layout (**) |--Screen aticonfig-Screen[0]-0 (0) (**) | |--Monitor LGD:6602 (**) | |--Device aticonfig-Device[0]-0 (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (**) ModulePath set to /usr/lib/xorg/modules/extensions,/usr/lib/xorg/modules (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or
Bug#580220: xserver-xorg-input-evdev: Logitech G500 mouse detected as 'USB HID v1.1 Keyboard'
On 05/04/2010 10:32 AM, Julien Cristau wrote: On Tue, May 4, 2010 at 10:01:38 -0400, The Wanderer wrote: X.Org X Server 1.7.6 Do you have a log from 1.7.6.901? Or did you upgrade the driver but neglected to restart X? I don't shut down X without specific reason; it's too disruptive to the things I normally keep running. In this case, I had started X, then later run apt-get update and noticed updated package versions (including, yes, updated xserver-xorg-core), then installed those versions, then did a suspend-to-disk/resume cycle, then noticed the problem. I can kind of see how using an updated xorg sub-package with an older running xorg could lead to problems in some cases (though in that case I'd think there should be a prominent please restart your X server as soon as possible! warning at the time of the upgrade), but I don't see how it could lead to this kind of misdetection, unless for some strange reason the code for detecting which type of device should be handled by what driver or sub-driver is actually split between the appropriate xserver-xorg-input* package and the core. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On 05/04/2010 02:40 PM, Jamey Sharp wrote: On Tue, May 4, 2010 at 6:54 AM, The Wanderer wande...@fastmail.fm wrote: I'm familiar with doing that (well, 'gdb foo' and 'run -v quux'), but I could have sworn that last time I tried it on a failed assertion, the 'bt full' returned no information, because the running program had already exited because of the failed assertion. No, assert calls abort(), which kills the current process with SIGABRT, which GDB traps before the process actually exits. Of course if this application is forking, it can be quite tricky to get gdb attached to the process that actually dies. It may be easier to run `ulimit -c unlimited` to enable core dumps, then let the application die, then use `gdb -c` to inspect the coredump. I tried that, both with running the shell-script wrapper and with running its commands by hand (just in case the ulimit setting was getting lost somewhere), and no core file seems to have been produced in any obvious location. I've checked /tmp, the current directory, and the directory with the executable being run by Wine, with no luck. I tried just running Wine under gdb, in case it would in fact catch the correct process; it did catch the signal after the assert, but 'bt full' just reported a series of #0 0x12345678 in ?? () No symbol table info available which obviously isn't very useful. Hey, does `glxinfo` assert-fail for you? No. The only thing which assert-fails for me, that I've tried so far, is Wine, and that only (as far as I can tell) when trying to use OpenGL. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On 05/04/2010 02:40 PM, Jamey Sharp wrote: Of course if this application is forking, it can be quite tricky to get gdb attached to the process that actually dies. It may be easier to run `ulimit -c unlimited` to enable core dumps, then let the application die, then use `gdb -c` to inspect the coredump. I've been doing some more fiddling with this, and I managed to get a viable stack trace using winedbg; see attached. (It should be a lot smaller than the last attachment. Is there any easy way to prevent attachments from being displayed inline that way when they're so big?) I also included a register dump, just in case that would be useful. Looking at the dump now, though, I'm suddenly no longer sure that it was taken at the correct stack frame; take it with a grain of salt. I can re-run the debug session if necessary. When you have the failed process in GDB, it would also help to go to the _XReply stack frame and print dpy-request and dpy-last_request_read. I'm guessing those will be 9 and 8, respectively. Unfortunately, I was not able to manage this. Possibly I don't understand how to go to the_XReply stack frame; I tried both 'select-frame 3' and 'frame 3' (the latter of which did print '#3 0x7e7a7f44 in _XReply () from /usr/lib32/libX11.so.6'), but both ways, I got only 'No symbol dpy in current context. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On 05/05/2010 11:43 AM, The Wanderer wrote:
On 05/04/2010 02:40 PM, Jamey Sharp wrote:
Of course if this application is forking, it can be quite tricky to
get gdb attached to the process that actually dies. It may be
easier to run `ulimit -c unlimited` to enable core dumps, then let
the application die, then use `gdb -c` to inspect the coredump.
I've been doing some more fiddling with this, and I managed to get a
viable stack trace using winedbg; see attached.
Really attached this time. I cut the lines from my failed attempts at
getting other info out of the log, since they weren't helpful and had a
bunch of garbage characters from backspacing and the like.
0019:001a: create process 'C:\Program Files\World of Warcraft\Wow.exe'/0x110738
@0x401000 (00)
0019:001a: create thread I @0x401000
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
0019:001a: loads DLL C:\windows\system32\KERNEL32.dll @0x7ede (00)
0019:001a: loads DLL C:\windows\system32\ntdll.dll @0x7ef6 (00)
0019:001a: loads DLL C:\Program Files\World of Warcraft\DivxDecoder.dll
@0x1000 (00)
0019:001a: loads DLL C:\windows\system32\rpcrt4.dll @0x7e96 (00)
0019:001a: loads DLL C:\windows\system32\advapi32.dll @0x7e9d (00)
0019:001a: loads DLL C:\windows\system32\gdi32.dll @0x7ea3 (00)
0019:001a: loads DLL C:\windows\system32\user32.dll @0x7eac (00)
0019:001a: loads DLL C:\windows\system32\winmm.dll @0x7ebe (00)
0019:001a: loads DLL C:\windows\system32\opengl32.dll @0x7e8d (00)
0019:001a: loads DLL C:\windows\system32\imm32.dll @0x7e65 (00)
0019:001a: loads DLL C:\windows\system32\mpr.dll @0x7e5c (00)
0019:001a: loads DLL C:\windows\system32\shlwapi.dll @0x7e57 (00)
0019:001a: loads DLL C:\windows\system32\comctl32.dll @0x7e2d (00)
0019:001a: loads DLL C:\windows\system32\shell32.dll @0x7e3a (00)
0019:001a: loads DLL C:\windows\system32\wininet.dll @0x7e60 (00)
0019:001a: loads DLL C:\windows\system32\msacm32.dll @0x7e2a (00)
0019:001a: loads DLL C:\windows\system32\ws2_32.dll @0x7e28 (00)
0019:001a: loads DLL C:\windows\system32\ole32.dll @0x7e14 (00)
0019:001a: loads DLL C:\windows\system32\dinput.dll @0x7e23 (00)
0019:001a: loads DLL C:\windows\system32\dinput8.dll @0x7e26 (00)
0019:001a: loads DLL C:\windows\system32\winspool.drv @0x7e0a (00)
0019:001a: loads DLL C:\windows\system32\lz32.dll @0x7e09 (00)
0019:001a: loads DLL C:\windows\system32\version.dll @0x7ef4 (00)
0019:001a: loads DLL C:\windows\system32\setupapi.dll @0x7e0d (00)
0019:001a: loads DLL C:\windows\system32\hid.dll @0x7e07 (00)
0019:001a: loads DLL C:\windows\system32\winex11.drv @0x7ded (00)
fixme:dbghelp_dwarf:compute_location Only supporting one breg (18 - 24)
trace:wgl:wglGetProcAddress func: 'wglGetIntegerv'
../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
0019:001a: exception code=0x8101
Unhandled exception code 0x8101
Unknown or malformed query Attached
0xf775f430 in ?? ()
trace: 98 = 80
Wine-gdb bt full
#0 0xf775f430 in ?? ()
No symbol table info available.
#1 0xf74bbb72 in *__GI_abort () at abort.c:88
act = {__sigaction_handler = {sa_handler = 0x3a74d0, sa_sigaction =
0x3a74d0}, sa_mask = {__val = {4149211453, 104, 80, 3831232, 3831020, 104, 80,
76, 2087318208, 4150058996, 76, 75, 3831192,
4149142594, 2087318216, 76, 3831232, 2087318216, 0, 4222451712,
2087318216, 2087318216, 2087318216, 2087318216, 2087318291, 2087318316,
2087318216, 2087318316, 0, 0, 0, 0}}, sa_flags = 0,
sa_restorer = 0xb}
sigs = {__val = {32, 0 repeats 31 times}}
#2 0xf74b168e in *__GI___assert_fail (assertion=0x7e8151d9
!dpy-xcb-reply_data, file=0x7e815189 ../../src/xcb_io.c, line=445,
function=0x7e8152f8 _XReply) at assert.c:78
buf = 0x7c69f2c8 (\363i|\360\363\\\367c/xcb_io.c:445: _XReply:
Assertion `!dpy-xcb-reply_data' faileP
#3 0x7e7a7f44 in _XReply () from /usr/lib32/libX11.so.6
No symbol table info available.
#4 0x7d75472f in LnxXextEscape () from /usr/lib32/libatiadlxx.so
No symbol table info available.
#5 0x7d733935 in Send () from /usr/lib32/libatiadlxx.so
No symbol table info available.
#6 0x7d747a81 in Pack_DI_AdapterCaps_Get () from /usr/lib32/libatiadlxx.so
No symbol table info available.
#7 0x7d73c458 in ADL_Workstation_AdapterNumOfGLSyncConnectors_Get () from
/usr/lib32/libatiadlxx.so
No symbol table info available.
#8 0x7b873603 in ?? () from /usr/lib32/dri/fglrx_dri.so
No symbol table info available.
Wine-gdb info all-registers
eax0x0 0
ecx
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
On 05/05/2010 03:21 PM, Jamey Sharp wrote: Yay, data! Thanks. On Wed, May 5, 2010 at 10:01 AM, The Wanderer wande...@fastmail.fm wrote: trace:wgl:wglGetProcAddress func: 'wglGetIntegerv' ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed. 0019:001a: exception code=0x8101 Unhandled exception code 0x8101 Unknown or malformed query Attached 0xf775f430 in ?? () trace: 98 = 80 Wine-gdb bt full #3 0x7e7a7f44 in _XReply () from /usr/lib32/libX11.so.6 No symbol table info available. You were right to type 'frame 3', you're just missing debug symbols. If you install libx11-6-dbg then you'll be able to get more information here, including the values of dpy-request and dpy-last_request_read. Sorry I didn't mention that before. In hindsight I think you may have, and I certainly do remember checking and noticing that I didn't have that particular package installed on that machine (though it is on my desktop for a different reason), but I apparently didn't remember to install it. #4 0x7d75472f in LnxXextEscape () from /usr/lib32/libatiadlxx.so I can't find this /usr/lib32/libatiadlxx.so in Debian. Where did it come from? (I'm not familiar with the fglrx packaging.) I suspect that it may have come from a previous manual installation of the fglrx driver(s), before I got the Debian packages working properly. I have now done the following: mv /usr/lib32/*ati* /root/backups/usr/lib32/ mv /usr/lib32/*fgl* /root/backups/usr/lib32/ apt-get install --reinstall fglrx-glx-ia32 and a quick test no longer gives the assertion failure; at a glance, everything seems to work fine. There is a specific instruction, in the manual-installation directions for the fglrx driver from AMD, to uninstall the existing driver via a specific shell script before installing an updated version. I don't think I'd found that part of the directions before making the switch from the manually-installed driver to the Debian-packaged driver; I certainly did not run the script before making the switch. Most likely, by coincidence the necessary libraries from the Debian-packaged version had the same ABI as the manually-installed version - or at least a compatible one - and so everything continued to work at that point. If there is any bug in the Debian packages, it would appear to be one of incomplete removal of the existing driver. However, while it would certainly be nice if installing or updating the Debian package would take the necessary steps to properly remove the manually-installed driver if one is present, it's not inherently required. If a previous version of one of these packages did install /usr/lib32/libatiadlxx.so (and the other related /usr/lib32 files not presently in Debian packages), then there is a bug in that they were not removed properly. If no previous version did such a thing, then the problem is user error on my part, and there is no actual bug. Thanks for the help tracking this down; I don't know if I'd have been able to narrow it down to the specific files involved on my own without a lot more manual work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579813: ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed.
Package: fglrx-driver Version: 1:10-3~prerelease-3 Severity: normal I should start out by saying that I am not 100% certain that this bug is in fglrx-driver; it also might be in libxcb, in Wine, or somewhere (else) in the OpenGL or GLX stack, or even in X. I am reporting it under fglrx-driver because I have to pick some package, and fglrx seems the most likely candidate. I track stable and testing. Fairly recently, I noticed that the fglrx-* packages could now be updated without needing to remove xserver-xorg*, and ran a partial dist-upgrade (omitting packages which have active bugs unless I can specifically determine that they don't affect me). In the process, both fglrx-driver and libxcb* were updated. After the update, I attempted to launch World of Warcraft under Wine. Instead of launching successfully (as it had been doing before the update), it exited before really getting started, with only the following console output: == ../../src/xcb_io.c:445: _XReply: Assertion `!dpy-xcb-reply_data' failed. err:module:attach_process_dlls opengl32.dll failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for LC:\\Program Files\\World of Warcraft\\Wow.exe failed, status 8101 == Googling on the assertion message produced numerous reports of a similar error (with a different, but consistent, line number) back in about 2008, which had apparently been caused by a change in the default locking behavior of xcb, triggering a formerly hidden bug in programs which had not been handling locking properly. Those reports mentioned that many different programs would produce the same error, including both OpenOffice.org Writer and glxgears. However, I am able to run both oowriter and glxgears without this error. The only thing I have found which produces this error is Wine. I have, however, been able to reproduce the problem (later in execution) with programs other than World of Warcraft. I therefore reported this as Wine bug 22490. The bug was closed as invalid in fairly short order, on the grounds that since Wine does not directly call libxcb, this cannot be a a Wine issue. It was suggested that I run Wine with 'WINEDEBUG=+synchronous,+wgl' in an attempt to obtain more information; however, doing so provided only the same console output as before. Grasping at straws, I obtained an strace log of the failing session, but it does not appear to contain any really usable information. I have considered attempting to downgrade fglrx-driver and/or the libxcb packages in order to narrow down the apparent location of this bug. However, doing so would not be a trivial matter, as downgrading either would effectively require me to also downgrade X; additionally, from the difficulty I have had with even installing or upgrading fglrx to date (having lost X temporarily almost every time), I am decidedly hesitant to attempt to downgrade it. As of yet, I have not been able to find any hints online that other people are experiencing this same issue. Whether this is because few people have both installed the updated versions of the packages involved and attempted to run something under Wine, or because there is something unusual about my own system, is not clear. What information can I provide which will help narrow down the location and/or cause of this bug, and how can I obtain that information? -- Package-specific info: VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series] DRM and fglrx Informations from dmesg: [0.00] No AGP bridge found [0.423163] Linux agpgart interface v0.103 [4.213257] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [4.256333] [fglrx] Maximum main memory to use for locked dma buffers: 3771 MBytes. [4.256867] [fglrx] vendor: 1002 device: 9553 count: 1 [4.257443] [fglrx] ioport: bar 1, base 0x2000, size: 0x100 [4.258013] [fglrx] Kernel PAT support is enabled [4.258223] [fglrx] module loaded - fglrx 8.72.10 [Mar 11 2010] with 1 minors [ 313.526469] fglrx_pci :01:00.0: irq 32 for MSI/MSI-X [ 313.526968] [fglrx] Firegl kernel thread PID: 2806 [ 313.527146] [fglrx] IRQ 32 Enabled [ 313.832462] [fglrx] Gart USWC size:1228 M. [ 313.832465] [fglrx] Gart cacheable size:487 M. [ 313.832470] [fglrx] Reserved FB block: Shared offset:0, size:100 [ 313.832472] [fglrx] Reserved FB block: Unshared offset:fc27000, size:3d9000 [ 313.832474] [fglrx] Reserved FB block: Unshared offset:1fffb000, size:5000 Xorg X server configuration file status: -rw-r--r-- 1 root root 1357 Apr 23 20:58 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: #Section Monitor # Identifier aticonfig-Monitor[0]-0 # Option VendorName ATI Proprietary Driver # Option ModelName Generic Autodetecting Monitor # Option DPMS true #EndSection # EDID version 1 revision 3 Section
Bug#554163: Bug #554163: Should import gqview preferences when migrating from gqview - geeqie
On 12/18/2009 05:01 AM, Michal Čihař wrote: Hi Dne Mon, 14 Dec 2009 07:51:32 -0500 The Wanderer wande...@fastmail.fm napsal(a): That doesn't make any sense. AFAIK GQView never tagged files with anything, and even if it did, a program which can understand such data should read it automatically from the image file instead of needing to explicitly import it; it might make sense to need to re-write the metadata in a new format, but that isn't what import would mean. GQView did have support for keywords and comments and it stored them separately. ..you mean separately as in, in a separate file? That seems bizarre (for at least the reason that I've never heard of this practice before, at least not for image files), but at least it does let the menu entry make sense; thank you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506552: fontconfig-config: Same or similar problem in icedove
The Wanderer wrote: Package: fontconfig-config Version: 2.6.0-3 Followup-For: Bug #506552 I am no longer nearly so certain that what I am seeing is the same bug. I have noticed that the same ugly-font problem is, in some cases, occurring in images as well as in normal text - images which I remember quite clearly being non-ugly before the change happened. Specifically, the text in the images down the right-hand side of the page at http://mother3.fobby.net/index.php show what looks like the same problem as I see elsewhere. Unfortunately, this makes it hard to show the difference to others, since any screen-captures I might make would probably look identical to the original images on any given machine. This means that what I am seeing is almost certainly not a font-related issue as such (and thus could not be bug in fontconfig-config), though it does so far manifest only in displayed text. I'm more or less stumped as to what it *could* be; the primary candidate would seem to be my video driver, but I haven't changed that since before the problem started (although I have recompiled it once in the interim, to get GL working again after an X-package update broke it - something which happens on a regular basis). Someone in #debian suggested that it might be bad xorg.conf settings or a failing monitor; that doesn't seem terribly likely to me, since A: I don't remember changing xorg.conf recently and B: the problem manifests only in certain programs, but I can't necessarily rule it out. I'm going to test with a different monitor later, but cannot do so for now. Assuming that the test with another monitor shows the same problem, any idea of what might have caused this, whether or not it might actually qualify as any kind of bug, and (if so) where might be appropriate to report that bug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506552: fontconfig-config: Same or similar problem in icedove
Andrew J. Buehler wrote: Package: fontconfig-config Version: 2.6.0-3 Followup-For: Bug #506552 I have just tested downgrading each obviously-could-be-related package (see list below) to the version in my package archive immediately preceding the one installed on the same day as the change, and the problem persists despite the downgrades (which are now reverted). Therefore, either I've missed a relevant package (possible), or I no longer have the correct working version in my archive (unlikely), or the problem is one of configuration which is only indirectly affected by the package contents - e.g. perhaps my local configuration was wiped out by the upgrade but naturally enough not restored by the downgrade. Testing was performed by shutting down and reopening Icedove, since it is much less of a hassle to restart than is Iceweasel, and shows the problem (in the form in which I see it) far more prominently. There is a faint chance that this is insufficient - that it would be necessary to restart X to see a change - but as that would be even more of a hassle than restarting Iceweasel, I have not tested it yet. The packages I tested downgrading are, in no particular order but with the tested all at once packages grouped together: package fromto xulrunner-1.9 1.9.0.4-2 1.9.0.3-1 fontconfig 2.6.0-3 2.6.0-1 fontconfig-config 2.6.0-3 2.6.0-1 libfontconfig1 2.6.0-3 2.6.0-1 libfontconfig1-dev 2.6.0-3 2.6.0-1 icedove 2.0.0.17-1 2.0.0.16-1 x-ttcidfont-conf31 30 ttf-liberation 1.04.92.dfsg-4 1.04~beta2-2 ttf-opensymbol 1%3a2.4.1-141%3a2.4.1-11 I also considered testing ttf-dejavu and libttf2, but the former has not been updated on my system since four months before the problem manifested (and seems to be up to date), and the latter has no older version on my system with which to test. Any suggestions for packages I could have missed testing, or other things I might want to try? -- This line is here because, while I don't want my usual .sig, it seems unnatural not to have one at all. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554163: Bug #554163: Should import gqview preferences when migrating from gqview - geeqie
Consider this seconded. I would also prefer if it could pick up the same window-manager settings as used by gqview (size, location, desktop, et cetera), but that's both significantly easier to re-set by hand and probably much harder to have happen automatically. It was mentioned in passing in bug 553920 that there is a menu entry in geeqie for migrating GQView metadata. From the context of that mention, it seems that this menu entry should perform exactly the migration being requested by this bug; it just doesn't do it by default on first run. I can see its being arguable that in fact it should not. However, I have not yet been able to confirm whether or not this menu entry actually does that migration. I would not expect it from the name (metadata to me refers to things like size tags and what program created this file and where I was when I took this picture information, and is per-file not per-program; I would expect the ~/.gqview/ information to be called configuration), and as far as I can tell, the geeqie Help manual does not even mention this menu item, much less explain what it does. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554163: Bug #554163: Should import gqview preferences when migrating from gqview - geeqie
On 12/14/2009 04:09 AM, Michal Čihař wrote: Hi Dne Sun, 13 Dec 2009 22:38:12 -0500 The Wanderer wande...@fastmail.fm napsal(a): However, I have not yet been able to confirm whether or not this menu entry actually does that migration. I would not expect it from the name (metadata to me refers to things like size tags and what program created this file and where I was when I took this picture information, and is per-file not per-program; I would expect the ~/.gqview/ information to be called configuration), and as far as I can tell, the geeqie Help manual does not even mention this menu item, much less explain what it does. Yes it's really just for metadata not for configuration. That doesn't make any sense. AFAIK GQView never tagged files with anything, and even if it did, a program which can understand such data should read it automatically from the image file instead of needing to explicitly import it; it might make sense to need to re-write the metadata in a new format, but that isn't what import would mean. I therefore now have no idea what this menu entry does, and am still looking for a way to migrate configuration (as would be necessary for geeqie to be considered a proper single-line-of-descent replacement for gqview). (...also, completely off the topic, why does the Debian BTS mail notification not set the reply-related headers sensibly? It's almost never going to be appropriate to reply just to the person who wrote the comment, rather than to the bug, and if you're replying to the bug then the person who wrote the comment is almost certainly going to be getting a copy anyway.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632386: kdrill: exits with 'Error: Object (null) does not have windowed ancestor'
Package: kdrill Version: 6.5deb2-2 Severity: important When using certain versions of the radical file (radkfile), KDrill will exit before displaying any window. When this happens (on my system), the full text output of KDrill is: kdrill 6.5: by Philip Brown -- p...@bolthole.com Starting up kdrill... please wait a while. Usefile .kanjiusefile does not exist. Using entire dictionary... Opened dictionary /usr/share/edict/kanjidic .. Opened dictionary /usr/share/edict/edict ...bad line: umility/(P)/ . NOTE: an infinity sign means there is no kanji. Switch to show meaning option to show alternates. Error: Object (null) does not have windowed ancestor I have been seeing this problem for some time when using manually updated versions of edict and related files, but it now appears to be happening with the versions available from Debian testing. Note that different versions of the bad line: output do still occur when using versions of the files which do not trigger this exit. That may be a problem, but it's probably not this problem. The error message is not printed by KDrill directly, but by the XtGetApplicationResources function from libxt. The call stack is: XtGetApplicationResources, library function called from prefs.c:64, in GetXtrmString called from radsearch.c:473, in InitRadicals called from main.c:171, in main Unfortunately, I have not been able to track the problem down further. It looks like something is wrong with the Widget argument which gets passed to XtGetApplicationResources, but I don't know Xt well enough to know where to get started figuring out what, and I don't know radkfile (et al.) well enough to figure out what part of the change in the recent updates may be triggering the difference. If there is anything I can do to help track down and fix this problem, please do not hesitate to let me know. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kdrill depends on: ii libc6 2.13-7 Embedded GNU C Library: Shared lib ii libx11-6 2:1.4.3-2 X11 client-side library ii libxaw7 2:1.0.9-2 X11 Athena Widget library ii libxmu6 2:1.1.0-2 X11 miscellaneous utility library ii libxt61:1.1.1-2 X11 toolkit intrinsics library Versions of packages kdrill recommends: ii kanadic 6.5deb2-2Katakana and hiragana drill files ii kanjidic2011.05.25-1 Kanji Dictionary ii xfonts-base 1:1.0.3 standard fonts for X Versions of packages kdrill suggests: ii edict 2011.05.25-1 English / Japanese dictionary ii xjdic 24-7 Japanese-English dictionary search -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640113: NameError': global name 'PIPE' is not defined
Package: moosic Version: 1.5.5-2 Severity: important When running moosic with any of the add to playlist commands (such as 'add' or 'mixin' or 'prepend') and passing a directory as the argument, moosic exits with the message NameError': global name 'PIPE' is not defined and nothing is added to the playlist. Files can still be added to the playlist by passing them in one at a time, and so directories can still be added by a pipeline such as 'find dirname/ -type f -print0 | xargs -0 moosic add', so this does not make the program completely unusable. However, it does make it unnecessarily difficult to build large-sized playlists, and as such significantly undermines the usability of the program for my purposes. This behavior did not manifest in the version of moosic I was running prior to the packaging of 1.5.5. I did not notice the problem before now because I was still running through a large playlist which had been built with a previous version; it is only today that I have needed to add more files to the playlist. If there is anything I can do to help narrow this down and get it fixed, please do not hesitate to let me know. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages moosic depends on: ii python2.6.7-3interactive high-level object-orie ii python2.7 2.7.2-5An interactive high-level object-o Versions of packages moosic recommends: ii mpg3210.2.13-3 Simple and lightweight command lin Versions of packages moosic suggests: ii mikmod 3.2.1-2 Portable tracked music player ii sox 14.3.2-2 Swiss army knife of sound processi ii timidity2.13.2-39+b1 Software sound renderer (MIDI sequ ii vorbis-tools1.4.0-1 several Ogg Vorbis tools -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639091: moosic: dies when not run with python2.7
Package: moosic Version: 1.5.5-1 Severity: important On my system, moosic now dies on launch, with the following output: Traceback (most recent call last): File /usr/bin/moosic, line 6, in module main(sys.argv) File /usr/lib/python2.6/dist-packages/moosic/client/cli/main.py, line 243, in main moosic.no_op() File /usr/lib/python2.6/xmlrpclib.py, line 1199, in __call__ return self.__send(self.__name, args) File /usr/lib/python2.6/xmlrpclib.py, line 1489, in __request verbose=self.__verbose File /usr/lib/python2.6/xmlrpclib.py, line 1237, in request errcode, errmsg, headers = h.getreply() AttributeError: HTTPConnection instance has no attribute 'getreply' That error appears to be the result of a change which arose in Python 2.7. However, since moosic's shebang is #!/usr/bin/python, and python-minimal currently installs that as a symlink to 'python2.6', and the Python libraries listed in the traceback are from python2.6, moosic is apparently being run with Python 2.6; therefore this error should not be appearing. I have now seen this behavior on two different systems, both of which track testing. I first saw this error in moosicd, on a system where Python 2.7 was not installed. Installing the python2.7 package made the error go away for moosicd, but it still occurs for moosic itself. If I explicitly launch moosic with python2.7, rather than relying on the shebang, it runs fine. This is very probably a bug in one or more of the Python packages, such that the correct versions of the Python libraries are not always being used. However, since I have no idea which package(s) are at fault, and since the problem could be fixed by adding a dependency on python2.7 and changing the shebang line, I am reporting it here. This problem could be worked around at the user end if the '/usr/bin/python' symlink were handled by the alternatives system. However, since it is instead installed explicitly by python-minimal, that is not an advisable solution. If there is anything I can do to help track down and resolve the problem, please do not hesitate to let me know. I use moosic daily, and having to jump through hoops to get it to be usable is exceedingly inconvenient. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages moosic depends on: ii python2.6.7-3interactive high-level object-orie ii python2.6 2.6.7-3An interactive high-level object-o ii python2.7 2.7.2-3An interactive high-level object-o Versions of packages moosic recommends: ii mpg3210.2.13-3 Simple and lightweight command lin Versions of packages moosic suggests: ii mikmod 3.2.1-2 Portable tracked music player ii sox 14.3.2-1 Swiss army knife of sound processi ii timidity2.13.2-39+b1 Software sound renderer (MIDI sequ ii vorbis-tools1.4.0-1 several Ogg Vorbis tools -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635111: libnss3-1d: java.io.FileNotFoundException: /usr/lib/libnss3.so in 3.12.10-2
Package: libnss3-1d Version: 3.12.10-2 Severity: critical Justification: breaks unrelated software The libnss-1d 3.12.10-2 update breaks logging in to Minecraft. After updating libnss3-1d from 3.12.10-1 to 3.12.10-2, attempting to log in to Minecraft (which is Java-based and authenticates to a remote site) fails with the following messages: java.security.ProviderException: Could not initialize NSS at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:201) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:103) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:262) at sun.security.jca.ProviderConfig$3.run(ProviderConfig.java:244) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:244) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:224) at sun.security.jca.ProviderList.getProvider(ProviderList.java:232) at sun.security.jca.ProviderList$ServiceList.tryGet(ProviderList.java:433) at sun.security.jca.ProviderList$ServiceList.access$200(ProviderList.java:375) at sun.security.jca.ProviderList$ServiceList$1.hasNext(ProviderList.java:485) at sun.security.jca.GetInstance.getInstance(GetInstance.java:170) at javax.net.ssl.SSLContext.getInstance(SSLContext.java:142) at javax.net.ssl.SSLContext.getDefault(SSLContext.java:85) at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:119) at javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:344) at javax.net.ssl.HttpsURLConnection.init(HttpsURLConnection.java:302) at sun.net.www.protocol.https.HttpsURLConnectionImpl.init(HttpsURLConnectionImpl.java:85) at sun.net.www.protocol.https.Handler.openConnection(Handler.java:62) at sun.net.www.protocol.https.Handler.openConnection(Handler.java:57) at java.net.URL.openConnection(URL.java:963) at net.minecraft.Util.excutePost(Util.java:68) at net.minecraft.LauncherFrame.login(LauncherFrame.java:96) at net.minecraft.LoginForm$5.run(LoginForm.java:117) Caused by: java.io.FileNotFoundException: /usr/lib/libnss3.so at sun.security.pkcs11.Secmod.initialize(Secmod.java:186) at sun.security.pkcs11.SunPKCS11.init(SunPKCS11.java:197) ... 27 more Before the update, this did not happen. In 3.12.10-1, the libnss3 .so files and associated symlinks were located in /usr/lib/, which is where I would expect them to be. In 3.12.10-2, they have been moved to /usr/lib/x86_64-linux-gnu/, where apparently something does not know to look for them. This could be because necessary changes to let the system know to look in the new location have not been made, because the path is hardcoded into the Java libraries, or because the path is hardcoded into Minecraft itself. I do not know which. I do not (know that I) have access to any other Java-based programs which use NSS, so I do not know whether or not this would also happen with Java applications other than Minecraft. There is a possibility that this is simply a problem with Minecraft, and if so, there's room to argue that since that's a third-party non-packaged non-free application, Debian has no responsibility for fixing what broke when the library moved. However, there's also room to argue that Minecraft is simply relying on system libraries, and that it is very much Debian's responsibility to make sure that those are accessible to any software, regardless of provenance. I do not know which argument is correct in this instance. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libnss3-1d depends on: ii libc6 2.13-10 Embedded GNU C Library: Shared lib ii libnspr4-0d 4.8.8-2 NetScape Portable Runtime Library ii libsqlite3-03.7.7-2 SQLite 3 shared library ii multiarch-support 2.13-10 Transitional package to ensure mul ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime libnss3-1d recommends no packages. libnss3-1d suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email
Bug#635111: Acknowledgement (libnss3-1d: java.io.FileNotFoundException: /usr/lib/libnss3.so in 3.12.10-2 )
Apparently people are ahead of me, and somehow I'm not being notified of changes to the bug even though I reported it (?). Yes, changing the path in /etc/java-6-openjdk/security/nss.cfg makes this work again. Last night when I tried this it didn't seem to work; I got an actual crash, with *** glibc detected *** java: free(): invalid next size (fast): 0x7fb9a8509bf0 ***, but today that does not happen. I think that crash may have happened while I still had incorrect remnants of an earlier attempt to fix the problem still in place. I agree, on further information this does seem to be a problem with openjdk rather than with libnss3. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679786: e16: Root-window menus don't work, on first virtual desktop only
Package: e16 Version: 1.0.0-4 Severity: important Dear Maintainer, In E16, clicking on the root window normally brings up one of three menus, depending on whether it was a left-, middle-, or right-click. To the best of my awareness, this is the primary means of launching applications in that window manager. In my current configuration, on the first virtual desktop (as defined by the 'desktops.num' setting in the e16 config file), clicking on the root window does nothing. However, in the second - and, to the limits of my testing thus far, any subsequent - virtual desktop, clicking on the root window brings up menus as normal. This behavior means that anyone running E16 with only one virtual desktop has no way to launch applications in X, unless they either have launch shortcuts configured in the E16 keybindings or go through the trouble of switching to console, launching eesh with an appropriate DISPLAY setting, and running an 'exec' command. I have reproduced this problem in multiple versions of E16, including 1.0.0-3.1 and a self-compiled version of 1.0.10 (which has never been packaged by Debian). I have not thus far been able to find a copy of the .deb for 1.0.0-3, or any previous version which would not be incompatible with the system changes made in -3.1, so I have not been able to test it in versions before that point. This behavior occurs even in the default configuration generated by removing ~/.e16/ and re-launching X (to re-initialize E16). I suspect that this is a bug being triggered by some change elsewhere in the system, rather than in E16 itself, but I cannot be completely certain of that. This problem first manifested after a forced reboot due to a power outage. During the uptime prior to that reboot, I had dist-upgrade'd a relatively wide selection of packages. I am fairly certain that e16 was held and thus should not have been one of them, but I am also fairly certain that I had previously been running 1.0.0-3, not 1.0.0-4. I would like to try to identify exactly where in the system configuration this problem is being triggered, and how to fix it. However, due to the lack of logs or console output from E16, I have nothing to go on. Where should I be looking to diagnose this? -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages e16 depends on: ii e16-data1.0.0-4 ii libaudiofile0 0.2.7-0.1 ii libc6 2.13-33 ii libdbus-1-3 1.6.0-1 ii libesd0 0.2.41-8 ii libglib2.0-02.32.3-1 ii libice6 2:1.0.8-2 ii libimlib2 1.4.5-1 ii libpango1.0-0 1.30.0-1 ii libsm6 2:1.2.1-2 ii libx11-62:1.5.0-1 ii libxcomposite1 1:0.4.3-2 ii libxdamage1 1:1.1.3-2 ii libxext62:1.3.1-2 ii libxfixes3 1:5.0-4 ii libxft2 2.3.1-1 ii libxinerama12:1.1.2-1 ii libxrandr2 2:1.3.2-2 ii libxrender1 1:0.9.7-1 ii libxxf86vm1 1:1.1.2-1 Versions of packages e16 recommends: pn esound none ii menu2.1.46 Versions of packages e16 suggests: pn e16keyedit none pn e16menuedit2 none ii kterm [x-terminal-emulator] 6.2.0-46 ii xterm [x-terminal-emulator] 278-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675940: fglrx-driver: fglrx crashes with X server 1.12 on 64bit architecture
According to the ati.cchtml.com bug, this is actually a problem with libpciaccess not handling 64-bit pointers correctly in some cases. The patch available there is a patch for libpciaccess, described by its author as an ugly hack (on which I agree, as it seems to be hardware-specific to some degree). As such, shouldn't this bug be redirected to the libpciaccess0 package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675940: fglrx-driver: fglrx crashes with X server 1.12 on 64bit architecture
On 07/18/2012 01:19 PM, Andreas Beckmann wrote: On 2012-07-16 15:50, The Wanderer wrote: According to the ati.cchtml.com bug, this is actually a problem with libpciaccess not handling 64-bit pointers correctly in some cases. The patch No. libpciaccess gets passed incorrect 64bit pointers. Ah. Then I misunderstood the explanation from that bug. available there is a patch for libpciaccess, described by its author as an ugly hack (on which I agree, as it seems to be hardware-specific to some degree). The binary blobs are passing invalid pointers, the blobs can't be patched, only the receiving side can be patched to work around the invalid input data. Acknowledged. Suggestion withdrawn. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645625: [Pkg-fglrx-devel] Bug#645625: fglrx-driver: hangs on startx, using X.Org Foundation libglx.so
On 10/17/2011 09:44 AM, Andreas Beckmann wrote: Please send the output of update-alternatives --display glx find /usr/lib/xorg/modules /usr/lib/fglrx -ls wanderer@aqualung:~$ update-alternatives --display glx glx - auto mode link currently points to /usr/lib/fglrx /usr/lib/fglrx - priority 99 slave glx--fglrx_drv.so: /usr/lib/fglrx/fglrx_drv.so slave glx--libGL.so.1-x86_64-linux-gnu: /usr/lib/x86_64-linux-gnu/fglrx/libGL.so.1 slave glx--linux-libglx.so: /usr/lib/fglrx/fglrx-libglx.so /usr/lib/mesa-diverted - priority 5 slave glx--libGL.so.1-x86_64-linux-gnu: /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 Current 'best' version is '/usr/lib/fglrx'. wanderer@aqualung:~$ find /usr/lib/xorg/modules /usr/lib/fglrx -ls 54067534 drwxr-xr-x 7 root root 4096 Oct 13 22:04 /usr/lib/xorg/modules 5406834 6068 -rw-r--r-- 1 root root 6200664 Oct 5 15:11 /usr/lib/xorg/modules/glesx.so 5407650 148 -rw-r--r-- 1 root root 144768 Aug 24 04:55 /usr/lib/xorg/modules/libint10.so 5407630 28 -rw-r--r-- 1 root root27456 Aug 24 04:55 /usr/lib/xorg/modules/libshadow.so 5407537 148 -rw-r--r-- 1 root root 144328 Aug 24 04:55 /usr/lib/xorg/modules/libfb.so 54067894 drwxr-xr-x 2 root root 4096 Oct 13 22:25 /usr/lib/xorg/modules/drivers 5407064 32 -rw-r--r-- 1 root root28776 May 1 11:47 /usr/lib/xorg/modules/drivers/cirrus_laguna.so 5406747 60 -rw-r--r-- 1 root root53736 May 1 12:25 /usr/lib/xorg/modules/drivers/tseng_drv.so 5406856 148 -rw-r--r-- 1 root root 147048 May 1 12:20 /usr/lib/xorg/modules/drivers/savage_drv.so 5406843 152 -rw-r--r-- 1 root root 147840 May 1 11:45 /usr/lib/xorg/modules/drivers/chips_drv.so 5406799 80 -rw-r--r-- 1 root root74824 May 1 12:22 /usr/lib/xorg/modules/drivers/sisusb_drv.so 5406804 16 -rw-r--r-- 1 root root15608 May 1 11:47 /usr/lib/xorg/modules/drivers/cirrus_drv.so 5406875 68 -rw-r--r-- 1 root root62448 May 1 12:16 /usr/lib/xorg/modules/drivers/s3_drv.so 5406965 84 -rw-r--r-- 1 root root78400 May 1 12:17 /usr/lib/xorg/modules/drivers/s3virge_drv.so 5406912 140 -rw-r--r-- 1 root root 135400 May 1 11:38 /usr/lib/xorg/modules/drivers/apm_drv.so 5407021 28 -rw-r--r-- 1 root root28504 May 1 12:32 /usr/lib/xorg/modules/drivers/voodoo_drv.so 5406840 168 -rw-r--r-- 1 root root 164576 May 1 12:26 /usr/lib/xorg/modules/drivers/trident_drv.so 5406776 20 -rw-r--r-- 1 root root20232 May 1 11:43 /usr/lib/xorg/modules/drivers/ark_drv.so 5406986 64 -rw-r--r-- 1 root root58376 May 1 11:55 /usr/lib/xorg/modules/drivers/i128_drv.so 5406901 1092 -rw-r--r-- 1 root root 1114104 May 26 06:04 /usr/lib/xorg/modules/drivers/radeon_drv.so 5406807 24 -rw-r--r-- 1 root root22184 May 1 11:50 /usr/lib/xorg/modules/drivers/fbdev_drv.so 5406788 572 -rw-r--r-- 1 root root 578632 May 1 12:23 /usr/lib/xorg/modules/drivers/sis_drv.so 5406809 196 -rw-r--r-- 1 root root 194000 May 3 11:15 /usr/lib/xorg/modules/drivers/mach64_drv.so 54067380 lrwxrwxrwx 1 root root 35 Oct 13 22:25 /usr/lib/xorg/modules/drivers/fglrx_drv.so - /etc/alternatives/glx--fglrx_drv.so 54069108 -rw-r--r-- 1 root root 6784 May 1 12:29 /usr/lib/xorg/modules/drivers/vmware_drv.so 5406726 124 -rw-r--r-- 1 root root 120104 May 1 12:19 /usr/lib/xorg/modules/drivers/siliconmotion_drv.so 5406806 36 -rw-r--r-- 1 root root36712 May 1 11:47 /usr/lib/xorg/modules/drivers/cirrus_alpine.so 5407061 324 -rw-r--r-- 1 root root 324896 May 14 13:02 /usr/lib/xorg/modules/drivers/intel_drv.so 5406935 356 -rw-r--r-- 1 root root 359944 May 4 16:46 /usr/lib/xorg/modules/drivers/openchrome_drv.so 5406900 76 -rw-r--r-- 1 root root73056 May 1 12:01 /usr/lib/xorg/modules/drivers/neomagic_drv.so 5406792 76 -rw-r--r-- 1 root root71064 May 1 12:23 /usr/lib/xorg/modules/drivers/tdfx_drv.so 5406913 60 -rw-r--r-- 1 root root53560 May 1 12:29 /usr/lib/xorg/modules/drivers/vmwlegacy_drv.so 5406885 116 -rw-r--r-- 1 root root 111616 May 1 12:08 /usr/lib/xorg/modules/drivers/r128_drv.so 54068278 -rw-r--r-- 1 root root 6808 May 26 06:04 /usr/lib/xorg/modules/drivers/ati_drv.so 5406953 28 -rw-r--r-- 1 root root26408 Jun 15 09:00 /usr/lib/xorg/modules/drivers/vesa_drv.so 5407069 20 -rw-r--r-- 1 root root17824 Aug 24 04:55 /usr/lib/xorg/modules/libfbdevhw.so 54067794 drwxr-xr-x 2 root root 4096 Oct 13 22:25 /usr/lib/xorg/modules/linux 5407075 64 -rw-r--r-- 1 root root58400 Oct 5 15:11 /usr/lib/xorg/modules/linux/libfglrxdrm.so 54067430 lrwxrwxrwx 1
Bug#645650: kdrill: increase maximum search results
Package: kdrill Version: 6.5deb2-4 Severity: wishlist Dear Maintainer, The search component of kdrill imposes a hard limit of 200 results to all kanji searches, and provides no way to get at any results beyond that limit. I have routinely needed to be able to look through all results, well past that limit. I am therefore running with the attached simple one-line patch, which raises the limit to 1000. I have not noticed any significant increase in e.g. memory requirements as a result. Please either apply a patch such as this one, or provide some more sophisticated means of raising the limit (e.g. a run-time option, such as in a config file). Note that a few searches can still return more results than will be displayed at once even with the limit set to 1000, but not enough to cause problems in my ordinary usage. Raising the limit slightly further would probably eliminate those cases as well, at least until the dictionaries being used grow far enough to press that new limit. Aside from raising the limit well beyond the maximum which will be needed anytime soon, I don't see any good simple solution to that. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash kdrill depends on no packages. Versions of packages kdrill recommends: ii kanadic 6.5deb2-4 ii kanjidic 2011.05.25-1 ii xfonts-base 1:1.0.3 Versions of packages kdrill suggests: ii edict 2011.05.25-1 ii xjdic 24-7 -- no debconf information -- debsums errors found: debsums: no md5sums for kdrill diff -Naur kdrill6.5-old//multikanji.c kdrill6.5//multikanji.c --- kdrill6.5-old//multikanji.c 2011-07-16 20:14:07.587370542 -0400 +++ kdrill6.5//multikanji.c 2011-07-16 20:16:48.871473678 -0400 @@ -53,7 +53,7 @@ /* MAXMULTI == max translation lines we will hold in multi-window */ /* If external routine wants to know this value, call getMultiMax() */ -#define MAXMULTI 200 +#define MAXMULTI 1000
Bug#645625: [Pkg-fglrx-devel] Bug#645625: fglrx-driver: hangs on startx, using X.Org Foundation libglx.so
On 10/17/2011 12:26 PM, Andreas Beckmann wrote: Hi, where does this in your xorg.conf come from? Section Files ModulePath /usr/lib/xorg/modules/extensions ModulePath /usr/lib/xorg/modules EndSection I don't know offhand where it came from; either it was added automatically by an fglrx installer which generated an xorg.conf file (before fglrx was properly packaged), or I added it by hand during my initial system setup because it was actually necessary at that point. Delete that block and move everything back to its original location. That should fix your issue. Yes, that gets me into X with functioning GLX, albeit with possibly lower performance; I seem to recall getting ~6400 FPS from glxgears under the manual-symlink solution, and now I'm getting only ~3000-~3200. That could be a coincidence, though; if I see perceptibly worse performance in software where it actually matters, I'll try to revert to the manual-symlink configuration and test. I don't think you need to do the debugging I described here: I would think probably not, no. I could switch back to the problematic config and do it if you want, but it doesn't seem necessary. 54068610 lrwxrwxrwx 1 root root 30 Oct 13 23:31 /usr/lib/xorg/modules/extensions/libglx.so - /usr/lib/fglrx/fglrx-libglx.so If you delete the link - does it work? It should pick up linux/libglx.so With the existing xorg.conf, no, it does not. With the Files section commented out, yes, it does. Thanks for the quick solution! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684538: libgl1-fglrx-glx: multiarch fglrx_dri no longer functional
On further investigation, this appears to be due to the fact that the /usr/lib32/libGL.so.1 symlink (from the ia32-libs package) was still in place, pointing to the non-fglrx libGL. After moving /usr/lib32/libGL* out of the way, the /usr/lib/i386-linux-gnu/ versions are picked up correctly, and 32-bit direct rendering works again. That's not a really satisfactory solution, but since uninstalling ia32-libs isn't really an option until I can be certain that any of the 32-bit libraries it used to provide will be available via multiarch packages, it's about the best that can probably be done for the time being. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684538: libgl1-fglrx-glx: multiarch fglrx_dri no longer functional
After having moved /usr/lib32/libGL* out of the way to fix 32-bit direct rendering, 32-bit Wine no longer compiles with OpenGL support, since it cannot find libGL.so. This appears to be because the /usr/lib/i386-linux-gnu/libGL.so symlink does not exist. (Nor, for that matter, do some of the analogues to the other libGL* symlinks which existed in /usr/lib32/.) After creating those missing symlinks, both sides of the equation are functional. I do not know why the symlinks did not exist. It seems possible that the package might have skipped creating them because matching symlinks already existed in another part of the system (e.g. as part of the alternatives system), though if so that's probably not the best behavior. Regardless, it seems possible that this problem could be avoided entirely by A: creating the missing /usr/lib/i386-linux/gnu/libGL* symlinks when installing the appropriate package, and B: moving /usr/lib/i386-linux-gnu/ ahead of /usr/lib32/ in ld.so.conf except that as far as I can tell, B: has already been done on my system, but the /usr/lib32/ version of libGL was still picked up before the /usr/lib/i386-linux-gnu/ version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684538: libgl1-fglrx-glx: multiarch fglrx_dri no longer functional
Source: libgl1-fglrx-glx
Severity: important
Since transitioning from fglrx-glx and fglrx-glx-ia32 to
libgl1-fglrx-glx:{amd64,i386}, I am no longer able to get OpenGL direct
rendering in 32-bit programs. The example which primarily concerns me is
32-bit Wine in a 32-and-64-bit side-by-side configuration, as
recommended on the Wine wiki; however, the problem has also been
observed with glxinfo:i386.
(The practical effect of no direct rendering on at least some programs
run under Wine is that they produce no visible output at all, outside of
the console, and that when run in fullscreen they appear to freeze the
system. Switching to a terminal or to console and taking down the Wine'd
EXE with e.g. pkill is enough to bring the system back, but it's still
not a good behavior.)
Judging from the comparative verbose debug output of both versions of
glxinfo, I suspect (though I am by no means certain) that the problem is
that the 32-bit version of fglrx_dri.so is no longer visible to the
programs involved. It does exist in /usr/lib/i386-linux-gnu/dri/, but
the symlink from /usr/lib/dri/ points to the amd64 version of the file.
I have both verbose-debug and non-debug output from both 32-bit and
64-bit versions of glxinfo, in case that would help. I have not been
able to extract any useful information out of the logs myself, except
that it doesn't look like the 32-bit version is even *trying* to open
fglrx_dri.so - just swrast_dri.so, which isn't there. (And putting it
there doesn't help.)
I have tried a number of things to get this to work, including moving
and/or symlinking files into places where they seem to be missing by
hand, but none of it has had much salutary effect.
Note that I ordinarily track testing, but updated my APT sources to sid
temporarily in order to install the new Xorg 1.12-compatible fglrx (and
its related packages); that is when I started having these problems.
Most of my system is still on testing, and I'd prefer to keep as much
of it that way as possible.
I would be quite willing to downgrade to older fglrx (and xorg) if
appropriate in order to avoid this problem until a proper fix can be
found, but I have not been able to find any workable way of doing that.
-- Package-specific info:
Full fglrx package list:
ii fglrx-atievent 1:12-6+point-1 external events daemon for the non-free ATI/
ii fglrx-control 1:12-6+point-1 control panel for the non-free ATI/AMD Radeo
ii fglrx-driver 1:12-6+point-1 non-free ATI/AMD RadeonHD display driver
ii fglrx-glx 1:12-6+point-1 transitional package, use libgl1-fglrx-glx
ii fglrx-modules- 1:12-6+point-1 dkms module source for the non-free ATI/AMD
ii libfglrx:amd64 1:12-6+point-1 non-free ATI/AMD RadeonHD display driver (ru
ii libfglrx:i386 1:12-6+point-1 non-free ATI/AMD RadeonHD display driver (ru
ii libfglrx-amdxv 1:12-6+point-1 AMD XvBA (X-Video Bitstream Acceleration) ru
ii libfglrx-amdxv 1:12-6+point-1 AMD XvBA (X-Video Bitstream Acceleration) ru
ii libgl1-fglrx-g 1:12-6+point-1 proprietary libGL for the non-free ATI/AMD R
ii libgl1-fglrx-g 1:12-6+point-1 proprietary libGL for the non-free ATI/AMD R
VGA-compatible devices on PCI bus:
03:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts XT
[Radeon HD 6800 Series]
DRM and fglrx Informations from dmesg:
[245456.136518] [fglrx] IRQ 79 Disabled
[245456.136864] [fglrx] APL: APL has not been initialized, unload database fail.
[245490.397120] [fglrx] module unloaded - fglrx 8.98.2 [Jul 19 2012]
[245493.014308] [fglrx] Maximum main memory to use for locked dma buffers: 23641
MBytes.
[245493.014446] [fglrx] vendor: 1002 device: 6738 count: 1
[245493.014844] [fglrx] ioport: bar 4, base 0xb000, size: 0x100
[245493.015102] [fglrx] Kernel PAT support is enabled
[245493.015117] [fglrx] module loaded - fglrx 8.98.2 [Jul 19 2012] with 1 minors
[245499.245742] fglrx_pci :03:00.0: irq 79 for MSI/MSI-X
[245499.247154] [fglrx] Firegl kernel thread PID: 19415
[245499.247442] [fglrx] Firegl kernel thread PID: 19416
[245499.247810] [fglrx] Firegl kernel thread PID: 19417
[245499.247990] [fglrx] IRQ 79 Enabled
[245499.484358] [fglrx] Gart USWC size:1280 M.
[245499.484360] [fglrx] Gart cacheable size:508 M.
[245499.484363] [fglrx] Reserved FB block: Shared offset:0, size:100
[245499.484365] [fglrx] Reserved FB block: Unshared offset:fbfd000, size:403000
[245499.484367] [fglrx] Reserved FB block: Unshared offset:3fff4000, size:c000
Xorg X server configuration file status:
-rw-r--r-- 1 root root 684 Mar 2 2011 /etc/X11/xorg.conf
Contents of /etc/X11/xorg.conf:
Section ServerLayout
Identifier aticonfig Layout
Screen 0 aticonfig-Screen[0]-0 0 0
EndSection
Section Module
EndSection
Section Monitor
Identifier aticonfig-Monitor[0]-0
Option VendorName ATI Proprietary Driver
Option ModelName Generic Autodetecting Monitor
Option DPMS true
EndSection
Section Device
Identifier
Bug#650238: libgcc1 (4.6.2-4) breaks gcc-4.3 4.3.6-1, but, there is no package for gcc-4.3(4.3.6-1)
Eh? How is this wishlist? The bug here is that it is possible, using only Debian-provided packages and the Debian dependencies system, to get the system into a state where it is not possible to compile modules for the currently-running kernel. That sounds like a pretty serious problem to me, and certainly not a wish-list item; I'd think it would break packages which need to compile modules for each install or upgrade of the package, e.g. dkms module packages. If the problem can't (yet) be fixed by updating the packages in question to actually work again, due to compile problems or whatever else, then it should at the very least be fixed by modifying dependencies so that the system will refuse to get into that state. (Honestly, I think it might be a good idea for each linux-image-* non-metapackage to at least Recommend the package for the compiler with which it was built. But that's not quite this same problem.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650238: libgcc1 (4.6.2-4) breaks gcc-4.3 4.3.6-1, but, there is no package for gcc-4.3(4.3.6-1)
And one point I forgot: it might be simple enough to fix this by recompiling the various linux-image-* packages with a newer GCC version, one which can still be obtained via Debian. However, as far as I can tell by looking at changelogs, that doesn't seem to have been done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711961: libglib2.0-0: causes iceweasel 3.5.18-1 to SIGABRT on launch
Package: libglib2.0-0 Version: 2.36.1-2build1 Severity: normal Dear Maintainer, I want to first note that I am intentionally using a configuration which may be unsupported. However, just in case the problem I am encountering might be relevant independent of that potentially unsupported configuration (and/or might get fixed anyway), I would like to report it regardless. I am running iceweasel version 3.5.18-1, which was the version available through the then Debian stable when I intentionally reverted to the 3.x series. I am working on resolving the issues which impede me from satisfactorily updating to a more modern version, but I am not there yet, and depending on other priorities may not get there any time soon. With libglib2.0-0 version 2.36.1-2build1 and its dependencies, this version of Iceweasel dies on launch with the following error: GLib-GObject:ERROR:/tmp/buildd/glib2.0-2.36.1/./gobject/gobject.c:4127:g_weak_ref_set: assertion failed: (weak_locations != NULL) I previously managed a GDB session which provided a backtrace indicating that the call chain for this this came through pango, but since then I've been unable to get the program to run in gdb to reproduce that backtrace. Given the lack of debugging information included, it's not clear that the backtrace would have helped anyway. After downgrading to libglib2.0-0 version 2.33.12+really2.32.4-5 and its dependencies from stable (including a number of libpango* downgrades and/or removals), this version of Iceweasel works fine. While this constitutes a regression, it is not clear whether that regression would only affect outdated software such as this or might potentially manifest for something more up-to-date. I'm reporting it on the possibility that it might be the latter, and so might get fixed; though I can hope, I do not really expect it to be fixed if it's the former. If this is sufficiently worth pursuing for further information to be desirable, please let me know what to provide. -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714820: ITP: ntopng -- High-Speed Web-based Traffic Analysis and Flow Collection Tool
On 07/03/2013 02:45 AM, Ludovico Cavedon wrote: Package: wnpp Severity: wishlist Owner: Ludovico Cavedon cave...@debian.org * Package name: ntopng Version : 1.0 Upstream Author : Luca Deri d...@ntop.org * URL : http://www.ntop.org/products/ntop/ * License : GPL-3 Programming Lang: C++ Description : High-Speed Web-based Traffic Analysis and Flow Collection Tool ntopng is the next generation version of the original ntop, a network traffic probe that shows the network usage, similar to what the popular top Unix command does. ntop is based on libpcap and it has been written in a portable way in order to virtually run on every Unix platform, MacOSX and on Win32 as well. Might I suggest a different package name, e.g. 'ntop-ng'? At a glance, 'ntopng' reads to me as N-to-PNG, along the lines of existing file-format converter programs. While it's not absolutely necessary to avoid that, if there's no real downside to doing so, it might be a good idea. I'm also not sure how good -ng-style names are in the first place, unless you are positive that there will never be a future next generation after this one; a name like ntop2 would be more forward-development-compatible in that light. But that's just my principles speaking, not a source of present confusion. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697423: dizzy: fullscreen display with '-f' fails on undefined subroutine, 'SDL::Mouse::show_cursor' at line 61
Package: dizzy Version: 0.3-1 Severity: normal Dear Maintainer, When I run dizzy with the fullscreen option, '-f', it does not work. The screen flashes blank for a fraction of a second, and the line Undefined subroutine SDL::Mouse::show_cursor called at /usr/games/dizzy line 61. is printed to the console. If I add the line use SDL::Mouse; to the end of the SDL use section at the head of the file, the problem disappears, and full-screen mode works properly. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dizzy depends on: ii libconvert-color-perl 0.08-1 ii libopengl-perl 0.66+dfsg-1 ii libsdl-perl2.540-1 ii perl 5.14.2-15 dizzy recommends no packages. dizzy suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705293: manpages-dev: access(2) does not document return-value behavior for F_OK
Package: manpages-dev Version: 3.44-1 Severity: normal Dear Maintainer, The man page for the 'access' function describes two ways to use the function: to check whether the current real user ID has specific permissions for a file (R_OK, W_OK, X_OK), or to check whether that file simply exists (F_OK). The Return Value section of the man page, however, appears to be written exclusively in the context of the check permissions modes. It documents a value of zero as meaning success (all requested permissions granted), but does not describe the meanings of return values when checking only for existence rather than attempting to check any permissions. A usage example near the bottom of what appears to be the z/OS man page for the same function http://publib.boulder.ibm.com/infocenter/zos/v1r11/topic/com.ibm.zos.r11.bpxbd00/rtacc.htm seems to indicate that in the check existence mode, a return value of zero indicates that the file exists, and nonzero indicates that the file does not exist; however, even in that version of the man page, the Returned Value section appears to be written exclusively in the context of the check permissions modes. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages manpages-dev depends on: ii manpages 3.44-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.6.2-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#455769: same problem on wheezy + Thinkpad X220T
On 03/28/2013 07:32 AM, Wouter Verhelst wrote: (on a more personal note, why oh why would you ever want the system to suspend when you close the lid? That's what a suspend button is for. If my laptop is compiling something, I do *not* want it to suspend when I close the lid, thankyouverymuch. Oh well) If nothing else, for symmetry. If a laptop will wake up from suspend when you open the lid (which mine at least will), having it go to sleep when you close it would be an intuitive behavior. For some people, having that intuitive symmetry broken produces enough mental dissonance that they are more comfortable with it present, even at the cost you describe. It's also a matter of convenience; if you *do* want to both suspend and close the lid in a particular case, with suspend-on-lid-close you can get the job done with just one action, but with suspend-only-on-button-press you have to take two. You pay for that convenience by sacrificing the convenience of being able to close the lid *without* suspending, but which inconvenience is the greater depends on your usage patterns, and different people may well prefer to sacrifice different ones. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On 12/10/2012 04:59 PM, Jonas Smedegaard wrote: Quoting The Wanderer (2012-12-10 17:57:18) On 12/10/2012 11:21 AM, Jonas Smedegaard wrote: Check the meanings with aptitude --help. On my system, the text output from that command does not include the string 'dist': True. Look at the *upgrade commands. (In hindsight, from what I found in the man page, I should have thought of that myself.) wanderer@apologia$ aptitude --help | grep -i upgr install - Install/upgrade packages. forbid-version - Forbid aptitude from upgrading to a specific package version. update - Download lists of new/upgradable packages. safe-upgrade - Perform a safe upgrade. full-upgrade - Perform an upgrade, possibly installing and removing packages. wanderer@apologia$ That's a reduced and less directly informative version of what's present in the man page, and again, nothing there seems to imply what you described the purpose of dist-upgrade (renamed to full-upgrade) to be. Yes, dist-upgrade can install new packages and remove installed ones; that's sometimes necessary in order to satisfy changing dependencies, e.g. when a program adds a new feature which depends on a new library, or when package names change to reflect new versions. That doesn't say anything about relaxed dependency handling - or, more to the point, more aggressive solutions - as I understand those terms, though. Oh, and if you used apt-get, then don't. Use aptitude! I'd rather not, thanks. I'm told that it's not a good idea to mix-and-match between aptitude and apt-get, and I find the aptitude UI to be palpably less friendly and manageable in most circumstances than that of apt-get. I'm aware that I'm a minority in this, but that doesn't change anything. You are not a minority: Many have been mislead. I meant a minority in the less friendly and manageable opinion. Feel free to use an inferior tool. I disagree that apt-get is inferior. It may not provide as broad a feature set (though I can't swear to that), but IMO as a functional tool it is just as good or better for most purposes. (Or at least for my purposes.) But note that aptitude is the tool recommended for upgrading from one release to the next (nowadays, if it has ever been recommended to use apt-get). I've long been aware that aptitude is by far the more commonly recommended tool of the two, at least for new users; I've had the impression that that recommendation extends to all purposes, not just to cross-release upgrades. As Felipe points out, however, section 4.4 of the wheezy release notes now explicitly states that apt-get is recommended over aptitude for cross-release upgrades. While I'd be interested to continue the discussion of aptitude vs. apt-get, it's certainly offtopic for this bug. As such, I do not (presently) intend to reply to any further posts on this bug on that subject, unless they appear to be going back in the direction of trying to resolve the reported problem. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On 12/11/2012 08:32 AM, The Wanderer wrote: While I'd be interested to continue the discussion of aptitude vs. apt-get, it's certainly offtopic for this bug. As such, I do not (presently) intend to reply to any further posts on this bug on that subject, unless they appear to be going back in the direction of trying to resolve the reported problem. And since I didn't say it explicitly before: although I do think the bug report is legitimate, I'm willing enough at this point to fix my own package-install situation manually and proceed from there, if no one has any further suggestions for how to proceed. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On 12/11/2012 08:56 AM, Fabian Greffrath wrote: Am 11.12.2012 14:44, schrieb The Wanderer: And since I didn't say it explicitly before: although I do think the bug report is legitimate, I'm willing enough at this point to fix my own package-install situation manually and proceed from there, if no one has any further suggestions for how to proceed. You could try aptitude why libjack-jackd2-0 to find out what caused the installation of that package and thus the removal of libjack0. Unfortunately, that just reports p libjack-jackd2-dev Provides libjack-dev p libjack-jackd2-dev Depends libjack-jackd2-0 (= 1.9.8~dfsg.4+20120529git007c dc37-4.1) which doesn't tell me anything I didn't already know. I played around with why and why-not for a few other packages as well, but didn't succeed in tracking anything down. (I wasn't aware of these commands, and I think they may be useful for future reference.) It seems possible that this might change if I actually go through with the remove libjack0 and libjack-dev dist-upgrade, so that the jackd2 packages are actually installed (and the jackd1 packages are not) - but so far I haven't done that, and I'm not sure I'd like to. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On 12/14/2012 05:59 PM, Felipe Sateler wrote: On Tue, Dec 11, 2012 at 11:17 AM, The Wanderer wande...@fastmail.fm wrote: On 12/11/2012 08:56 AM, Fabian Greffrath wrote: You could try aptitude why libjack-jackd2-0 to find out what caused the installation of that package and thus the removal of libjack0. Unfortunately, that just reports p libjack-jackd2-dev Provides libjack-dev p libjack-jackd2-dev Depends libjack-jackd2-0 (= 1.9.8~dfsg.4+20120529git007c dc37-4.1) which doesn't tell me anything I didn't already know. I played around with why and why-not for a few other packages as well, but didn't succeed in tracking anything down. (I wasn't aware of these commands, and I think they may be useful for future reference.) It seems possible that this might change if I actually go through with the remove libjack0 and libjack-dev dist-upgrade, so that the jackd2 packages are actually installed (and the jackd1 packages are not) - but so far I haven't done that, and I'm not sure I'd like to. I tried to reproduce this on a clean chroot: 1. Create squeeze chroot 2. Install libjack-dev, jackd and jack1 3. install ia32-libs 4. Add wheezy to sources.list 5. Upgrade apt and dpkg (needed for multiarch) 6. Add i386 foreign architecture in dpkg and apt-get update again 7. apt-get dist-upgrade This caused a lot of installs (including a :i386 flurry), but libjack-dev was not removed, and libjack-jack2-0 was not installed. Well, I have encountered the same problem on a second system (a laptop, configured similarly although not identically to the original report's desktop machine), so at least it's not a pure one-off situation. I don't have any further ideas about how to track down the cause, however, and although I do have a squeeze-based VM explicitly for testing things related to Debian I'm not likely to have time to experiment much with this anytime soon. For the time being, I've gone ahead and dodged around the problem (on one of the two affected systems) by dist-upgrading with jackd1 and libjack-dev held. Whether there will be problems with future dist-upgrades I don't know. FWIW, I've checked the dependencies of every package in that dist-upgrade via 'apt-cache show', and the only references to jack are in the package description (not the actual dependencies) of vlc-nox. The only packages not modified in that dist-upgrade which would be modified in one without those two holds are the four which would be removed and the four which would be installed: jackd1, jackd1-firewire, libjack-dev, and libjack0 on the one hand, and jackd2, jackd2-firewire, libjack-jackd2-0, and libjack-jackd2-0:i386 on the other. If you want to close this as unreproducible or similar, I wouldn't actively object. It might be worth keeping it open as a low priority just in case something does get discovered, or for discoverability in case someone else has the same problem, but I'm not in a position to make that judgment. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696060: mtr: StDev overflowed to negative
Package: mtr Version: 0.82-3 Severity: minor Dear Maintainer, As part of an effort to diagnose - and later to confirm the fix of - an ongoing network problem, I have maintained an mtr session running for several weeks straight. The current overall summary for one hop in that session presently reads as follows: HostnameLoss Rcv Snt Last Best Avg Worst StDev 73.223.7.1 0.3% 4028069 4039341 687 12 60593 -2147483.75 The standard deviation value is negative, which is meaningless AFAIK, and therefore should not be possible. The specific negative value in question looks at a glance like the result of an overflow. I am not clear on exactly what it would take to reproduce this problem. Presumably, unreasonably high worst-case ping times in what is otherwise a normal network environment would be at least a contributing factor. However, I am relatively certain that I recall past sessions where this hop has shown a Worst value of over 7 milliseconds, but the StDev value has remained positive; as such, I am not sure whether that would be sufficient. This bug is of course extremely minor, as even if it does occur reproducibly, the circumstances for it are rare and it is unlikely to have more than a cosmetic effect even when it does occur. However, as it is still a bug, I felt it worth reporting anyway. If there is anything I can do to help to track this down, please don't hesitate to let me know. -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mtr depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-3 ii libgtk2.0-0 2.24.10-2 ii libncurses5 5.9-10 ii libpango1.0-0 1.30.0-1 ii libtinfo5 5.9-10 mtr recommends no packages. mtr suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696060: mtr: StDev overflowed to negative
On 12/16/2012 10:44 AM, Rogier Wolff wrote: Hi, The variance, which is used to calculate the stdev, is stored in a 64-bit integer. However, what we store there are the squares of the difference from the average. So if you have 70 second ping time (sometimes), the square of 7 miliseconds becomes 4900 million! Quite a lot, but unlikely to overflow a 64-bit value However the calculation is done in microseconds Thus your 70 seconds is 70 million microseocnds, giving 4900 trillion (4.9 * 10^15) added to the running total every second or so, (as long as the average remains around zero). This can overflow a 64-bit variable in human-observable time. The case at hand was only about 6 milliseconds, but yes, that would explain the problem. The fact that I've seen 7-millisecond Worst times without seeing this problem would then be explained by the fact that those sessions didn't last this long; IIRC they were about two weeks at most, and this one is over six. I've modified the code to do the calculations in miliseconds from now on. This should buy us a factor of a million of margin. :-) Not a 100% fix in theory, but it should hide the problem for pretty much any case that's actually reasonable to support. Sounds good to me; thanks for the prompt response! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695594: xserver-xorg-video-radeon: X segfaults when entering OpenGL mode in Minecraft
On 12/11/2012 04:58 AM, Michel Dänzer wrote: Note that this crash means minecraft is using indirect rendering, which is undesirable for a local display. Are you intentionally using indirect rendering? If not, the output of LIBGL_DEBUG=verbose glxinfo | grep render might give hints as to why you're not getting direct rendering. That was enough for me to track it down, albeit only with about four separate searches of the entire root partition for one string or another. It turns out to be because an earlier install of the FGLRX driver - I think from before there was an officially distributed Debian package for it - had modified /etc/profile to call /etc/ati/ati-fglrx.sh, which in turn would set LIBGL_DRIVERS_PATH to something like '/usr/lib/dri:/usr/lib32/dri:/usr/lib64/dri' if the path was not already set. After commenting out that line from /etc/profile, and rebooting to be sure it was cleared from the environment, the crash no longer occurs. I plan to also clear out the other remnants of that old fglrx install when I have time. Since Debian doesn't appear to set LIBGL_DRIVERS_PATH by default, but also doesnt place the architecture-native DRI drivers (in this case, r600_dri.so) in any of those three locations, they weren't being found. That led to fallback to indirect rendering mode, which apparently led to the crash. It's not good to crash when using indirect rendering, of course, and I'd be willing to conduct tests to help track that crash down if desired - but at least the direct-rendering mode does appear to work properly. (Though I'd like to know why, judging from the output of glxgears, I seem to get enforced vsync with radeon but didn't with fglrx... but that's not really related to this bug.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696363: devscripts: Repeated-word typo in wrap-and-sort man page
Package: devscripts Version: 2.12.6 Severity: minor In the man page for wrap-and-sort, the entry for the '--wrap-always' option reads: Wrap all package lists in the Debian control file even if the entries are shorter than 80 characters and could fit in one line line. The word line appears twice at the end of the sentence. In an 80-column terminal, this sentence is line-wrapped in between the repeated words, making this easy to overlook; however, in a larger terminal the error is more visible. -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- Not present -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages devscripts depends on: ii dpkg-dev 1.16.9 ii libc6 2.13-35 ii perl 5.14.2-15 ii python2.7.3~rc2-1 Versions of packages devscripts recommends: ii at3.1.13-2 ii curl 7.26.0-1 ii dctrl-tools 2.22.2 ii debian-keyring2012.06.01 ii dput 0.9.6.3+nmu1 ii equivs2.0.9 ii fakeroot 1.18.4-2 ii gnupg 1.4.12-6 ii libcrypt-ssleay-perl 0.58-1 ii libdistro-info-perl 0.10 ii libjson-perl 2.53-1 ii libparse-debcontrol-perl 2.005-3 ii libsoap-lite-perl 0.714-1 ii liburi-perl 1.60-1 ii libwww-perl 6.04-1 ii lintian 2.5.10.2 ii man-db2.6.2-1 ii patch 2.6.1-3 ii patchutils0.3.2-1.1 ii python-debian 0.1.21 ii python-magic 5.11-2 ii sensible-utils0.0.7 ii strace4.5.20-2.3 ii unzip 6.0-7 ii wdiff 1.1.2-1 ii wget 1.13.4-3 ii xz-utils 5.1.1alpha+20120614-1 Versions of packages devscripts suggests: ii bsd-mailx [mailx]8.1.2-0.2006cvs-1 ii build-essential 11.5 ii cvs-buildpackage 5.23 pn devscripts-elnone ii gnuplot 4.6.0-8 pn libauthen-sasl-perl none ii libfile-desktopentry-perl0.04-3 pn libnet-smtp-ssl-perl none pn libterm-size-perlnone ii libtimedate-perl 1.2000-1 pn libyaml-syck-perlnone ii mutt 1.5.21-6.2 ii openssh-client [ssh-client] 1:6.0p1-3 ii svn-buildpackage 0.8.5 ii w3m 0.5.3-8 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
Package: libjack-dev Version: 1:0.121.3+20120418git75e3e20b-2.1 Severity: normal Dear Maintainer, When I attempt to dist-upgrade to current testing, apt wants to remove libjack0 and install libjack-jackd2-0. This is fine; the latter explicitly Provides: the same virtual package as the former, so presumably this is part of an intended package transition. As part of the same dist-upgrade, apt wants to remove libjack-dev, but does not attempt to install libjack-jackd2-dev. This is not fine. Please modify package dependencies so that a dist-upgrade on a system where libjack-dev is installed will correctly transition to libjack-jackd2-dev. Alternately, if this transition would in fact not be correct, please explain to me what the correct procedure - even if a manual one - would be. (I suspect that this bug will actually have to be fixed in libjack-jackd2-dev, but I am reporting it against libjack-dev to make reportbug happy, as that is the package I currently have installed.) -- System Information: Debian Release: wheezy/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libjack-dev depends on: ii libjack01:0.121.3+20120418git75e3e20b-2.1 ii pkg-config 0.26-1 libjack-dev recommends no packages. libjack-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On 12/10/2012 06:08 AM, Jonas Smedegaard wrote: Hi, Quoting The Wanderer (2012-12-10 02:25:21) When I attempt to dist-upgrade to current testing, apt wants to remove libjack0 and install libjack-jackd2-0. This is fine; the latter explicitly Provides: the same virtual package as the former, so presumably this is part of an intended package transition. As part of the same dist-upgrade, apt wants to remove libjack-dev, but does not attempt to install libjack-jackd2-dev. This is not fine. Please modify package dependencies so that a dist-upgrade on a system where libjack-dev is installed will correctly transition to libjack-jackd2-dev. No, because this is not a transition, but two different APIs that (mostly) share same ABI. Which means some packages works fine with either of the JACK libraries but some require the jackd2 one - which then pushes the other out, including the -dev package. By pushes the other out, I infer that you mean causes the other to become uninstalled. (At first glance, I would have expected that phrasing to mean pushes the other onto the system, i.e. causes the other to become installed, which is the opposite of what is actually happening.) Just to clarify: is JACK v2 strictly a superset of JACK v1 in terms of API and presumably ABI? Or are there parts of the JACK v1 API which JACK v2 does not provide? If the former, then I would be inclined to consider this a strict transition/upgrade situation. If the latter, then I find your comment below about the JACK v2 extensions to the ABI/API to be confusing, in that I understand extensions to be simply additions on top of what was already present - as opposed to incompatible modifications. Alternately, if this transition would in fact not be correct, please explain to me what the correct procedure - even if a manual one - would be. If you want to develop JACK v1 then avoid installing packages that depend on the JACK v2 extensions to the ABI/API. Actually, what I want to be able to do is to compile programs which use the JACK libraries. (To me, develop JACK would mean modify the code of JACK itself.) The bug, IMO, is that the dist-upgrade takes me from a situation where this is possible (because the appropriate library and its -dev package are installed) to one where it is not (because although the appropriate library is installed, its -dev package is not). This can be fixed easily enough by manually installing the new matching -dev package, but IMO the fact that that package does not get installed automatically when the older -dev package was already present is a problem. The removal of libjack0 and libjack-dev would prevent me from compiling programs which depend on that API in any case. Assuming it's not possible (or at least not practical) to arrange for both libraries and their headers to be installed side-by-side, which your comments seem to indicate is true, this seems unavoidable. Continuing to provide the matching -dev package would at least let me continue to work with programs which *do* know how to work with either API. Admittedly it would also seem to imply that the APIs provided by the two -dev packages are compatible, which if not accurate is undesirable, but I'm not sure that that's worse than the alternative. I believe there is no bug here - but am not sure, so please do not give up just yet :-) (Thank you for the attitude; I've had far too many hostile or abrupt responses to bug reports which the maintainers considered dubious or invalid. It's nice to get a helpful one instead.) To be clear, I'm not saying there's a functionality problem here. The problem I see is one of user-friendliness and discoverability. It took me several days and a chance comment from someone on debian-user to figure out that there even *was* a replacement -dev package. At first, I had thought that the -dev package simply hadn't been updated to match the newer library package (and the newer binary packages, jackd2 et al.), so I was waiting for an updated version to appear in testing which would not require me to remove the -dev package in order to dist-upgrade; the thought that it might already have been updated, but simply wasn't being installed as part of the dist-upgrade, didn't even occur to me. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On 12/10/2012 10:08 AM, Jonas Smedegaard wrote: Quoting The Wanderer (2012-12-10 14:41:51) Just to clarify: is JACK v2 strictly a superset of JACK v1 in terms of API and presumably ABI? Or are there parts of the JACK v1 API which JACK v2 does not provide? If the former, then I would be inclined to consider this a strict transition/upgrade situation. If the latter, then I find your comment below about the JACK v2 extensions to the ABI/API to be confusing, in that I understand extensions to be simply additions on top of what was already present - as opposed to incompatible modifications. Ahem, sorry: Please forget about JACK v2. That is the wrong name (my fault!) , and confuses matters! There are multiple implementations of JACK, and one of those implementations happen to have a 2 in its name. Ah. In that case (and based on a few other things which I've snipped), the question becomes why the dist-upgrade is trying to remove libjack0. libjack-jackd2-0 conflicts with libjack0, and jackd2 depends on libjack-jackd2-0, so that part is obvious. I've tried to trace dependencies, but I haven't been able to figure out what is causing the dist-upgrade to try to install jackd2. I can prevent dist-upgrade from attempting the removal by holding libjack-dev and jackd1, but that doesn't explain why the attempt was happening in the first place. (No other packages get held back as a result of that hold.) At first, I had thought that the -dev package simply hadn't been updated to match the newer library package (and the newer binary packages, jackd2 et al.), so I was waiting for an updated version to appear in testing which would not require me to remove the -dev package in order to dist-upgrade; the thought that it might already have been updated, but simply wasn't being installed as part of the dist-upgrade, didn't even occur to me. When you have development tools installed, you will not experience as smooth an upgrade as when you do not. That seems less than entirely desirable, but if that's the design intent of the package system, then fair enough. The purpose of dist-upgrade (as opposed to upgrade) is to relax dependency handling to permit more aggressive solutions to the complex puzzle of package relation conflicts. I thought the purpose of dist-upgrade, as opposed to upgrade, was simply to allow upgrades across scenarios where dependency changes require installation of different packages rather than simply of new versions of the same packages. P.S. Skipping parts of your email does not mean that I find it silly or irrelevant, just that I had no comment on it. We are multiple package developers, and I leave your qustions hanging for others to hopefully contribute too. Oh, of course; it didn't even occur to me to potentially be offended. I understand about snipping quite well, even if I don't do it as much as I possibly should myself. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
(Apologies to Felipe for the duplicate reply; I didn't notice until after sending that the To: didn't include the bug address.) On 12/10/2012 10:15 AM, Felipe Sateler wrote: On Sun, Dec 9, 2012 at 10:25 PM, The Wanderer wande...@fastmail.fm wrote: Package: libjack-dev Version: 1:0.121.3+20120418git75e3e20b-2.1 Severity: normal Dear Maintainer, When I attempt to dist-upgrade to current testing, apt wants to remove libjack0 and install libjack-jackd2-0. This is fine; the latter explicitly Provides: the same virtual package as the former, so presumably this is part of an intended package transition. Is this expected to happen? Does anything strictly depend on jack2? Not that I've been able to identify so far. As part of this same dist-upgrade, a flood of new lib*:i386 packages are being installed, I think as part of the ia32-libs dummy-package transition. It doesn't seem impossible that one of them is depending on jackd2 or similar, but I haven't been able to identify any which does. Also, if I hold libjack-dev and jackd1, the dist-upgrade no longer attempts to remove them - but the only packages which disappear from the upgrade or the new-install lists are libjack-jackd2-0, libjack-jackd2-0:i386, jackd2, and jackd2-firewire. My only guess is that one of the new packages Recommends: one of the jack2 packages, but I have no idea which one it might be. As part of the same dist-upgrade, apt wants to remove libjack-dev, but does not attempt to install libjack-jackd2-dev. This is not fine. Maybe we should convert libjack-dev to a dummy package like jackd. If I understand the problem correctly from what Jonas has explained, that would not seem like an appropriate solution. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695550: libjack-dev: does not automatically transition to libjack-jackd2-dev
On 12/10/2012 11:21 AM, Jonas Smedegaard wrote: Quoting The Wanderer (2012-12-10 16:30:19) On 12/10/2012 10:08 AM, Jonas Smedegaard wrote: There are multiple implementations of JACK, and one of those implementations happen to have a 2 in its name. In that case (and based on a few other things which I've snipped), the question becomes why the dist-upgrade is trying to remove libjack0. Ohhh: Most likely cause is that libjack-jackd2-dev provides libjack-dev! Why does it do that - it seems plain wrong to me! In combination with what Felipe pointed out about ia32-libs and jackd1, that looks like a plausible reason to me. (The ia32-libs factor also probably means that part of the culprit is the holds I have in place on a few other packages, which are also interfering with parts of the ia32-libs dummy-package transition. As such, this is at least partly my own fault, and may not manifest for everyone.) I'd guess that whoever set that up was operating on the same mistaken assumptions about the relation of the jack implementations to one another as I was. I thought the purpose of dist-upgrade, as opposed to upgrade, was simply to allow upgrades across scenarios where dependency changes require installation of different packages rather than simply of new versions of the same packages. Check the meanings with aptitude --help. On my system, the text output from that command does not include the string 'dist': wanderer@apologia$ aptitude --help | grep -i dist wanderer@apologia$ This is with aptitude 0.6.8.2-1. The aptitude man page does give a hint about what you might be talking about, but I wouldn't have interpreted the section on the 'full-upgrade' option to mean what you said. For what little that's worth. Oh, and if you used apt-get, then don't. Use aptitude! I'd rather not, thanks. I'm told that it's not a good idea to mix-and-match between aptitude and apt-get, and I find the aptitude UI to be palpably less friendly and manageable in most circumstances than that of apt-get. I'm aware that I'm a minority in this, but that doesn't change anything. (Though now that I look, I see an option in aptitude which I think wasn't there last time I looked, and which looks quite a bit like something I've been wanting in apt-get for some time now...) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714820: ITP: ntopng -- High-Speed Web-based Traffic Analysis and Flow Collection Tool
On 07/06/2013 09:14 PM, Ludovico Cavedon wrote: On Wed, Jul 3, 2013 at 5:00 AM, The Wanderer wande...@fastmail.fm wrote: Might I suggest a different package name, e.g. 'ntop-ng'? At a glance, 'ntopng' reads to me as N-to-PNG, along the lines of existing file-format converter programs. While it's not absolutely necessary to avoid that, if there's no real downside to doing so, it might be a good idea. Good point about the double interpretation, I did not think about it. However, given that there is no real conflict, I would like to keep the name as close as possible to upstream. Just to be clear, making sure we're on the same page: I'm certainly not proposing changing the name of the actual program; I'm only proposing changing the name of the package. For comparison, a program which upstream calls 'calc' is available in the package name 'apcalc', even though there is no package named 'calc'. (I don't recall whether or not there used to be.) If that would also be too much of a change from upstream to suit your preferences, then fair enough. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730730: youtube-dl: long description lists 'youtube:search' twice
Package: youtube-dl Version: 2013.11.11-2 Severity: minor Dear Maintainer, The long description of youtube-dl (as seen with e.g. 'apt-cache show') includes a list of sites which the program supports. In version 2013.11.11-2, the entry 'youtube:search' now appears in this list twice. A previous version (I believe 2013.10.23-1) included it only once. It seems unlikely that this duplication is intentional. -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages youtube-dl depends on: ii python2.7.5-5 ii python-pkg-resources 0.6.49-2 Versions of packages youtube-dl recommends: ii ffmpeg 6:0.8.9-1 ii libav-tools 6:9.10-1 ii mplayer 2:1.0~rc4.dfsg1+svn34540-1+b2 ii rtmpdump 2.4+20121230.gitdf6c518-1 youtube-dl suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730737: dizzy: exits immediately with strict refs error in Perl2GLSL.pm, line 160
Package: dizzy Version: 0.3-1 Severity: grave Justification: renders package unusable Dear Maintainer, When I launch dizzy, it briefly displays a black window, then exits. The following is printed to the console: Smartmatch is experimental at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 17. Smartmatch is experimental at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 183. GPU features: [x] GLSL [x] FBOs Can't use string (# op description list of private...) as an ARRAY ref while strict refs in use at /usr/share/perl5/Dizzy/Perl2GLSL.pm line 160. I have a local modification to /usr/games/dizzy, to make the '-f' (fullscreen) option work; this was reported as bug 697423, and appears to be fixed under that bug, but the fixed version has not yet been released AFAICT. I have tested without this modification, by way of 'apt-get install --reinstall dizzy', and the present problem still occurs. I am reporting this as grave because it renders the package completely unusable for me, and I have no reason to expect the behavior to be different for anyone else. If it still works on a fully upgraded system tracking testing for anyone else, please feel free to downgrade this to normal. Note that this is the same version of dizzy as was working at the time of bug 697423. In the interim I have dist-upgraded multiple times to track testing, and I am at present up-to-date with testing as of early this afternoon. I do not know specifically when it stopped working. Although I do not use dizzy often, I still like having it available. If there is anything I can do to help track this down, please do not hesitate to let me know. -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dizzy depends on: ii libconvert-color-perl 0.09-1 ii libopengl-perl 0.6702+dfsg-2 ii libsdl-perl2.540-3 ii perl 5.18.1-4 dizzy recommends no packages. dizzy suggests no packages. -- debconf-show failed -- debsums errors found: debsums: changed file /usr/games/dizzy (from dizzy package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710140: gpgme1.0 (=1.3.2) dropping libgpgme-pth.so
apt-listbugs alerted me to this bug when I attempted to upgrade from 1.2.0-1.4. I can't tell from the information provided: if I upgrade to an affected version, should I expect things on my system to break? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723107: less: search history no longer contains new blank entry from current search
Package: less Version: 458-2 Severity: normal Tags: upstream Dear Maintainer, When beginning a text search in less by pressing the '/' key, you are presented with a blank line to type your search string into. It is possible to scroll backwards and forwards through the search history, in order to repeat a previous search (with or without modifications). The behavior of this scrolling at the bottom of the list has changed, in a way that I find both unintuitive and undesirable. Steps to reproduce: * View a file in less. * Press '/' to display a blank search line. * Press the Up arrow to display the most recent search string. * Press the down arrow. Expected result: The original blank search line is displayed again. Actual result: The screen flashes in the manner of a system beep event, and the displayed search string does not change. It is useful to be able to easily return to a blank search string, for example in order to quickly and conveniently cancel the search without changing the displayed search results. It is also not intuitive that up then down does not return to the original location. This behavior change appears to be a side effect of an intentional change: the ability to scroll through only search strings beginning with a particular prefix, by typing that prefix before pressing the Up or Down arrow. I am not positive, but I believe this was introduced in less version 449. Please restore the blank current search entry in the less search history. -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages less depends on: ii debianutils 4.4 ii libc62.17-92 ii libtinfo55.9+20130608-1 less recommends no packages. less suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737208: RFS: linuxlogo/5.11-4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/03/2014 02:46 AM, Dariusz Dwornikowski wrote: I do not want to close old bugs. Just asking, what will happen with bugs for older versions that e.g. are not used anywhere no more? Will these bugs hang forever or is there a cleaning policy ? Whether to close a bug has, AFAIK, nothing to do with whether the version it was reported against is still in use. It's entirely about whether the bug exists in current packaged versions. If the bug is still valid - meaning, mostly, if the behavior described in the bug A: is in fact considered a bug and B: still exists in the current version - the bug should remain open, even if that means remaining open forever. If the behavior described in the bug no longer exists in the current version, but for some reason the bug wasn't closed when the fix was first released, then I'd imagine that the bug should be closed manually (with a comment explaining that the bug is know to be fixed as of such-and-such a version). In the specific case of the bug you tried to close (twice) in the changelog which led to this subthread discussion, the correct thing to do is not clear at a glance. This is because you gave two different explanations of why you were closing it, and the two explanations disagree with one another. One explanation was upstream won't fix. This seems to imply that the behavior described does still exist in the current packaged version, and that upstream has refused to change it. I believe that would be handled one of two ways: * Decide that the behavior described isn't really a bug after all, and close the bug report. * Decide that the behavior is a bug, and leave the bug report open to reflect the fact that the behavior still exists in the current packaged version. The other explanation was not relevant anymore. This seems to imply that the behavior described no longer exists in the current packaged version, but that for some reason the bug wasn't closed when the change actually occurred. I think that in that case, the correct thing to do would be to close the bug report manually (not via a changelog entry), with a comment explaining that the bug is known to have been fixed sometime before version Such-and-such. I'm not an expert on these matters, however. I hope that helps. (And that I haven't gotten anything wrong anywhere.) - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS9Y2HAAoJEASpNY00KDJr1yoP/AxDl1Xxx97kIL2QyDsoRUQ3 lhHWR2cZFmFtiUbdRpKRwzwcUj2IU2IUtphP+30y6EzI82YYXkrKJvYHEBt6kMWg tW68HYhA9lXEtPEq/QMP4tkfEhTAoDg5WaDUK2aG0TmAOq0+UK5sC+xrM24YdTxu 8BcqDki12nFH51RKzdG2lhhvkGmKPQmL6T4/jB8xCasCPWGlgu4ZGjdtDTRLbrXn FgVfIBigDmvSn9yEZrlvJiSReE3Prv8CzUi3vSg6UvNMRfQoGkj1sA8/+X++AoMW twS2Gyj0YqN3QSk/m+/LUo7Ft4DTOZCtpa4ffOHYNl9C/6VsbWO67VN/RbsWhWmM vaFPGHf98THd6gGiFAYvLGjpzUZ8bmvxhBApgx0/9l1wx1VjHRdnd6TsemAuvUVy /Wph8wpu0xvxCtE+TLRRoLDoRERpKZbvafrLPm07VcBuXr3uDWHv6ZOEY3CwI0WG bp/+/4mCE27wP6ji01BuIzqItQ4pJVaRQ4eqRW3mGcSwCU3r3Tb0om7zTrYocfxG b2xK8SWPbJzbW4GlKvSkt7nF/fxVBp4y40b71qPicx0UDK/R4fEVzmS/Otn9LXtS PLSMLa+3VXXCCDTwSEG8yuDJA+c8aA2ARh/+uR+opCdK2GVjnj3fzmShuj21FNAu +tGpbUfClzj3uG0gqDL/ =brz9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/22/2014 05:12 AM, Johannes Schauer wrote: Hi, Quoting أحمد المحمودي (2014-01-22 10:36:11) Actually what happens implicitly (at least on Ubuntu precise) is: $(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@ which causes the compilation to fail, because the -l... should be after the object files (or source files in this case). Ah funny, so it's a ubuntu problem. I did not observe this problem with Debian unstable. After trying it out myself in a ubuntu precise and saucy chroot and asking on #debian-mentors, the reason why this error happens only on Ubuntu seems to be: https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed https://wiki.ubuntu.com/NattyNarwhal/ToolchainTransition Should I contact upstream to yet again change his makefile or are things okay as they are because everything works fine in Debian? Do things still work fine in Debian when using ld.gold (by installing the binutils-gold package) rather than ld.bfd? I know there's an important difference in ld.gold related to --as-needed (or possibly to - --no-as-needed, I don't recall offhand). I seem to recall that there are long-term plans to switch Debian over to ld.gold or to produce the same effect in ld.bfd, and that it's recommended (or at least preferred) to make sure your package builds with the gold linker; I suspect that this is the similar change... being discussed for Debian mentioned in the ToolchainTransition article you linked. There's no expected completion date for this AFAIK, but trying to be compliant with it isn't a bad idea; I've already got the upstream of something I haven't even packaged yet to accept a compliance patch, just based on test packaging attempts. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS39JJAAoJEASpNY00KDJrqYQP/0GBnMOtwgXJwbDIj/qskRr0 En2lnuVM76ua/xb4iYCrbmeQ3APnwJ8pqrJ2oSozuA+A1244TAiXgzf/iLFCZ+JI 2sID3uMLf8+rrXnVs0FFKNEuNHAVYLSi9TxF1Ptlpai1YFwasGU5MrEr13kthrD+ RgQ0+3HWxJ29aNo4yR90SxK8zADjjm0bggJlwI8ltGaWxKMPZsfZSs12f19lMSe+ UpIT0vISg724mlsU3i31+rUIrfnAm+AlrVzX0j5H6p5gkp6o1+IKsmi9LBQviCJh sBZ85Eq7LvZpfWpErf1FBXVRlnosuBC/P/S8XfJhTQP5owDLqOO5ot33IKb128f0 /MmoiT0xe/KjlKnqcLg0Mru90HmNkm1VY0ZKuojJfc1n/OcMg+IX8UrjGCTSnjSW bV7CpT2eYFj6ikbSNcLGBWEy+zllppWaBXIB5K+c3NJ++oc1VHN88/lKlmL36d07 BKPiMA1qoyGbdbpr9dLbCXL8QVgOS9ZblMXRimZjsYhDDM4DzZq6pMheTorfCUR3 9wzGL40K1tE4MNm/j2gfKaYTKauw1u+EI70CPX6+jFECmWqAsL0grDHvMlavZfvN JmoxhwsH6WHldkrhjih1VcglJ84AZCB/wllxsRRI0+ULt7yo4X7966y+0AFi57la 5xw2Zvg+Asg22VMaA1cy =AeaL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735182: RFS: fuseloop/1.0.1-1 ITP -- loopback mount using FUSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/25/2014 05:24 AM, Johannes Schauer wrote: Hi, Quoting The Wanderer (2014-01-22 15:14:34) Do things still work fine in Debian when using ld.gold (by installing the binutils-gold package) rather than ld.bfd? I know there's an important difference in ld.gold related to --as-needed (or possibly to - --no-as-needed, I don't recall offhand). I dont think the binutils-gold package exists anymore. binutils-gold seems to be provided by the binutils package which now seems to ship /usr/bin/ld.gold I hadn't noticed, but you're right, it's only in stable now. (Even the stable package claims that it only installs the diversion of ld to ld.gold, so it's possible that ld.gold was always provided by binutils directly; I haven't dug into the history here.) That might mean my attempted recall was wrong, or that plans have changed since the last I heard about it. It's still probably good practice to make sure things build both ways, though. Do you happen to know an easy, undisruptive way to test with ld.gold? That depends. The most general way I can think of would be to set up an alternatives group for ld, define ld.bfd and ld.gold as the two alternatives, and then switch back and forth in between tests; however, that's a system-wide change, which might not qualify as non-disruptive. Depending on your package's build system, there might be a configure option or an environment variable to specify what ld to use. That would be non-disruptive, since it's local rather than system-wide, but it's also not universally applicable. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJS46qkAAoJEASpNY00KDJr6RMP/i2y/d+ob0fGrU1MrowLPJ48 8w25wSwOxwUWBsm8cck9qSMfB/qgF2lythw4utfPi+LUO0cj7+evTpDJjtcewwJs u4q3mE+HpzWTmkYaD9gZXiKKJiaXx/Uf8QNuob+2kIkesI4QxPNzOnqREvrf/vP/ U+0UwHTwMti80ZFzFWxasMfxNqFyii64vMoYPFx1CkUCYBXwDI8br++xsDOT8yW6 rK3kab1h9VIS+glpTbM+DZBvlVt/1XDQkb10UqK5myIvzvtc99nMunvu7lRuN6wL 7BtwYbGC5vx6y25sNpsumJKBHNyK99vyXAB7xGPuxZ5RWJwd81R5NyE3SDtQ/+OA lA7WWmuOqYxcK2Rkd9r+EEsiaKLqUnUCOvXL/wZQS8SwbuLTyD2rKgCHGendBeU4 RyATKI3gndC1LR226Su7gkx/FhRE5ZGsyx2Re9OEWt4MuVRijOwDhNM1YJX59XlA UiCbMGkfX/zG3p/l4HYuj/TIYlXxxWxXCj/IJfDvh0QAI3Gdr2jbciQYiSWTJHQ7 6MzlAnkbn3M7PJC2BKfIilVufeQmln6SOvTe7JvHD1bQbWZ512RDhAAaA7NQxB4L 2OogGzLQg7nLheVFzaWJAEULqDzuHMCXsC8iItNtUX55JrvAG7pp1sKAFWjoYeCl oA8qeUxdwVseS1C2krN+ =817s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741843: [help] volview: FTBFS: vtkKWWizard.cxx:162:51: error: 'Tcl_Interp' has no member named 'result'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/15/2014 04:07 PM, Andreas Tille wrote: Hi, is there any kind C++ capable soul who could provide a patch for this problem? A bit of Googling seems to indicate that this is due to building against Tcl 8.6: https://bugzilla.redhat.com/show_bug.cgi?id=902561 As a short-term thing, you can probably get it working by either adding - -DUSE_INTERP_RESULT to the CPPFLAGS at build time, or patching some appropriate internal header to include the same define - or possibly by explicitly build-depending on tcl8.5-dev, though I don't know enough about Tcl or its packaging to speak to that approach. In the long term, as the link indicates, the correct fix would involve modifying the source to avoid using internal fields from Tcl_Interp. However, that seems like the sort of thing that would be best done by upstream. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTTZZdAAoJEASpNY00KDJrFMwP/1RPRb8PkbiNmRuegI8aT63b yrt3s+iKF8fAC9XsPpYI+J5I7VlnEz97B4Rf1/vBYx2R/HBjJE7FxSAJiPUoKz0J Eqgo0evIaVKdOFFLydAPbbEz9jswyZRDtXCYwBD1gXNjTMayOvZ/X2TLmvlPTOCD BJChOuA57lIUPsXfvaacQPQeu2rqX0WOrHp9NEZMaPRU3j5w1nHKKzgkYaDgYTii gWMaWaO1WStGTw++N6pKKLeFBHTIgJ2oKr/pX7HtmQwS3TXDZFL0PGT/ixxghut5 o+0+cwRdlVTOdZIhU2c5ALFvb7Jbmq7SPkoA66HxhR5pV9Ds3Cj0dQrclpUpw2jv /HvPYw9y1Q1YLMHCjOz1xLSYf6HPSZmMLb/xmSwkdjdhorcoK/dqsmZQrlvBxpdM 0ZCBXvyxUcmPbwjz9wYqd3wO7hjdnujhlFf5Hyt0CJ+/27Iuo4Bwe5u5SOatDpuy LmKnEtp9tllqgEvwMZt+HjX44auL02TxDoX9mkfh/wXOg5t3i0G4oIDvL2lzMduT iA+OQjPtAEJcgwkiQZdm1KZicvKX/7ftOSaBlNybWXw0wLciU+cD8yXanHGc3nQ+ J8zFpPOFo18LYcCas8TnvsaNTci5pUI2vLtjGJ8DFK+4A6YU9Xn1UPBmEyrhnNyV bXwaasScwv3qGuIwdKkU =xeha -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519469: apt-get proposes to autoremove packages not yet installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm seeing what looks like a somwhat less severe version of this same behavior. As it stands, I have no packages listed as candidates for autoremoval: root@apologia:~# apt-get autoremove Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded. Attempting to dist-upgrade results in candidates listed for autoremoval, all but one of which are also listed as candidates for new-package installation: root@apologia:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages were automatically installed and are no longer required: librtmp0:i386 libzita-alsa-pcmi0 libzita-resampler1 uuid-dev Use 'apt-get autoremove' to remove them. The following NEW packages will be installed: gir1.2-atspi-2.0 libatspi2.0-dev librtmp1 librtmp1:i386 libsdl-gfx1.2-5 libzita-alsa-pcmi0 libzita-resampler1 nettle-dev startpar uuid-dev Something is screwy somewhere, though I'm not completely clear on whether it's necessarily in apt or whether it might be in the dependency constellation of some other package(s). I'll hold off on completing this upgrade for a few days, in case this gets any attention and there's anything useful to be discovered from my system configuration. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTXFc2AAoJEASpNY00KDJrjXkQAIMYZLxyUdVTu7nEYi7MI5uB eHWh/mHaoCQLj1/JevECqVI9EpNvXA+SspyjTCGbmS7XCOddPKnAMNT3f5iYwa3/ 4YAdiQdBfRZgWX3SICi4CDz2ZwPdjjX0SYiX5kq4Dzk90sbZJg0k651xkQJH5cPm XHPXwZ/udFcqAQ1wwmOkTaNe4saX09K9s3/W2V8Q6SjPRb6T4lSwatlYAI/0Q5Pq y5li1x3kNazGI2Cqahn3/w7FnFehg/pBx1a7VZ0m6DKfP0Oa3MAPYxzt+aczLUaO gurPXPHMvnrxS3/Udq7wuzqBkk13Znx0udGMt2zItFF7KPJPSewLG+pkulj6DecO KndjDxFXX63q6Bh6XCUMgNjYN+F/WDdAXTLtITZnnd4ZmTgj6ekO3sOqaTfdVAx+ 0uPhRhPJgMMxvoDybJJRIPHu5m9m/M/mz4bAmBiVoOauu3ONBMlwLTgGvf9tLIpS 1M31DQJYBB7qt244JN4gYScyc4ay8xM83RWMJibZ3rC0/myGrlz1L9q5NJnEJuZE 5jnWsHhYrhithKDfh85BXQhFN6+b2lWC/rT9W78AC9CBO4/AuAgnlxJCWRerFZCH 7tZW1RodOLjjB1jWhBF+4jM3lRzFBL/46pyBIXN1K0W9eD2wqnXYyNj/0TH06L30 fWIsPwTlKY670Snp+gOZ =D13N -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519469: apt-get proposes to autoremove packages not yet installed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It looks like this happens when: * One version of a package is installed. * A newer version of that package is available from the repositories. * The newer version depends on a package which the currently-installed version does not. * The new-dependency package is not currently installed. * The original package is for some reason marked as kept back by the dist-upgrade logic, and so will not actually be upgraded. In this circumstance, apt-get incorrectly selects the new dependency for installation as a new package by dist-upgrade, even though the package version that depends on it is not actually going to be installed. It then correctly lists the newly installed package for autoremoval, because nothing that's actually installed depends on it. Here's the details of my case, from which I came to this conclusion: I run an amd64 system, with i386 enabled on multiarch. jackd1, libjack0, libjack0:i386, and libjack-dev are installed on my system. Both libjack-dev and jackd1 depend on libjack0. The newest available version of jackd1 adds a dependency on libzita-alsa-pcmi0 and libzita-resampler1, and the newest version of libjack-dev adds a dependency on uuid-dev. None of those three packages are currently installed. Due to bug 740708, the current testing version of libjack0 is not coinstallable with the current testing version of libjack0:i386. As a result, libjack0 is kept back on dist-upgrade, causing libjack-dev and jackd1 to also be kept back. However, the new dependencies of those packages are still selected for installation by dist-upgrade. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTXUdMAAoJEASpNY00KDJrcw8P/RDZpTVzSmB2WbQ5oFMsGKh4 SmgaT1Z93Sd1EkPXgUAZxSRn2qKRQdAUBogKnDbFlsyOThB8Fcis15h1fHbBQZ6a FGFL+YHNs7I+pRFHgpu22EUo4AbesektX5XecFMUniYeDaIlgp+vbrU2Rz+V8NGa AkrZi030VZBkCVTmaK0PDzbb4NAtUmzo1/0/aiFjqOR/kpOVblxcw5N7XfWUmdHg TtEUqmDViYkVYYO9NyWf7eU7PW6gxFNqHMHw1qVwyNwCl1xg7cIXr/nFNCdp/Nf8 yT+IjMXRzTKEDDr+gF/xJpNodHVjaXrPgi00m2Nd+h3RLnaNbolCYvGd/Bma2E6l IwRB19XpQ8HA5Pt/6JJ12arZCnNRuop44dG71ggevZxIXVID9XK7xv/070a28kqB 4YK3SQq90Hzv0gzujlj+rzbK0ujchZe+DHnxbFGZJNMleYe5b3bqgExGmglVAERd PEUTFfrrhEJbsxo8cJ2O9ARoMVDKfM/PVyhrqNSoPyPIEcNsS2n83K+yG7wlhyT7 nWgRJaeVmBC6ASjqwlEJlifunAxG3dQP1j56Xmwvm6FECp3kvQzLNddxMXTLhggD XRuGg/oMxIUqRDe9oVmxYB2/VP/o5aQMvzeLvSRKbuwldvDw+pRW+MQAgi5oNfau laP9tfl1+tORrJyjUIZ/ =cAO7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751048: marked as done (RFS: fizsh/1.0.6-1 (already in Debian))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/16/2014 12:42 PM, Axel Beckert wrote: Control: reopen -1 Dear Bart, Debian Bug Tracking System wrote: Package fizsh has been removed from mentors. since when is this a reason to close RFS bug reports? Reopening! I believe the idea is that if the package is not (any longer) in mentors, there is nothing left to sponsor, so the RFS bug is obsolete. If something new comes along to be sponsored later on, according to my understanding of the logic, a new RFS bug should be filed. I could easily be entirely off-base about that, of course, and I agree that the phrasing in these (semi-automated?) closure messages is kind of confusing; it took me a few weeks seeing them come through the mentors list before I figured out what was probably going on. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTn6hGAAoJEASpNY00KDJrqJ8QAIT2MPWHQ+1wKCsTrROi8jEf Jk5IqDhq3nrhcFNXNkdiOFS3xcQSC8eeXRfV8Yi/WxnC/8GZ+Njst7av3DR+wtTB lxVOBaq/s6Q82KwkIpdcnJlPhPmDG6nkQiiuIPkuIprRuvzpoe3ytSr7ucA+20ua BBD8vJX8WRlVbyPvOZmsYwsaKwLMZp8rvmiDOBD5a6AVUbTmNE2eBxny3KcXNCjF BVSp4kzKPqVzeTHvJv8dgd/e+ADzXRwK8Pn2BBVknFS5snrxzYN8K6KWG6oKt/w+ Qug/G46eOwMgcSDpCf3M6EKsjs/MwqcKGzuOlu06yljq/swMcVuRRwKN6vS6uOXA U7h/QrPhvaJ5RxV4moRpA+CQWU70btGVPoplreYK9wsaCHV4ApuUioR6lXZx32w1 yJot9k8IewLJRRBUAUrb2OI19TrN/2BiluyiObBBHGhQ6B+SOrwGYBE4JTsmXaYC JjMxqeR07gSw0fxNLH5qDADRYqNvQPme0wJEf3VgH1umBGLLdwFviDC9vEpQlohD AZJ5Ef2tEAAQ6c+Hl+CljY+QOaE+7QZBzbcTHaEXNSFDJPbFVDM6EKbn/DGS/4d9 WPl+kWC+93NalkIwgI6zaSwoWTf96VlEg6kB8slEyXFf2VIHEy4rNyatTuOxWFmt +uYpkuh4eD3cmB4glYne =fNjx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751396: genisoimage: -xa option not documented in man page
Package: genisoimage Version: 9:1.1.11-2 Severity: normal Dear Maintainer, According to information found via Web search, the old mkisofs supported a '-xa' option, to create XA-format ISO filesystems. (Exactly what the differences between that and a non-XA filesystem are is not clear at a glance, but testing confirms that they do exist.) Since genisoimage is descended from mkisofs, it seemed likely that it should also support the same option, but the man page does not mention any such option. However, in my testing, genisoimage does accept the '-xa' option, and does generate a different image with that option - including various obviously XA-related tags in the generated (meta?)data. Please document the '-xa' option in the genisoimage man page. It may also be worth reviewing the code to identify any other undocumented command-line options, and adding man-page documentation for any such which are found. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages genisoimage depends on: ii libbz2-1.0 1.0.6-5 ii libc6 2.18-7 ii libmagic1 1:5.18-1 ii zlib1g 1:1.2.8.dfsg-1 genisoimage recommends no packages. Versions of packages genisoimage suggests: pn cdrkit-doc none ii wodim 9:1.1.11-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751396: genisoimage: -xa option not documented in man page
On further research, it appears the man page was updated to include this option (and many others, some of them aliases to already-documented commands and some previously undocumented) in upstream SVN... in January 2011. (With typo fixes in March of the same year.) However, the last official upstream release was made in October 2010. The only commits upstream since that official release are documentation updates, documentation spelling/typo fixes, a correction to a Changelog entry, and a segfault fix for icedax. That doesn't seem enough to be worth making a release over, which probably explains why upstream hasn't made one. Any chance of either updating the package to the latest upstream SVN revision, or at least cherry-picking the man-page changes into the Debian package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505381: genisoimage: writes blank sectors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This behavior (or one very similar to it) appears to still be present, five and a half years later. The patch still appears to apply (albeit with considerable a offset) against current upstream SVN. I have not managed to find any indication of what the reason for adding these blank sectors is supposed to be. The code in question appears to date all the way back to the original import of mkisofs into Subversion, so there's no help there. Any chance of either getting this patch applied, or at least figuring out a reason why it would be a bad idea? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJTmzLDAAoJEASpNY00KDJrbKkP/16p+KD924ulw9uNTLl9fiy8 RW3WTiMqK8Hv8izcOk+nfTZlLBWDMdFsUHTqWsw4xhgCN+F6KauVDAy1eB82FrEx 8KTCTpb7H0fCrXzY9WArQBPSWAAF/lWn5/dRmw4ZuJUaaAmsZcYRxl1E4cxB+CEF Aoctd0gk3jccQ9Qd+IwzIc5eM2eP1HwHWYfoLoVs7aOlnAWLQ2vt4tnR1nW3YXcG uGUIkcP662l7taIJRW2NsT31AdWXneDrZ3dnHLaORjnrKBzkuFhg0mdRmaKQqzE7 91Tg5L+H/mH9lusfRqkR038dIZy2YoZdpRtcsDkn0iLqvxa3DKVxR3dUZj+Id2+C lhhvTQ2K/1MPVf/FF6mP5ubo7h4V/Vk1K4AQPh9k+RQBRc829njy9HMPcCAdFW2v bAYcESqWmrzNY7HjCVb3rVMVm5SKL3BG5IfwflWBm/+0zr6z970Y7ufHtlnrdzrr KL10nAKg8yh9r4sWYDl2iB007M7bKVLplQsExdh+x6Dj7O5Oiwkub523/zaa4nYu eu0HibpVgGdmi6xE547UucNCf7bOl6TPAfsbiQihwXC3HDNx9fCUb5CkzMgFlPcz l9GRhordnborQzTwTbIimMWFv/OaGwKDFW8Mn4mczGyCmCQoVx68lx8smjVfghuv lkyl/b0kz5TcaoUBzOw3 =+qSF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756883: micropolis-data: depends on dummy package ttf-dejavu-core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: micropolis-data Version: 0.0.20071228-7 Severity: minor Dear Maintainer, The ttf-dejavu-core package has been replaced by the fonts-dejavu-core package; as far as I am aware, this is a simple package renaming. ttf-dejavu-core itself still exists, but is a dummy package, and in the long run needs to be safe to remove without causing the removal of any other packages. However, micropolis-data still lists a dependency on ttf-dejavu-core, which prevents the dummy package from being removed without also removing micropolis. Please update the dependency to fonts-dejavu-core, or if there is some reason why that is not a suitable alternative, take other appropriate measures. - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages micropolis-data depends on: ii ttf-dejavu-core 2.34-1 micropolis-data recommends no packages. Versions of packages micropolis-data suggests: ii micropolis 0.0.20071228-7 - -- debconf-show failed -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJT3ZZpAAoJEASpNY00KDJrVEMQAKsrRcQABKPs+puvCJT9OZ5Z ur5HtZg3VAlFA/1SSW8S3HGZ/n+eoTXWopCG3AUmmHEPiu60HgzKaAMnDI63RSqk iDIxkRNRa0EvAe3HKDMPS7/9mj5Tl8h7ib4BrkkMCqCoS7/BYLaCeHu7Zsc2if8g 8ecbRb6LI//HUSwz+cyPxFdPWORN724pR04t08ro6JRt7k4Qx6292pPIMHCDx339 9fAEI4dPVquT+ZJeNzb+/Kb8+yZ4kyGMc6GbHFNMgqAGK4airC+S8kHPv8tJbKQ1 Qj27Hje2sg3M7RfdsYEz0enZg5Et1ImVa89RvJvUTc83fnfaG2E0M/s3d4ytgwRK oxrslokBM2eWCclfqWlpF/4GKo98rNf7pGxq8JDiX0/dwH4JvIBaBXvMcJ7o8tBl eANneH91wbFRqIdg/kwEiMN+ATZgAI+rVChesI6hs/Vzt36EoXx2JpLrE1WlbVdR BjKNTMDUlyAkwdxYRmUCgbYSHWlhT+QeYQ50FQtih+YG0XFUQ5b4qLRmST93jnmJ GPVARYHLnQanMyzp2ILP+55k1VaxU6MVYnEy2Px78UzteiZJKbtNCMaw325zVYAK OD+DiMRgkrAuOxjK/i3UjPbx3rwp71UAWZ7S9zM52GAAENiXD8pj/wcL1W0g+84H wzW/yOPGr7bJwdwj0ARu =cORu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763619: libmeanwhile-dev: package long description refers to old library package name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Source: libmeanwhile-dev Version: 1.0.2-5 Severity: minor Dear Maintainer, The long description of libmeanwhile-dev states that the package contains development files of the libmeanwhile0 library.. However, the package itself now Depends: on libmeanwhile1, and libmeanwhile0 appears to no longer exist. It is more common for -dev packages to simply state that the package contains the development files, without specifying any particular package name or version, which is already implicitly indicated by the package dependencies. This mismatch is probably an example of one of the reasons why. Please address this discrepancy, either by removing the package-name reference, or by updating it to refer to the currently live package name. - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUK/XKAAoJEASpNY00KDJr7H0P/jGXvUcWp+0jkf9PfyeJSRFt oYttppes3F+aWqUgHYFSc5KqVH4iN+QpA+P2BaMGMhvw8EZNQiD+DUS10g4agaEA eyp3Oult3zszybk+8hsi3HtWuu8trvNc4z9qn9QoEm8ODvC2pqOM/e3ATYeJHLA9 YbW8bpS2ZFlSw0Zosw8PJp2njaFaff7kl5AD/6+Z6I9gaUTo/fRTQJx57/PZrDBk OzOS0UxyVrdyYwgKjx24q5sx4CLlSdLF6MSFCrzzhUGXw+S7Q9w60RLxA+9wDspc m0dRRrEBTO2c1U2PvGaO9vSM95hgXAOow/nBLRR3FAx0QrqXaEsTsJ6bZJwNkUMU 3c9cqW0M9xOK1dhvDHjPOfmfWhRnymjyfNElwmRYZPVQVZ86qBwqR0vgZTScRzmZ ie/wcle1j01zakMChdhwWRvushvqyo0Bw7tRXZmcrL4rcfOm5S+TyNQ859ciPERw tXoQdVmFaUiYT8Lknkro6gvCFShBFov0J42hIfXnMQ8PAuDD1eJKRSH6QVq+aTLu NJot0Mjeo9U9Pev4vdLVPcG8lEHY92eM4h+FseGu4Fnh9DLBf0f2feIdVPxIJIan HTzFEYyJUgJKNdExuDxxxgYe2u5sZ+oRaH1sOhkqw/wGr2olaFsuUKLfqfsCEzwH 4Au+xVIrDlTFtcr74pwX =4dG3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769602: youtube-dl: download from YouTube fails, “RegexNotFoundError: Unable to extract Initial JS player signature function name”
This looks like an issue which was fixed upstream in version 2014.11.13: https://github.com/rg3/youtube-dl/issues/4175 -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#798033: www.debian.org: get.debian.org rejects HTTPS connections, but redirects to HTTPS site
Package: www.debian.org Severity: minor Dear Maintainer, I'm not completely positive that this is the correct place for this bug report, but I don't know of anywhere else which would be better. Please feel free to reassign if appropriate. Whenever possible, I prefer to connect to Websites via HTTPS. This includes all Debian Websites. When I connect to http://get.debian.org/ in a Web browser, I am redirected to https://www.debian.org/CD/, which is a HTTPS site. However, the initial connection attempt is made over HTTP, and is potentially subject to external observation. When I connect to https://get.debian.org/, I get a near-instant "connection refused" or "failed to connect" error. Firefox reports "Unable to connect", w3m reports "Failed to load", and wget reports "Connection refused". Initial testing seems to indicate that the same basic behavior occurs with cdimage.debian.org, which is the old name for the service now provided by get.debian.org. Please make it possible to connect to get.debian.org via HTTPS and have the redirection function properly. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#799296: mysql-client-5.6: upgrading from 5.5 to 5.6 with client running lost client command history
Package: mysql-client-5.6 Version: 5.6.25-4 Severity: minor Dear Maintainer, I habitually have an instance of mysql-client running, connected to a particular database, with the somewhat-complex commands which I regularly use with that database present in the mysql command history. When I have upgraded mysql-client in the past, all I have needed to do is to exit the old client instance after the upgrade and re-launch with the new client, and everything has been seamless. In particular, the command history from the previous client has still been present. When I upgraded to 5.6, exited the 5.5 client, and re-launched with the 5.6 client, I discovered that my command history was empty. Newly-entered commands made it into the new history just fine, but all of the old ones were gone, apparently beyond recovery. I expected that instead, my command history would be retained, as has happened on every previous upgrade in what is substantially the same scenario. In this particular case, I was able to recover the main important commands from where they were displayed in the terminal from the recent 5.5 session, but it is pure good fortune that all of the main important commands had been used recently enough to still be visible in the terminal's backscroll. If any had not been, I would be stuck with reconstructing them from scratch. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mysql-client-5.6 depends on: ii debianutils4.5.1 ii libaio10.3.110-1 ii libc6 2.19-19 ii libdbd-mysql-perl 4.028-2+b1 ii libdbi-perl1.633-1 ii libgcc11:5.2.1-17 ii libstdc++6 5.2.1-17 ii libterm-readkey-perl 2.33-1 ii libwrap0 7.6.q-25 ii mysql-client-core-5.6 5.6.25-4 ii mysql-common 5.6.25-4 ii perl 5.20.2-6 ii zlib1g 1:1.2.8.dfsg-2+b1 mysql-client-5.6 recommends no packages. mysql-client-5.6 suggests no packages. -- debconf-show failed signature.asc Description: OpenPGP digital signature
Bug#799296: [debian-mysql] Bug#799296: mysql-client-5.6: upgrading from 5.5 to 5.6 with client running lost client command history
On 2015-09-17 at 12:48, Clint Byrum wrote: > Sorry that you had this happen. I wonder if the important commands > were mysql grants for users? It's not impossible that some of the oldest commands in the history might have been such grants, but most of the history was more mundane select and update queries - albeit ones with enough complexity to be a pain to construct. > More likely would be that perhaps you had the mysql client wrapped > with a shell script that changed MYSQL_HISTFILE to something other > than ~/.mysql_history ? Not as far as I know. I haven't intentionally written any such wrapper; as far as I know, what I was running was the version of /usr/bin/mysql which is provided by mysql-client 5.5.44-0+deb8u1. I also still have a backup copy of a (much) older ~/.mysql_history, from before this database even existed, at a path and filename which seems to indicate that I copied it from the name ~/.mysql_history. For whatever that's worth. > Thanks for reporting anyway, we'll try and figure this one out. You're quite welcome. In the unlikely event that there's anything I can do to help track this down, please don't hesitate to let me know. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#807948: apt: 'update' fails with 'Couldn't create tempfiles for splitting up' InRelease files
On 2015-12-14 at 12:47, David Kalnischkies wrote: > Control: notfound -1 1.0.10.2 > Control: found -1 1.1.3 > > (fixing up metadata to reflect report) Looks like my attempt got there a bit earlier, but thanks anyway, since I wasn't sure I'd gotten it right. (Is the use of -1 to represent "current bug" or suchlike documented anywhere? I remembered seeing it used, but I couldn't find it in https://wiki.debian.org/HowtoUseBTS, https://www.debian.org/Bugs/server-control, or 'man bts', so I didn't risk trying it.) > On Mon, Dec 14, 2015 at 11:42:34AM -0500, The Wanderer wrote: > >> Couldn't create tempfiles for splitting up >> /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_InRelease > > The code doing the splitting is present since 0.9.8 (~2013), so that > is probably really about the tempfiles rather than this code itself > as it didn't change much. > > I guess its permission related as this code is now executed as _apt > rather than as root. You can disable privilege dropping temporarily > with -o APT::Sandbox::User=root Agreed, that sounds likely - and thanks for the tip. > Interesting might be the permissions of your $TMPDIR: stat /tmp > $TMPDIR $ stat /tmp $TMPDIR File: ‘/tmp’ Size: 53248 Blocks: 112IO Block: 4096 directory Device: fd02h/64770d Inode: 2 Links: 73 Access: (0775/drwxrwxr-x) Uid: ( 1000/wanderer) Gid: ( 1004/ tmpdir) Access: 2013-08-30 09:47:13.901246241 -0400 Modify: 2015-12-14 23:14:47.519608765 -0500 Change: 2015-12-14 23:14:47.519608765 -0500 Birth: - IOW, it's not world-writable, and the group involved is probably not a standard one. By comparison, on a different machine which doesn't have the problem, /tmp is drwxrwxrwx root:root. Now that I've looked at this, I vaguely recall that I set /tmp up this way intentionally, not long after I built this system - but I can't remember why. I think it was simply that I couldn't write to /tmp as my normal user otherwise, but that doesn't seem to hold with the other system; there may also have been a bit of thinking that the way /tmp looked in 'ls / --color=auto' with drwxrwxrwx root:root was ugly, but if so I haven't noticed it on the other system in the past few years. This is probably the culprit. I'll investigate changing this in the morning, when I have more time and less of a headache. It might be worth trying to detect /tmp or $TMPDIR writability at some point in the process, but I entirely understand if it's considered not worth the code and/or the hassle. > Potentially also how you mount it (if you do it): mount | grep tmpfs This returns a bunch of things, starting with udev and including several things under /run and one under /sys, but no /tmp or similar. > [I see that you haven't followed the systemd switch yet, which > suggests you could have other "new" default options not as default > like a non- persistent /tmp as well] As it happens, /tmp is currently persistent on this computer, but is non-persistent on the one which doesn't have the problem. That's got nothing to do with the systemd switch AFAIK, however, and I'm pretty sure it's orthogonal to the current problem. > You could also try moving /var/lib/apt/lists away. There is no > 'partial' in this file path, so maybe some bad file is stuck in there > doing bad things. While at it: Anything interesting in the partial/ > subdirectory and does the mention file looks at least reasonable? The > files are all Hit's – what modification time have the files in the > lists/ dir? I don't have this information ready to hand, since I always run the update again after downgrading back to the working version, and that's going to update the timestamps and suchlike. If it's important, which I now think it probably isn't, I can do the dance to get it tomorrow or so. > I presume 1.1.3 was the first apt you tried of the 1.1 series, > right? It's the first to make it to testing, so yes. >> Could not execute 'apt-key' to verify signature (is gnupg >> installed?) > > (That is a catch-all message printed after we had a failure higher > up the chain [which was probably very technical like this one] – with > the "most likely" cause added in a few layman terms as we do it in a > few other error messages as well.) I rather expected this would be the case. I mentioned gnupg just to confirm that, yes, I had investigated the cause suggested in the error message and it didn't seem to apply. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#807948: apt: 'update' fails with 'Couldn't create tempfiles for splitting up' InRelease files
Package: apt Version: 1.0.10.2 Severity: important Dear Maintainer, When I upgrade to apt 1.1.3 or later (tested with both that and 1.1.4), and then run 'apt-get update' or 'apt update', I get results like the following: Ign:1 http://ftp.us.debian.org/debian stable InRelease Hit:2 http://ftp.us.debian.org/debian testing InRelease Err:2 http://ftp.us.debian.org/debian testing InRelease Couldn't create tempfiles for splitting up /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) Hit:3 http://ftp.us.debian.org/debian stable Release Err:4 http://ftp.us.debian.org/debian stable Release.gpg At least one invalid signature was encountered. Ign:5 http://download.videolan.org/pub/debian/stable InRelease Hit:6 http://download.videolan.org/pub/debian/stable Release Err:7 http://download.videolan.org/pub/debian/stable Release.gpg At least one invalid signature was encountered. Hit:8 http://security.debian.org stable/updates InRelease Err:8 http://security.debian.org stable/updates InRelease't create tempfiles for splitting up /var/lib/apt/lists/security.debian.org_dists_stable_updates_InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) Hit:9 http://security.debian.org testing/updates InRelease Err:9 http://security.debian.org testing/updates InRelease splitting up /var/lib/apt/lists/security.debian.org_dists_testing_updates_InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) Reading package lists... Done W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://ftp.us.debian.org/debian testing InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?) W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://ftp.us.debian.org/debian stable Release: At least one invalid signature was encountered. W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://download.videolan.org/pub/debian/stable Release: At least one invalid signature was encountered. W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://security.debian.org stable/updates InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?) W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://security.debian.org testing/updates InRelease: Could not execute 'apt-key' to verify signature (is gnupg installed?) W: Failed to fetch http://ftp.us.debian.org/debian/dists/testing/InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) W: Failed to fetch http://security.debian.org/dists/stable/updates/InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) W: Failed to fetch http://security.debian.org/dists/testing/updates/InRelease Could not execute 'apt-key' to verify signature (is gnupg installed?) W: Failed to fetch http://ftp.us.debian.org/debian/dists/stable/Release.gpg At least one invalid signature was encountered. W: Failed to fetch http://download.videolan.org/pub/debian/stable/Release.gpg At least one invalid signature was encountered. W: Some index files failed to download. They have been ignored, or old ones used instead. As the below should indicate, I do have gnupg installed. Downgrading back to apt 1.0.10.2 (which is a manual process involving multiple passes with dpkg, due to dependency problems) restores functionality. A problem which looks like the same issue has been reported by an Ubuntu user: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1524196 The configuration information below was captured from a system where the downgrade back to 1.0.10.2 had been completed. The pins against apt and aptitude-common are to prevent dist-upgrades from bringing back the broken configuration again. As far as I'm aware, nothing about my system should prevent this from working. However, I've been unable to figure out how to get meaningful information about what is failing. If there is anything I can do to help track this down, please do not hesitate to let me know. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.1\.0-2-amd64$"; APT::NeverAutoRemove::
Bug#807948: Acknowledgement (apt: 'update' fails with 'Couldn't create tempfiles for splitting up' InRelease files)
found 807948 1.1.3 notfound 807948 1.0.10.2 thanks My mistake - I forgot to tweak the bug-report template's automatic version info before sending it in. This is found in 1.1.3 and later, not in 1.0.10.2. This is the first time I've used the BTS commands, so I hope I've got this right... I tried to correct it with the 'bts' command-line program first, and saw no errors, but nothing seems to have happened to the bug itself. If this mail doesn't fix it, I'll leave things alone until someone can look at this, or until I can get advice through other channels.
Bug#807948: apt: 'update' fails with 'Couldn't create tempfiles for splitting up' InRelease files
On 2015-12-14 at 23:31, The Wanderer wrote: > On 2015-12-14 at 12:47, David Kalnischkies wrote: >> On Mon, Dec 14, 2015 at 11:42:34AM -0500, The Wanderer wrote: >> >>> Couldn't create tempfiles for splitting up >>> /var/lib/apt/lists/ftp.us.debian.org_debian_dists_testing_InRelease >> Interesting might be the permissions of your $TMPDIR: stat /tmp >> $TMPDIR > > $ stat /tmp $TMPDIR > File: ‘/tmp’ > Size: 53248 Blocks: 112IO Block: 4096 directory > Device: fd02h/64770dInode: 2 Links: 73 > Access: (0775/drwxrwxr-x) Uid: ( 1000/wanderer) Gid: ( 1004/ tmpdir) > Access: 2013-08-30 09:47:13.901246241 -0400 > Modify: 2015-12-14 23:14:47.519608765 -0500 > Change: 2015-12-14 23:14:47.519608765 -0500 > Birth: - > > IOW, it's not world-writable, and the group involved is probably not > a standard one. > > By comparison, on a different machine which doesn't have the > problem, /tmp is drwxrwxrwx root:root. > > Now that I've looked at this, I vaguely recall that I set /tmp up > this way intentionally, not long after I built this system - but I > can't remember why. I think it was simply that I couldn't write to > /tmp as my normal user otherwise, but that doesn't seem to hold with > the other system; there may also have been a bit of thinking that the > way /tmp looked in 'ls / --color=auto' with drwxrwxrwx root:root was > ugly, but if so I haven't noticed it on the other system in the past > few years. > > This is probably the culprit. I'll investigate changing this in the > morning, when I have more time and less of a headache. I've changed this to match the described configuration of the machine which works, and the error has disappeared. (I first tried just adding '_apt' to the group involved, which has write access to that directory, but that didn't work; I'm not really sure why.) Unless it's worth trying to detect this type of case in the code and either adapt to work around it or provide a more useful error message, about the only thing I think might be called for would be update documentation to at least provide a hint of where to look. (Someone should probably also point this out to the person who reported the Ubuntu bug I linked to; I may, if no one else does.) If that's not worth it either, this bug can probably be closed as (a somewhat unusual form of) operator error. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#798033: www.debian.org: get.debian.org rejects HTTPS connections, but redirects to HTTPS site
On 2016-02-18 at 04:27, Niklas Edmundsson wrote: >>>> * The Wanderer <wande...@fastmail.fm> [2015-09-04 12:17]: >>>>> When I connect to http://get.debian.org/ in a Web browser, I >>>>> am redirected to https://www.debian.org/CD/, which is a HTTPS >>>>> site. > > FYI, get.debian.org redirects to http://www.debian.org/CD/ > > I think the https stuff comes from the > https-was-previously-used-for-this-site-so-lets-enforce-it > site/browser feature, I forget what it's called... > > So at least the confusion is not intentional on our part ;-) The same redirection happens with wget: $ wget http://get.debian.org/ --2016-02-29 07:19:52-- http://get.debian.org/ Resolving get.debian.org (get.debian.org)... 130.239.18.173, 130.239.18.165, 2001:6b0:e:2018::165, ... Connecting to get.debian.org (get.debian.org)|130.239.18.173|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.debian.org/CD/ [following] --2016-02-29 07:19:52-- https://www.debian.org/CD/ So unless wget has a similar feature (which would rather surprise me, particularly since I don't see one documented in the man page), I think this is an unlikely explanation. (For that matter, it also happens with lynx, for which I'd be even more surprised if such a feature were present.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#817244: exim4-base: cron noise re environment
On 2016-03-10 at 11:05, Andreas Metzler wrote: > On 2016-03-10 The Wanderer <wande...@fastmail.fm> wrote: > >> Andreas Metzler <ametz...@bebt.de> on Wed, 9 Mar 2016 18:07:30 +0100 >> I get this same behavior. > >>> The Debian configuration sets add_environment: > >> $ /usr/sbin/exim4 -bP | grep environment >> LOG: MAIN >> WARNING: purging the environment. >> Suggested action: use keep_environment and add_environment. >> >> add_environment = >> keep_environment = > > >> $ /usr/sbin/exim4 -bV | tail -n1 >> Configuration file is /var/lib/exim4/config.autogenerated >> >>> grep -rl _environment /etc/exim4/ >> >> $ grep -rl _environment /etc/exim4/ >> grep: /etc/exim4/passwd.client: Permission denied > > Hello, > > Does not look like you are using unmodified up-to-date exim4-config: I didn't see how that could have happened, but you appear to be quite right, though there's something odd going on. Yesterday, I did an 'apt-get update'/'apt-get dist-upgrade', specifically in order to check whether the updated exim4 in testing fixed this problem. In the morning, when I saw that the cron mail had still showed up with the same contents, I went looking and found this bug report. After receiving your mail, I ran 'apt-get dist-upgrade' again, without running 'apt-get update' first - and it listed exim4-config as being available to upgrade. (It appears to have previously been at version 4.86-7.) I don't know how this can have happened, since as far as I'm aware I had no pins or holds on exim4-related packages. With exim4-config updated to version 4.86.2-2, however, I now get the environment results you indicated. I expect this to have fixed the problem. If I do get the notification again tomorrow, I will report back. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#810290: ITP: mediawiki -- website engine for collaborative work
Is there any update or status on this? Before realizing that Debian's MediaWiki packages were out of date and were not included in testing, I committed to setting up an in-house Wiki at my workplace, to be present and functional by the end of June. If it were going to be dropped from Debian entirely, I could fall back on installing and configuring MediaWiki separately, rather than via the Debian packaging system. However, if (as this bug indicates) it's going to be reintroduced through Debian, I would prefer not to install an unpackaged version and then need to deal with either upgrading it manually or migrating across to the packaged version. As it has been more than two months since the filing of the ITP, and nearly as long since the last bug activity, I am left a little bit in Limbo on this; I can neither move forward independently of any Debian package, nor plan around the expected arrival schedule of the updated Debian package. (Also, the version of MediaWiki in Debian stable does not seem to behave as documented; the only in-Debian documentation I've found directs the sysadmin to configure the package via a Web interface, but on a machine which has had mediawiki 1:1.19.20+dfsg-2.3 installed - with its dependencies, including Apache - and no other special configuration performed, Apache does not expose the described Web interface. Which isn't relevant to this bug, except that it means I can't just start out with the already-packaged version and expect to be able to upgrade that if-and-when the new version gets packaged.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#817244: exim4-base: cron noise re environment
I get this same behavior. > The Debian configuration sets add_environment: > > ametzler@argenau:~$ /usr/sbin/exim4 -bP | grep environment > add_environment = <; PATH=/bin:/usr/bin > keep_environment = $ /usr/sbin/exim4 -bP | grep environment LOG: MAIN WARNING: purging the environment. Suggested action: use keep_environment and add_environment. add_environment = keep_environment = > Are you using Debian's configuration scheme? As far as I know, yes; I certainly don't remember making any changes to it. If my current exim4 configuration is not the Debian default, I'm reasonably sure that's news to me. > ametzler@argenau:~$ /usr/sbin/exim4 -bV | tail -n1 $ /usr/sbin/exim4 -bV | tail -n1 Configuration file is /var/lib/exim4/config.autogenerated > grep -rl _environment /etc/exim4/ $ grep -rl _environment /etc/exim4/ grep: /etc/exim4/passwd.client: Permission denied -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#825104: zotero-standalone: claims to not require any Firefox browser, but depends on firefox packages
Package: zotero-standalone Version: 4.0.29.5+dfsg-1 Severity: minor Dear Maintainer, The long package description of zotero-standalone states in part that: "This package contains the standalone version of Zotero which does not require any Firefox browser." However, the package includes a Depends: line which lists both firefox and firefox-esr. As such, the package cannot in fact be installed without a Firefox browser. If this version of Zotero does in fact require the presence of a Firefox browser on the system, then the package description is incorrect and needs to be revised. (And the description of the program as "standalone" may be argued to be misleading.) If it does not require that, then the Depends on firefox | firefox-esr should be demoted to at most a Recommends, if not removed entirely. I notice that the Depends: line from package version 4.0.22-1 lists several different versions of xulrunner as alternatives, with iceweasel as the last option in the list. It seems possible that it was once possible to install Zotero standalone (with no Firefox browser present), by installing one of the xulrunner packages instead, and that when the xulrunner alternatives were dropped the package description was not altered to match. I do not know why xulrunner was dropped as a dependency alternative; the only reason to do so which springs to my mind is the possibility that separate XULRunner may be going away, and thus not be there to be depended on. If that is the case, then it seems entirely possible that it will in fact cease to be possible to install a standalone version of Zotero at all, in which case the zotero-standalone package should probably go away as well. Note that to date, I have not actually used Zotero myself; I simply noticed this while looking at the package out of interest. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#833621: RFS: libgap-sage/4.8.3+ds-1 [ITP] -- GAP kernel as a C shared library
On 2016-08-09 at 04:36, Mattia Rizzolo wrote: > control: tag -1 moreinfo > control: owner -1 ! > > On Sun, Aug 07, 2016 at 02:49:38AM +0100, Jerome Benoit wrote: >> [1] https://anonscm.debian.org/cgit/debian-science/packages/libgap-sage.git > > d/*.lintian-overrides + d/*.README.Debian: > you use the word 'furnished', which really means "providing > forniture" (or "provided with forniture"), afaik. I'm positive Debian > doesn't ship forniture :D > I think you meant 'provided' there. Actually, this is valid. The first definition of "furnish" from the dict-gcide package is: 1. To supply with anything necessary, useful, or appropriate; to provide; to equip; to fit out, or fit up; to adorn; as, to furnish a family with provisions; to furnish one with arms for defense; to furnish a Cable; to furnish the mind with ideas; to furnish one with knowledge or principles; to furnish an expedition or enterprise, a room or a house. See also e.g. http://www.thefreedictionary.com/furnish for online-dictionary definitions. Although the sense related to providing furniture for a room is the more common usage nowadays, it is in fact secondary to the sense related to providing anything with "anything necessary, useful, or appropriate". -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#854314: youtube-dl: 'Signature extraction failed' on some YouTube videos
Package: youtube-dl
Version: 2016.12.01-1
Severity: normal
Dear Maintainer,
Today, in attempting to download videos from YouTube with youtube-dl, I
have seen some download normally and others produce errors.
(Unfortunately, this happened late enough that the release-freeze
announcement came in while I was testing it.)
Specifically, I have seen the following:
$ youtube-dl https://www.youtube.com/watch?v=4pbMUEHvoAo --verbose
[debug] System config: []
[debug] User config: ['-f', 'best']
[debug] Command-line args:
['https://www.youtube.com/watch?v=4pbMUEHvoAo', '--verbose']
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.12.01
[debug] Python version 3.5.3 - Linux-4.8.0-2-amd64-x86_64-with-debian-9.0
[debug] exe versions: rtmpdump 2.4
[debug] Proxy map: {}
[youtube] 4pbMUEHvoAo: Downloading webpage
[youtube] 4pbMUEHvoAo: Downloading video info webpage
[youtube] 4pbMUEHvoAo: Extracting video information
[youtube] {43} signature length 42.43, html5 player en_US-vflkk7pUE
[youtube] 4pbMUEHvoAo: Downloading player
/yts/jsbin/player-en_US-vflkk7pUE/base.js
ERROR: Signature extraction failed: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 919, in _extract_signature_function
errnote='Download of %s failed' % player_url)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 517, in _download_webpage
res = self._download_webpage_handle(url_or_request, video_id, note,
errnote, fatal, encoding=encoding, data=data, headers=headers, query=query)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 424, in _download_webpage_handle
urlh = self._request_webpage(url_or_request, video_id, note,
errnote, fatal, data=data, headers=headers, query=query)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 404, in _request_webpage
return self._downloader.urlopen(url_or_request)
File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line
2000, in urlopen
req = sanitized_Request(req)
File "/usr/lib/python3/dist-packages/youtube_dl/utils.py", line 513,
in sanitized_Request
return compat_urllib_request.Request(sanitize_url(url), *args, **kwargs)
File "/usr/lib/python3.5/urllib/request.py", line 269, in __init__
self.full_url = url
File "/usr/lib/python3.5/urllib/request.py", line 295, in full_url
self._parse()
File "/usr/lib/python3.5/urllib/request.py", line 324, in _parse
raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: '/yts/jsbin/player-en_US-vflkk7pUE/base.js'
(caused by ValueError("unknown url type:
'/yts/jsbin/player-en_US-vflkk7pUE/base.js'",)); please report this
issue on https://yt-dl.org/bug . Make sure you are using the latest
version; see https://yt-dl.org/update on how to update. Be sure to
call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 919, in _extract_signature_function
errnote='Download of %s failed' % player_url)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 517, in _download_webpage
res = self._download_webpage_handle(url_or_request, video_id, note,
errnote, fatal, encoding=encoding, data=data, headers=headers, query=query)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 424, in _download_webpage_handle
urlh = self._request_webpage(url_or_request, video_id, note,
errnote, fatal, data=data, headers=headers, query=query)
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/common.py",
line 404, in _request_webpage
return self._downloader.urlopen(url_or_request)
File "/usr/lib/python3/dist-packages/youtube_dl/YoutubeDL.py", line
2000, in urlopen
req = sanitized_Request(req)
File "/usr/lib/python3/dist-packages/youtube_dl/utils.py", line 513,
in sanitized_Request
return compat_urllib_request.Request(sanitize_url(url), *args, **kwargs)
File "/usr/lib/python3.5/urllib/request.py", line 269, in __init__
self.full_url = url
File "/usr/lib/python3.5/urllib/request.py", line 295, in full_url
self._parse()
File "/usr/lib/python3.5/urllib/request.py", line 324, in _parse
raise ValueError("unknown url type: %r" % self.full_url)
ValueError: unknown url type: '/yts/jsbin/player-en_US-vflkk7pUE/base.js'
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
line 1005, in _decrypt_signature
video_id, player_url, s
File "/usr/lib/python3/dist-packages/youtube_dl/extractor/youtube.py",
Bug#856247: dict-gcide: Missing definition present upstream: "appeal"
On 2017-02-27 at 03:00, Ritesh Raj Sarraf wrote: > On Sun, 2017-02-26 at 17:20 -0500, The Wanderer wrote:> >> Reinstalling the package (via 'apt-get install --reinstall dict-gcide') >> did not affect this behavior. > >> By contrast, looking up 'appeal' in either the www.dict.org Web-based >> query interface for gcide or the gcide.gnu.org Web-based query interface >> finds three separate definition sections: >> http://www.dict.org/bin/Dict?Form=Dict2=gcide=Appeal >> http://gcide.gnu.org.ua/?q=appeal=Define=. > >> I would expect that looking up "appeal" using the dict command-line >> interface would provide the same results as doing so via the various >> online interfaces. > > Yes. I am aware of the version in Debian. The version in Debian needs to be > updated to the latest. But this won't happen in time for Debian Stretch due to > lack of time on my part. So this is just a matter of "not at current upstream version"? I apologize for the noise, then. The dict.org Web lookup interface claims to be using version 0.48, which is a reasonable match for the Debian-installed version of 0.48.3; I thought I'd seen an 0.48 version number on the gcide.gnu.org.ua interface as well, but now that I look I don't see one, and the savannah.gnu.org project page says that version 0.51 is available (apparently since 2012!). Not having packaged the current upstream release is significantly less of a problem than missing definitions which are in the upstream instance of the packaged version. I'd ask if there's anything I can do to help get the Debian version updated to the latest upstream release, but the fact that we're past the freeze date means there's probably not much point. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#856247: dict-gcide: Missing definition present upstream: "appeal"
Package: dict-gcide
Version: 0.48.3
Severity: normal
Dear Maintainer,
When I run the following command, I get (in part) the following output:
$ dict -d gcide repeal
[...]
>From The Collaborative International Dictionary of English v.0.48 [gcide]:
Repeal \Re*peal"\ (r?-p?l"), v. t. [imp. & p. p. {Repealed}
(-p?ld"); p. pr. & vb. n. {Repealing}.] [OF. repeler to call
back, F. rappeler; pref. re- re- + OF. apeler, F. appeler, to
call, L. appellare. See {Appeal}, and. cf. {Repel}.]
[...]
This points to a definition of "appeal", marked as being available for
lookup. However, when I attempt to look up "appeal", I get no results:
$ dict -d gcide appeal
No definitions found for "appeal"
Similarly, manually grepping through /usr/share/dictd/gcide.* does not
locate any definitions for "Appeal".
Reinstalling the package (via 'apt-get install --reinstall dict-gcide')
did not affect this behavior.
By contrast, looking up 'appeal' in either the www.dict.org Web-based
query interface for gcide or the gcide.gnu.org Web-based query interface
finds three separate definition sections:
http://www.dict.org/bin/Dict?Form=Dict2=gcide=Appeal
http://gcide.gnu.org.ua/?q=appeal=Define=.
I would expect that looking up "appeal" using the dict command-line
interface would provide the same results as doing so via the various
online interfaces.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dict-gcide depends on:
ii dictd [dict-server] 1.12.1+dfsg-4
dict-gcide recommends no packages.
Versions of packages dict-gcide suggests:
ii dict-wn 1:3.0-33
-- no debconf information
Bug#841837: apt-listchanges: feature request: combine identical changelog entries from multiple packages
Package: apt-listchanges Version: 3.5 Severity: wishlist Dear Maintainer, On a semi-frequent basis - usually when there is an automatic mass binary rebuild on the buildds, in response to a transition against a common dependency package - running a dist-upgrade will result in being shown a flood of changelog entries which are essentially identical, differing only in package name, package version, and entry timestamp. The pattern which such entries usually follow is: * Binary-only non-maintainer upload for [architecture]; no source changes. * Rebuild against [depended-on package]. (At the moment, I am also seeing a mass set of identical entries in an apparently maintainer-initiated update to set of KDE-related packages; a couple of dozen or so packages seem to have been updated simultaneously to the same version, with identical or near-identical changes in each. This sort of issue thus is not exclusive to such automatic rebuilds, it's just most common there.) This mass repetition of identical entries makes it difficult to spot changelog entries for other packages in the middle of the flood - especially since these near-identical entries are often not grouped all together, but scattered around throughout the apt-listchanges report, such that other packages' entries sometimes appear in the middle of a set of the identical entries. I would like to request that there be implemented a mode for apt-listchanges in which, if two changelog entries which are to be reported in a single apt-listchanges run are identical except for package name, package version, and timestamp, the changelog body is only shown once, and the packages and versions (and possibly timestamps) which use that body are listed together next to that single instance. It's fine (and probably best, at least to start with) if this mode is not the default, as long as it can be enabled in an appropriate configuration file, and the way to enable it is documented in the man page. This is, of course, not an urgent request. I regret that I lack sufficient familiarity with the apt-listchanges code (and even the language it's written in) to be comfortable with trying to implement this myself; that may change, but even if it doesn't, I still want to record the existence of the request. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages apt-listchanges depends on: ii apt1.3.1 ii debconf [debconf-2.0] 1.5.59 ii debianutils4.8 ii python3-apt1.1.0~beta5 pn python3:any ii ucf3.0036 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii chromium [www-browser] 53.0.2785.143-1 ii dillo [www-browser]3.0.5-2+b1 ii elinks [www-browser] 0.12~pre6-11+b3 ii exim4-daemon-light [mail-transport-agent] 4.87-3+b1 ii iceweasel [www-browser]38.8.0esr-1~deb8u1 ii kterm [x-terminal-emulator]6.2.0-46.1+b1 ii links [www-browser]2.13-1 ii lynx [www-browser] 2.8.9dev9-1 ii python3-gi 3.22.0-1 ii w3m [www-browser] 0.5.3-29 ii xterm [x-terminal-emulator]327-1 -- debconf-show failed
Bug#851819: ERROR: wget failed to download http://people.debian.org/~bartm/...
It's now been well over two months since this bug was filed. Not only has the problem not been fixed, another Flash release has been made upstream in the interim; I've been retrying this once a day so that I'll notice as soon as a fix gets put in place, and it's now reporting failure to download the checksum file for 25.0.0.127 (vs. the original report's 24.0.0.194). Getting this working in the short term should be nearly trivial for anyone who has write access to the ~/bartm/ Webspace. Does anyone other than Bart Martens himself have that access? If so, someone with that access should put the necessary file into place, so that the package is once again installable at least in the short term. If not, someone should adopt the package (or at least NMU it, though I suspect this would be out of scope for an NMU) and either drop the requirement for this external checksum entirely (making it optional would be fine), or alter the checksum lookup to point to a location which is write-accessible to a sufficiently large pool of people that one of them can be expected to respond to future Flash updates within a week or so. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#856813: pidgin: AIM accounts will require 2.12 as of 2017-03-28
Package: pidgin Version: 2.11.0-3 Severity: normal Dear Maintainer, As has been reported on various tech-news sites, AOL is dropping support for older versions of the authentication methods which third-party clients such as Pidgin use to connect to the AOL Instant Messenger service. This dropping of support is scheduled to take effect on March 28th, well before the expected release of Debian stretch. The official word from upstream is that version 2.12 of Pidgin will include support for the newer authentication methods involved, and that this version is due for release in about a week. To release Debian stretch with a version of Pidgin which no longer supports connecting to one of the major instant-messaging networks, despite a version which does still support that being available, would obviously be undesirable. However, as we are already within the release freeze, including the fix is not as straightforward as simply packaging the new upstream version directly after its release. Please take whatever measures are appropriate to ensure that a version of pidgin which supports the new required authentication mode for AIM either ships with Debian stretch, or is available to users of stretch as promptly as possible after the release occurs. If such a version can be available (even if from another repository) to users of testing in the meantime, that would be even better. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages pidgin depends on: ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.16-1 ii libdbus-glib-1-20.108-2 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype62.6.3-3+b2 ii libgadu31:1.12.1-4 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-02.50.3-1 ii libgstreamer1.0-0 1.10.3-1 ii libgtk2.0-0 2.24.31-2 ii libgtkspell02.0.16-1.1 ii libice6 2:1.0.9-1+b1 ii libpango-1.0-0 1.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpangoft2-1.0-0 1.40.3-3 ii libpurple0 2.11.0-3 ii libsm6 2:1.2.2-1+b1 ii libx11-62:1.6.4-3 ii libxss1 1:1.2.2-1 ii perl-base [perlapi-5.24.1] 5.24.1-1 ii pidgin-data 2.11.0-3 Versions of packages pidgin recommends: ii gstreamer1.0-alsa 1.10.3-1 ii gstreamer1.0-libav 1.10.3-1 ii gstreamer1.0-plugins-base 1.10.3-1 ii gstreamer1.0-plugins-good 1.10.3-1 Versions of packages pidgin suggests: ii libsqlite3-0 3.16.2-2 -- debconf-show failed
Bug#851819: ERROR: wget failed to download http://people.debian.org/~bartm/...
What is the justification for marking this bug as 'important', down from the previous 'grave'? As things stand, this package is actually uninstallable - or rather, it will fail in the postinst step which is what actually downloads and installs the current version of the plugin (since the package itself is just a downloader). I confirmed this by testing in a chroot. A release-blocker severity seems entirely appropriate to me under those circumstances; making a Debian release which includes a package which cannot be installed does not seem remotely ideal, even if the problem can be fixed without changing the contents of the package repositories. If there are plans in place to make sure that that problem is fixed before the release, and that it is dealt with promptly whenever it recurs after the release, that's one thing - but if that's the case, those plans should be stated publicly (preferably on the bug report), and to date that has not happened AFAICT. Te actual problem here is that the functionality of this internal update tool depends not only on something external both to the local machine and to the package system, but on something that is specific to one particular person. If I'm reading things correctly, people.debian.org/~bartm/ is the personal Debian web space of Bart Martens, who is listed as the maintainer for this package; this would seem to imply that _no one else_, except perhaps the sysadmins of that server, can update this. This seems like an undesirably fragile design. If external checksum files for this download are to be required, IMO they should be hosted on a Webspace particular to the package rather than to the maintainer, and any DD should have the ability to update them. Maintaining a hard requirement for external checksum files is one matter when the maintainer who updates them is on the ball and gets them updated promptly after a new version is available (i.e., within a week at most) - but when the checksum files have still not been updated not only more than a week after the release of the new version, but a good month and a half after the bug reporting their absence was opened, that represents a less acceptable situation. I subscribe to a half-dozen or so Debian discussion mailing lists, and I have not seen any sign of life from Bart Martens since September of 2016 - close to six months ago. It's far from impossible that he's active elsewhere and I've just missed noticing those areas, but at some point this starts to look like an inactive maintainer. Unfortunately, the normal channels for dealing with a nonresponsive maintainer mostly seem to assume that the proper solution to the problem (assuming the maintainer remains nonresponsive) is for someone else to adopt the package - but in this case, that wouldn't directly help, since the problem is actually in the maintainer's private Debian Webspace and external to the package itself. At best, a new maintainer could tweak the script to A: point to a different Webspace - which would only redirect the problem, in the long term - or B: (optionally) skip the validation entirely, which is potentially problematic in its own way. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
