Bug#1012612: texinfo: Info documentation links to missing "pod2texi" manual
On Mon, Jan 09, 2023 at 07:45:04AM +0100, Hilmar Preuße wrote: > I've uploaded texinfo 7.0.1-3 to Debian experimental. Could you install > it and check if it solves the issue? Thanks! I downloaded the texinfo and texinfo-lib packages from the experimental repository and installed them. The issue is not solved: - /usr/share/info/dir still mentions "(pod2texi)Invoking pod2texi." - /usr/share/info/texinfo.info.gz still includes that link in its START-INFO-DIR-ENTRY section. - There's still no /usr/share/info/pod2texi.info(.gz) file Thank you for your packaging work! Tim.
Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer
I've done some more research, and come up with more details. As I understand it, the original X-COM for DOS was released as version 1.0, then had a bunch of fixes up to version 1.4. Later, a "collector's edition" was released which ported the game to Windows and included even more fixes. PCGamingWiki says[1] that the GOG build is straight up version 1.4, bundled with DOSBox to make it run on modern OSs. It also says that the Steam build uses the 1.4 engine for DOS, but with some Collector's Edition data files. [1]: https://pcgamingwiki.com/wiki/X-COM:_UFO_Defense#Availability I found some details on the files that shipped with the Collector's Edition, so together with the official patches I acquired earlier, I believe I can trace all these variations. Going back to the original list of missing files... # assets not in setup_xcom_ufo_defense_2.0.0.4.exe: # group_members: | # 44288 6a2b1ec8182f5025ee505c6949356925 GEODATA/BIGLETS.DAT # 12456 5ae490e16959e1961071f0172c793c94 GEODATA/SMALLSET.DAT These files come from the Collector's Edition. Compared to the 1.4 versions, they add extra characters that weren't in the original DOS character set[2][3]. I imagine the DOS engine doesn't actually use them, but OpenXCOM might. [2]: https://www.ufopaedia.org/index.php/BIGLETS.DAT [3]: https://www.ufopaedia.org/index.php/SMALLSET.DAT # 46601 1770cf9f3a18350c7afa54b0e271c359 GEODATA/ENGLISH.DAT # 52672 eacbbca8d2de655cda7aa403702bec46 GEODATA/FRENCH.DAT # 53587 1cd8dd5069970d0f2a6983339057a34b GEODATA/GERMAN.DAT These files come from the Collector's Edition. Comparing them to the 1.4 versions, the only differences are that the message "Quit to DOS" (or its translated equivalent) has been changed to "Quit" (or translated etc.). # 93853 7194c1480e6ce2d3e188133ece4fdefb SOUND/ROLAND.CAT As discussed previously, this file comes from the 1.4 patch. Looking at the original list of obsolete files: # obsolete: # group_members: | # 32768 9f20ed66008a2fbc055c10db74c44307 GEODATA/BIGLETS.DAT?orig # 9216 3943027ebeab34adfa3d31c04adc886d GEODATA/SMALLSET.DAT?orig These are the versions from the GOG release, and since they doesn't appear in any other patches, presumably from the original 1.0 release. # 46608 a28031075f0e531d5896ffca8125d7bc GEODATA/ENGLISH.DAT?orig # 52679 1538fc2f7d85aa81d06b4bff319d9902 GEODATA/FRENCH.DAT?orig # 53594 342570230da352242219d6fea289d8b1 GEODATA/GERMAN.DAT?orig These are the versions from the 1.2 and 1.3 patches. Lastly, the mysterious extra ROLAND.CAT. As I understand it: - 1.0 through 1.3 came with music data for AdLib (in ADLIB.CAT) and Roland CM-32 (in ROLAND.CAT) devices. - 1.4 switched to a different music engine[4], which used different formats. ADLIB.CAT was updated to use the new format, and a new GM.CAT was supplied to support General MIDI devices, but ROLAND.CAT was left untouched. - Therefore, if you tried to use Roland CM-32 support in 1.4, the game would hang[5] as the new music engine tried to interpret the ROLAND.CAT file in the old format. - A fan reverse-enginered the old and new file-formats and repackaged the Roland music data from 1.3 in the format 1.4 expects[6], which is the version bundled with the GOG release. - However, OpenXCOM does not use or care about ROLAND.CAT, only GM.CAT, so there's no point packaging it at all. [4]: https://www.ufopaedia.org/index.php/SOUND [5]: https://pcgamingwiki.com/wiki/X-COM:_UFO_Defense#Game_hang_when_attempting_to_use_the_MT-32_in_version_1.4_.28DOS.29 [6]: https://www.vogons.org/viewtopic.php?t=21542l=32 On Sat, Feb 02, 2019 at 11:06:29AM +, Simon McVittie wrote: > On Sat, 02 Feb 2019 at 20:17:38 +1100, Tim Allen wrote: > > I found a site[1] claiming to host the official 1.1, 1.2, 1.3 and 1.4 > > patches, alongside a bunch of other unofficial patches. It turns out > > that the ROLAND.CAT that game-data-packager was looking for (MD5: > > 7194c14...) is part of the UFO 1.4 update. The site says[2]: > > > > # This patch fixes many stability issues, some game stopping research > > # bugs And removed the startup copy protection. However it also replaces > > # the sounds with ones that are not as good as the originals. > > Should we be preferring to package the unpatched ROLAND.CAT (143866 bytes, as > shipped by GOG) rather than the v1.4 ROLAND.CAT (93853 bytes, as shipped by > Steam) if we can see both, then? The YAML syntax lets us prefer one version > over others. Now that I know OpenXCOM doesn't use it, there's probably no point packaging it at all. Perhaps OpenXCOM might use it at some point in the future, but that seems very unlikely given that GM.CAT is almost exactly the same thing, and ADLIB.CAT is probably the one people care about for nostalgic reasons. > > The B
Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer
On Thu, Jan 31, 2019 at 09:38:51AM +, Simon McVittie wrote: > On Wed, 19 Dec 2018 at 13:47:54 +1100, Timothy Allen wrote: > > I extracted the installer with innoextract, and manually copied the > > directories listed for Nightly builds in the OpenXcom documentation[1] > > to the place where OpenXcom looks, and successfully began a new game > > and played a mission. I don't know how exhaustively OpenXcom checks its > > datafiles at startup, but it seemed good to me. > > Thanks. It looks as though the GOG package contains different > (original/unpatched?) versions of ROLAND.CAT and the five GEODATA files in the > "obsolete" group. I don't know of anywhere that we can download > replacement/patched/updated copies of those files, but if the ones shipped by > GOG work in practice, presumably they're good enough? I found a site[1] claiming to host the official 1.1, 1.2, 1.3 and 1.4 patches, alongside a bunch of other unofficial patches. It turns out that the ROLAND.CAT that game-data-packager was looking for (MD5: 7194c14...) is part of the UFO 1.4 update. The site says[2]: # This patch fixes many stability issues, some game stopping research # bugs And removed the startup copy protection. However it also replaces # the sounds with ones that are not as good as the originals. The BIGLETS.DAT and SMALLSET.DAT files don't appear in any patch, official or unofficial, expected hash or otherwise, so I have no idea where they came from, or why the Steam and GOG releases differ. The "obsolete" ENGLISH.DAT, FRENCH.DAT and GERMAN.DAT that the GOG release includes come from the 1.2 and 1.3 official patches. The versions that game-data-packager expected aren't present. I mention this all just for completeness; thank you for updating the game-data-packager package! [1]: http://www.strategycore.co.uk/files/ufo-enemy-unknown/patches/ [2]: http://www.strategycore.co.uk/files/ufo-1.4/
Bug#693669: Lower wine dependency to a recommendation
I'd like to request that this bug be re-opened, because POL's hard dependency on Wine makes the package substantially less useful than it would otherwise be. My current system is (like many other people's) amd64, and so I'm using Debian's multiarch feature to install wine:i386 to run games with. Unfortunately, due to the way multiarch dependencies work right now, playonlinux's wine dependency can only be satisfied by wine:amd64 which doesn't support any of the (32-bit) apps I want to run. So, I have to choose between having a Debian-supplied Wine and running my own playonlinux, or having a Debian-supplied playonlinux and using their generic 32-bit Wine builds. I'd really like to have Debian everything. Even better would be if the Debian package for playonlinux supported both the wine:i386 (which provides a 'wine' binary) and wine-unstable:i386 (which provides a 'wine-unstable' binary). Thanks for your time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694744: New upstream version 1.1.1
I just heard about bugs-everywhere today, and it sounds like an interesting project, so I thought I'd look up its status in Debian. According to message 39[1], the main thing preventing bugs-everywhere from being packaged by Debian is the lack of the numpydoc package that teaches Sphinx how to read numpy docstrings, as described in bug 559916. Looking at that bug[2] it seems a python-numpydoc package was submitted to sid on 2012-12-10, and it is currently sitting happily there[3]. Obviously it won't migrate to testing because of the freeze, but that's a start. What else needs to be done to get bugs-everywhere back into Debian? [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694744#39 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559916#125 [3]: http://packages.qa.debian.org/n/numpydoc/news/20121210T210038Z.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615922: [PATCH] Reset exit status before sourcing a file.
The POSIX specification for the dot command[1] states:
EXIT STATUS
Returns the value of the last command executed, or a zero exit
status if no command is executed.
If an empty file is sourced, then no command is executed, and hence
the exit status should be zero. If the exit status is not reset before
sourcing an empty file, the exit status of the previous command leaks
through. Here's a simple test case:
false
. /dev/null
[ $? = 0 ] echo Success || echo Failure
This behaviour becomes more problematic when combined with set -e. Consider
the following snippet:
if [ $FILETYPE != shell ]; then
run_external_script $FILEPATH
else
. $FILEPATH
fi
Assume set -e, that FILETYPE is set to shell and that FILEPATH points to
an empty file. Since the condition returns a non-zero exit status (which is
protected from set -e by the if statement), the shell runs the else branch
of the code, sources the empty file, and then checks the last exit status
again. Because the exit status from the condition hasn't been cleared, set -e
causes the shell to exit even though no un-handled error has occurred.
[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/dot.html
Signed-off-by: Timothy Allen screwt...@froup.com
---
src/main.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/main.c b/src/main.c
index 1735c67..b4c07e9 100644
--- a/src/main.c
+++ b/src/main.c
@@ -318,6 +318,7 @@ int
dotcmd(int argc, char **argv)
{
int status = 0;
+ exitstatus = 0;
if (argc = 2) {/* That's what SVR2 does */
char *fullname;
--
1.7.1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539108: bdf2psf does not handle empty bitmaps
On Wed, Nov 18, 2009 at 08:46:37PM +0200, Anton Zinoviev wrote: On Sat, Nov 14, 2009 at 10:56:34PM +1100, Tim Allen wrote: On Wed, Nov 11, 2009 at 06:40:19PM +0200, Anton Zinoviev wrote: I am unable to reproduce this - the space symbol in the psf font I obtain is correct. Can you attach your vera-mono-12.bdf and vera-mono-12.psf? Please find both attached. Unfortunately again I am unable to reproduce this. I used the very same command you put in your bug report and the result is a font with proper space character: bdf2psf vera-mono-12.bdf /usr/share/bdf2psf/standard.equivalents /usr/share/bdf2psf/required.set+/usr/share/bdf2psf/useful.set 256 vera-mono-12my.psf It is true that I am using a newer version of bdf2psf but I think there were no changes in the bdf2psf script since version 1.44 you reported. Are you using the same command in order to convert the font? When I generated the vera-mono-12.psf that I attached, I copied-and-pasted the command directly from this bug report. When you use that command to generate a .psf from the .bdf attached to the bug, does your generated .psf match the .psf attached to the bug? When you load the font, are you using the default VGA text console, or a frame-buffer console? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
On Fri, Oct 23, 2009 at 01:24:00PM +0100, Nicholas Marriott wrote: It appears screen-256color converts colours 8-15 into 90-97 which are an extension designed to allow bright colours without the bold attribute (bold font). Looking at xterm's ctlseqs.pdf, it refers to these 90-97 and 100-107 codes as aixterm codes; I suppose before xterm invented the 88- and 256-color hack, IBM had their own ideas about how to extend ECMA48 beyond 8 colours. Looking briefly at xterm-256color in terminfo.src I can't see why it doesn't do the same but I don't have time or inclination to dig into it right now. There's a family of screen terminfo entries, and a family of xterm terminfo entries; if screen-256color inherits from screen-16color but xterm-256color overrides setab and setaf entirely, that might explain it. I'm not sure how to go about checking that, though, and as you say, it hardly matters. This appears to be yet another terminal capability without a terminfo flag allowing it to be detected so tmux can't make use of it explicitly (ie pass it through if it is supported). However, converting it into colours 8-15 (which should then be converted into 3x+bold for non-256-colour terminals) should hopefully do the trick. I applied your patch to the Debian source, rebuilt the package and installed it, and my color-test script works fine now as does my mutt configuration. Thank you very much! Tim. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550701: tmux does not support screen-256color like it claims
On Mon, Oct 12, 2009 at 01:14:49PM +0200, Karl Ferdinand Ebert wrote: I could reproduce this behaviour but not the issue with mutt. Could you give more detail on mutt's screen-corruption? My problem was that with TERM=xterm-256color inside tmux, mutt would draw rows at the wrong place as you scrolled through the message list. However, I first observed this behaviour with tmux 0.8; it doesn't seem to be a problem with 1.0. tmux isn't quite compatible with TERM=xterm-256color, though. xterm implements 'background color erase', which means that the following command paints the entire terminal green: tput setab 2; tput clear tmux doesn't support 'background color erase', which means that the above command results in a terminal in the default colours. This shows up in mutt in the very first line, where keyboard shortcuts are displayed - if this line has a background colour, and TERM=xterm-256color (or any color xterm variant) the background colour extends all the way across the window in screen and gnome-terminal, while in tmux the background-color stops at the right-most text on the line. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539108: bdf2psf does not handle empty bitmaps
Package: bdf2psf
Version: 1.44
Severity: important
In the BDF font format, each glyph's shape is defined in terms of a
bitmap of certain dimensions, located at a certain offset from the
origin. For example, in a font that uses a 12x24 pixel character cell,
the apostrophe glyph (') might only cover 2x4 pixels, and so it could be
represented as a 2x4 bitmap offset upward from the origin, rather than a
12x24 bitmap with no offset and a large number of blank pixels. A wholly
blank glyph could legitimately be represented by a 0x0 bitmap.
This bitmap shrink-wrapping is performed by many tools that deal with
BDF fonts, including gbdfed and otf2bdf. bdf2psf handles it well, except
for the degenerate 0x0 bitmap case.
Steps to reproduce:
1. Get a sample BDF file with an empty bitmap for the U+0020 SPACE glyph:
sudo aptitude install ttf-bitstream-vera otf2bdf
otf2bdf -r 72 -p 12 -c C \
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf |
sed -e s/AVERAGE_WIDTH.*/AVERAGE_WIDTH 80/ vera-mono-12.bdf
(the sed invocation is required because bdf2psf sanity-checks the
AVERAGE_WIDTH property rather than the font bounding box, or checking
the DWIDTHs of the glyphs that it actually uses)
2. Convert the BDF file to a PSF file:
bdf2psf vera-mono-12.bdf \
/usr/share/bdf2psf/standard.equivalents \
/usr/share/bdf2psf/required.set+/usr/share/bdf2psf/useful.set \
256 \
vera-mono-12.psf
3. Load the resulting psf file:
consolechars -f vera-mono-12.psf
Expected result:
Character cells containing a U+0020 SPACE glyph should be blank.
Actual result:
Character cells containing a U+0020 SPACE glyph contain random noise, as
though they displayed uninitialised memory.
Note:
If you apply the following patch to the BDF file and re-convert it to
PSF, the resulting font works as expected:
--- vera-mono-12.bdf2009-07-29 17:19:50.0 +1000
+++ vera-mono-12-fixed.bdf 2009-07-29 17:20:38.0 +1000
@@ -31,8 +31,9 @@
ENCODING 32
SWIDTH 583 0
DWIDTH 7 0
-BBX 0 0 0 0
+BBX 0 1 0 0
BITMAP
+00
ENDCHAR
STARTCHAR 0021
ENCODING 33
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages bdf2psf depends on:
ii perl 5.10.0-24 Larry Wall's Practical Extraction
bdf2psf recommends no packages.
bdf2psf 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#516945: cups: Serial backend permissions problem
Package: cups Version: 1.3.8-1lenny4.1 Severity: normal *** Please type your report below this line *** Fresh install of Lenny, serial printer added with lpadmin -p DEC-LA100 -v serial:/dev/ttyS0?baud=9600+size=8+parity=none+flow=hard -D DEC Letterprinter 100 -P textonly.ppd Print fails with E [24/Feb/2009:08:18:48 +] PID 4993 (/usr/lib/cups/backend/serial) stopped with status 22! in log. # ls -l /dev/ttyS? crw-rw 1 root dialout 4, 64 2009-02-24 15:36 /dev/ttyS0 crw-rw 1 root dialout 4, 65 2009-02-24 16:09 /dev/ttyS1 crw-rw 1 root dialout 4, 66 2009-02-24 14:15 /dev/ttyS2 crw-rw 1 root dialout 4, 67 2009-02-24 14:15 /dev/ttyS3 Restarting cups after each change: chown root.lp /dev/ttyS0 -does not fix. chmod 666 /dev/ttyS0 -does not fix. Return /dev/ttyS0 to original permissions/ownership. # ls -l /usr/lib/cups/backend/serial -rwxr--r-- 2 root root 14900 2009-01-13 16:53 /usr/lib/cups/backend/serial (Received theory being serial should run as root with 744, or 700, permissions) chmod 700 /usr/lib/cups/backend/serial -fixes problem. Note permissions of serial in /usr/lib/cups/backend-available are 700. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.26-1-486 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cups depends on: ii adduser3.110 add and remove users and groups ii cups-common1.3.8-1lenny4.1 Common UNIX Printing System(tm) - ii debconf [debconf-2 1.5.24Debian configuration management sy ii ghostscript8.62.dfsg.1-3.2lenny0 The GPL Ghostscript PostScript/PDF ii libavahi-compat-li 0.6.23-3lenny1Avahi Apple Bonjour compatibility ii libc6 2.7-18GNU C Library: Shared libraries ii libcups2 1.3.8-1lenny4.1 Common UNIX Printing System(tm) - ii libcupsimage2 1.3.8-1lenny4.1 Common UNIX Printing System(tm) - ii libdbus-1-31.2.1-5 simple interprocess messaging syst ii libgnutls262.4.2-6 the GNU TLS library - runtime libr ii libkrb53 1.6.dfsg.4~beta1-5MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libpam0g 1.0.1-5 Pluggable Authentication Modules l ii libpaper1 1.1.23+nmu1 library for handling paper charact ii libslp11.2.1-7.5 OpenSLP libraries ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii perl-modules 5.10.0-19 Core Perl modules ii poppler-utils [xpd 0.8.7-1 PDF utilitites (based on libpopple ii procps 1:3.2.7-11/proc file system utilities ii ssl-cert 1.0.23simple debconf wrapper for OpenSSL Versions of packages cups recommends: ii avahi-utils 0.6.23-3lenny1 Avahi browsing, publishing and dis ii cups-client 1.3.8-1lenny4.1Common UNIX Printing System(tm) - ii foomatic-filters 3.0.2-20080211-3.2 OpenPrinting printer support - fil ii smbclient 2:3.2.5-4 a LanManager-like simple client fo Versions of packages cups suggests: ii cups-bsd1.3.8-1lenny4.1 Common UNIX Printing System(tm) - pn cups-driver-gutenprint none (no description available) pn cups-pdfnone (no description available) ii foomatic-db 20080211-2+nmu1 OpenPrinting printer support - dat ii foomatic-db-engine 3.0.2-20080211-1 OpenPrinting printer support - pro pn hplip none (no description available) pn xpdf-korean | xpdf-japa none (no description available) -- debconf information: cupsys/raw-print: true cupsys/backend: ipp, lpd, parallel, scsi, serial, socket, usb, snmp, dnssd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492488: Reproduction of the Iceweasel crashes.
On Sat, Oct 25, 2008 at 11:56:21PM +0900, Charles Plessy wrote: Dear Michele, Michael, Roberto, Nathan, Tim, Josh, and Riku. I am contacting you because you reported crashes with Iceweasel. Do you still have this problem? If yes, are you running an up-to-date Lenny system now or can you upgrade? I was having crash-on-startup issues with Iceweasel 3 on PowerPC, especially the RC builds from Experimental. Happily, these crashes seemed to go away about the time that Iceweasel 3 was added to Unstable. Checking some logs, it seems that my bug was #482415 and I got it working in message 188: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482415#188 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500531: gbdfed: New upstream release: 1.4patch1
Package: gbdfed Version: 1.3patch1-2 Severity: wishlist I see that a newer version of gbdfed is available upstream than is packaged in Debian: http://www.math.nmsu.edu/~mleisher/Software/gbdfed/ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (499, 'experimental') Architecture: powerpc (ppc64) Kernel: Linux 2.6.26-1-powerpc64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gbdfed depends on: ii libc6 2.7-13 GNU C Library: Shared libraries ii libfreetype6 2.3.7-2FreeType 2 font engine, shared lib ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libgtk2.0-0 2.12.11-3 The GTK+ graphical user interface ii libpango1.0-0 1.20.5-2 Layout and rendering of internatio ii libx11-6 2:1.1.5-2 X11 client-side library gbdfed recommends no packages. gbdfed suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490010: Pasting text from Pidgin into itself produces gibberish
This happens every time I paste text from a Pidgin chat window into the text-box at the bottom. Steps to reproduce: - Double click on a contact in your buddy list to open a chat window. - In the text box at the bottom, type wocka wocka (or anything else) - Select the text with the mouse, then right-click and choose 'copy'. - Click after the text to deselect it. - Right-click in the empty space, then choose Paste as plain text. The text wocka wocka should appear. - Right-click in the empty space again, then choose Paste. Expected result: - A third copy of the text wocka wocka should appear. Actual result: - The text 眀漀挀欀愀 眀漀挀欀愀 appears. I notice that the first character of the gibberish replacement is U+7700, while the intended text begins with the character U+0077. Given that both I and the original reporter are using the PowerPC architecture, I strongly suspect Pidgin has some bad endianness assumptions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482415: Crash Fixed
On Wed, Jun 11, 2008 at 07:33:40AM +0200, Mike Hommey wrote: I'd prefer to have confirmation from everyone reporting this bug that it is indeed fixed. Having waited for iceweasel-3.0~rc2-2 to be built for powerpc, I upgraded to it last night. After some wrestling with aptitude, I wound up purging every package whose name involved 'iceweasel' or 'xulrunner' (except the 1.8 version, which epiphany requires), then installing 'iceweasel' and 'iceweasel-dbg' from scratch. Iceweasel still crashes on startup, but now it has a different traceback (for some reason, it no longer triggers bug-buddy, so this is from iceweasel -g): Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf7fed220 (LWP 3108)] 0x0fd6441c in ptmalloc_init () from /lib/libc.so.6 (gdb) bt full #0 0x0fd6441c in ptmalloc_init () from /lib/libc.so.6 No symbol table info available. #1 0x0fd68e00 in memalign_hook_ini () from /lib/libc.so.6 No symbol table info available. #2 0x0fd68b70 in memalign () from /lib/libc.so.6 No symbol table info available. #3 0xf7fe04f0 in __tls_get_addr () from /lib/ld.so.1 No symbol table info available. #4 0x0d9e38a0 in ?? () from /lib/libselinux.so.1 No symbol table info available. #5 0x0d9dbe48 in ?? () from /lib/libselinux.so.1 No symbol table info available. #6 0x0d9d30f0 in ?? () from /lib/libselinux.so.1 No symbol table info available. #7 0x0d9e7e94 in _fini () from /lib/libselinux.so.1 No symbol table info available. #8 0xf7fdd698 in _dl_fini () from /lib/ld.so.1 No symbol table info available. #9 0x0fd1e4dc in exit () from /lib/libc.so.6 No symbol table info available. #10 0x0fd02708 in generic_start_main () from /lib/libc.so.6 No symbol table info available. #11 0x0fd028c0 in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #12 0x in ?? () No symbol table info available. Some more information: -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (499, 'experimental') Architecture: powerpc (ppc64) Kernel: Linux 2.6.25-2-powerpc64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iceweasel depends on: ii debianutils 2.29 Miscellaneous utilities specific t ii fontconfig2.6.0-1generic font configuration library ii libc6 2.7-12 GNU C Library: Shared libraries ii libgcc1 1:4.3.1-2 GCC support library ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libgtk2.0-0 2.12.10-2 The GTK+ graphical user interface ii libnspr4-0d 4.7.1-3NetScape Portable Runtime Library ii libstdc++64.3.1-2The GNU Standard C++ Library v3 ii procps1:3.2.7-8 /proc file system utilities ii psmisc22.6-1 Utilities that use the proc filesy ii xulrunner-1.9 1.9~rc2-4 XUL + XPCOM application runner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482415: Crash Fixed
For the record, I can run the xulmine demo from here: http://benjamin.smedbergs.us/xulrunner/ ...perfectly well, once I unzip it and change the version-numbers in application.ini. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482415: Crash Fixed
On Wed, Jun 25, 2008 at 02:40:47PM +0200, Mike Hommey wrote: On Wed, Jun 25, 2008 at 10:22:24PM +1000, Tim Allen [EMAIL PROTECTED] wrote: Iceweasel still crashes on startup, but now it has a different traceback (for some reason, it no longer triggers bug-buddy, so this is from iceweasel -g): This one is not a crash on startup, but at shutdown, and is a known issue. It will be fixed in next upload of xulrunner. Please make sure you don't have another iceweasel process (firefox-bin, actually) running before running iceweasel, because the crash you are seeing usually only occurs when iceweasel is already running, and iceweasel is opening a new window with the existing instance. I ran: sudo pgrep -fl 'xul|ice|fire' ...but the only results mentioned 'firewire' and '/dev/input/mice', which I assume are irrelevant. After some prompting on IRC, I tried: rm -rf ~/.mozilla; iceweasel -no-remote -ProfileManager ...and the Profile Manager appeared and created a shiny new profile for me. After I created a new profile, it seems I can now run 'iceweasel' any time I want and it works. Thanks for all your help! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482415: iceweasel: crashes immediately upon startup
This same thing happens for me on PowerPC, as well - with the exact same backtrace from bug-buddy. When started with the following command-line: rm -rf ~/.mozilla/ iceweasel -safe-mode ...I get this output: /usr/lib/bug-buddy/firefox-bin: No such file or directory. Cannot access memory at address 0x15 No windows or dialogs ever appear. It worries me a little that the innermost iceweasel stack-frame looks like it's trying to reflow a 0x0 box at (6000,6000). -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (900, 'unstable'), (700, 'experimental'), (500, 'stable') Architecture: powerpc (ppc64) Kernel: Linux 2.6.24-1-powerpc64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iceweasel depends on: ii debianutils 2.28.4 Miscellaneous utilities specific t ii fontconfig2.5.0-2generic font configuration library ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-3 GCC support library ii libglib2.0-0 2.16.3-1 The GLib library of C routines ii libgtk2.0-0 2.12.9-2 The GTK+ graphical user interface ii libnspr4-0d 4.7.0-2NetScape Portable Runtime Library ii libstdc++64.3.0-3The GNU Standard C++ Library v3 ii procps1:3.2.7-8 /proc file system utilities ii psmisc22.6-1 Utilities that use the proc filesy ii xulrunner-1.9 1.9~b5-4 XUL + XPCOM application runner System: Linux 2.6.24-1-powerpc64 #1 SMP Thu Mar 27 13:07:07 CET 2008 ppc64 X Vendor: The X.Org Foundation X Vendor Release: 10400090 Selinux: No Accessibility: Disabled GTK+ Theme: Murrine Brave Icon Theme: Tango Memory status: size: 90230784 vsize: 90230784 resident: 27197440 share: 19324928 rss: 27197440 rss_rlim: 18446744073709551615 CPU usage: start_time: 1211602108 rtime: 62 utime: 53 stime: 9 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/lib/bug-buddy/firefox-bin' [Thread debugging using libthread_db enabled] [New Thread 0xf7fd (LWP 7573)] [New Thread 0xf65fc4c0 (LWP 7578)] [New Thread 0xf76954c0 (LWP 7575)] [New Thread 0xf7e954c0 (LWP 7574)] 0x0fdbe350 in waitpid () from /lib/libc.so.6 #0 0x0fdbe350 in waitpid () from /lib/libc.so.6 #1 0x0e452a10 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0 #2 0x0e452c4c in g_spawn_command_line_sync () from /usr/lib/libglib-2.0.so.0 #3 0x0d7b58c4 in ?? () from /usr/lib/gtk-2.0/modules/libgnomebreakpad.so #4 0x0ee47398 in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:216 #5 signal handler called #6 nsFrame::BoxReflow (this=0x10456b54, [EMAIL PROTECTED], aPresContext=0x1044c508, [EMAIL PROTECTED], aRenderingContext=0x10489008, aX=6000, aY=6000, aWidth=0, aHeight=0, aMoveFrame=1) at nsFrame.cpp:6225 #7 0x0f028020 in nsFrame::DoLayout (this=value optimized out, aState=value optimized out) at nsFrame.cpp:6032 #8 0x0f116bf8 in nsIFrame::Layout (this=0x10456b54, [EMAIL PROTECTED]) at nsBox.cpp:561 #9 0x0f039460 in LayoutAndInvalidate ([EMAIL PROTECTED], aBox=0x10456b54, [EMAIL PROTECTED]) at nsGfxScrollFrame.cpp:2475 #10 0x0f03a1ac in nsGfxScrollFrameInner::LayoutScrollbars (this=0x104568ec, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at nsGfxScrollFrame.cpp:2537 #11 0x0f03d748 in nsHTMLScrollFrame::Reflow (this=0x104568a8, aPresContext=value optimized out, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at nsGfxScrollFrame.cpp:818 #12 0x0f024b64 in nsContainerFrame::ReflowChild (this=value optimized out, aKidFrame=0x104568a8, aPresContext=0x1044c508, [EMAIL PROTECTED], [EMAIL PROTECTED], aX=0, aY=0, aFlags=0, [EMAIL PROTECTED], aTracker=0x0) at nsContainerFrame.cpp:771 #13 0x0f07bf5c in ViewportFrame::Reflow (this=0x104566dc, aPresContext=0x1044c508, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at nsViewportFrame.cpp:286 #14 0x0f000b20 in PresShell::DoReflow (this=0x10453b60, target=0x104566dc) at nsPresShell.cpp:6304 #15 0x0f007b00 in PresShell::ProcessReflowCommands (this=0x10453b60, aInterruptible=value optimized out) at nsPresShell.cpp:6410 #16 0x0f007c98 in PresShell::DoFlushPendingNotifications (this=0x10453b60, aType=Flush_Layout, aInterruptibleReflow=1) at nsPresShell.cpp:4597 #17 0x0f007d48 in PresShell::ReflowEvent::Run (this=value optimized out) at nsPresShell.cpp:6169 #18 0x0f754df8 in nsThread::ProcessNextEvent (this=0x1005d1d8, mayWait=1, result=0xffc635d8) at nsThread.cpp:510 #19 0x0f716170 in NS_ProcessNextEvent_P (thread=value optimized out, mayWait=1) at nsThreadUtils.cpp:227 #20 0x0f67779c in nsBaseAppShell::Run (this=0x100d8f68) at
