Bug#1038788: pterm crashes if resize is attempted after terminal reset

[Jacob Nevins]

> Package: pterm
> Version: 0.78-2
> 
> If I open pterm terminal window, resize it and then type in:
> 
> reset
> 
> That will reset the size of the terminal to 80 columns as one of the
> command's effects.
> 
> If I then try resizing pterm window to more columns, it crashes and in
> .xsession-errors I see:
> 
> pterm: ./terminal/terminal.c:2325: term_resize_request_completed: Assertion
> `term->win_resize_pending == WIN_RESIZE_AWAIT_REPLY' failed.

This looks like upstream bug
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/unix-resize-assertion-failure.html
which will be fixed in the next release.

Bug#1027769: closed by Debian FTP Masters (reply to Bdale Garbee ) (Bug#1027769: fixed in cpmtools 2.23-1)

[Jacob Nevins]

Thank you for working on this (and for updating cpmtools)!

I don't think the 2.23-1 binaries are actually using libdsk, though?

I can't actually test the unstable binaries at the moment, but 'ldd'
doesn't indicate use of libdsk, and 'strings' includes a string that I
don't think would appear in a libdsk build:
"POSIX driver accepts no options (build compiled without libdsk)"

I don't think cpmtools autodetects libdsk, so just adding it to
build-deps isn't sufficient -- I think it's necessary to also invoke
configure with '--with-libdsk' (in this case, '--with-libdsk=/usr',
I think).

You can tell whether you have a libdsk-enabled build (without having a
suitable disk image to hand) like this:

$ cpmls -T dsk /dev/null

Response without libdsk:
cpmls: cannot open /dev/null (POSIX driver accepts no options (build compiled 
without libdsk))

Response with libdsk:
cpmls: cannot open /dev/null (No such file or directory)
[hmm]

Whether the cpmls usage message mentions "[-T libdsk-type]" is another
clue, but that's based on #ifdef rather than linking so I trusted it
slightly less, given the poor error handling in the configure script.
(Beware that the cpmtools configure script won't raise an error if there
was some problem finding libdsk; it'll just say "no" and leave the build
to fall over.)

Bug#1027769: cpmtools: build with libdsk?

[Jacob Nevins]

Package: cpmtools
Severity: wishlist

It would be lovely if Debian's cpmtools could be built against libdsk
(which is in Debian as of March 2018) -- these days, most of my cpmtools
usage needs a libdsk-enabled build.

Bug#1027768: cpmtools: New upstream version 2.23 available

[Jacob Nevins]

Package: cpmtools
Severity: wishlist

As subject. (Debian currently has 2.20.)

2.23 was released around Nov 2022. It adds new formats, a few new
features, and various bugfixes.
Attached, for convenience, all the upstream change descriptions between
2.20 and 2.23 (since upstream only include the most recent changes in
their tarball).

Some differences I've noticed that look relevant for packaging:
 - new man page diskdefs.5
 - there are some new configuration directives in diskdefs ("dirblks"
   and "bootsec"), and some existing formats have them added, but I
   think they are backward compatible, so shouldn't need special
   conffile handling?

(For info, upstream has also incorporated a patch that Debian used to
have, but has since fallen out of Debian:
)
Changes since 2.22:

o  Use 16 bit block pointers for file systems > 256 blocks, not >= 256
o  Translate CP/M file name character '/' to ',' for the host and back
o  dirblks in Kaypro format fixed
o  Misc fixes for directory listing
o  Added bootsec diskdefs option
o  Check Device_close return value
o  Check for too small block number when reading file data
o  Replaced obsolete macros in configure.in
o  Cygwin/Windows support did not build any more and likely not for quite
   some time, so it was removed.

Changes since 2.21:

o  Refactored curses terminal calls into own module
o  Many autoconf changes with the hope to improve portability and
   likely just breaking things
o  New diskdef for HP200

Changes since 2.20:

o  rc759 diskdef renamed to rc75x, as it works for the series
o  diskdefs.5 added
o  Many disk formats from Larry Kraemer added
o  Renamed ampdsdd to ampro400d for consistency with libdsk and because
   ampdsdd very likely was wrong
o  Check for invalid block size
o  Output line number for diskdefs errors
o  Correctly output create or access time for CP/M 3 in cpmls
o  Spectravideo SVI-728 diskdef added
o  $DESTDIR support
o  Correctly handle empty files
o  Fix block allocation for large directories.
o  Fix time stamp conversion
o  Allow user number 16-31 for CP/M 2.2
o  Intel MDS/22 formats added
o  Crash when using blocksize 16384 fixed

Bug#1027767: libdsk: New upstream version 1.5.19 available

[Jacob Nevins]

Package: libdsk
Severity: wishlist

As subject. (Debian currently has 1.5.9.)

1.5.19 was released 2022-02-27. As well as ~3.5 years of bugfixes (some
of which matter to me), it includes (not a complete list):

 - new utilities dsklabel, dskparse, lsgotek
 - new drivers/formats for some Apple formats and Gotek floppy emulators
 - new text-based "ldbst" format, which is very useful for fiddling with
   the details of disc images
 - bug fix for data loss in the 'rcpmfs' driver

Bug#440253: Please package inform 7

[Jacob Nevins]

The first release of open-sourced Inform 7 that includes Linux binaries,
and a Linux GUI, is now available, so I suppose this is now ripe for
packaging in Debian, should anyone be up for it.

https://github.com/ganelson/inform/releases/tag/v10.1.2
is the first overall Inform 7 release that includes Linux binaries.
(The first official release of the open-source version was on 21 August,
but without finalised Linux integration.)
This version number primarily denotes the toolchain, but also
incorporates specific versions of the GUIs.

I believe
https://github.com/ptomato/inform7-ide/releases/tag/2.0.0
is the source code for the version of the Linux IDE that's included in
that.

The tag and binaries are only a few hours old at this point; I don't
know if detailed Linux release notes are coming.

INSTALL.md in the inform7-ide repository looks to have a few clues
relevant to distro packagers. This forum thread where the IDE developer
previously sought feedback on release candidates may also be useful:
https://intfiction.org/t/release-candidate-of-inform-7-ide-for-gnome-testing-help-wanted/55045

One detail about the IDE that might be relevant for packaging is that,
unlike previous versions, new IDE versions reportedly "feature the
ability to select the version of Inform used, so that if v10.1.0 does
not agree with your existing Inform project, you can easily revert that
project to use 9.1, 9.2 or 9.3".

While Debian is unlikely to ever package those old closed-source
9.x versions of the toolchain, presumably the same will apply to new
10.x+ versions. This might inform the division into packages and their
dependencies.

Bug#1017066: trn4: intermittent false-positive reports of new mail ("(Mail)")

[Jacob Nevins]

Package: trn4
Version: 4.0-test77-13
Severity: minor

trn4 has a feature where it can tell you if there's new mail in your
local mailbox (/var/mail/$USER or whatever), by putting "(Mail)" in the
status line, e.g.
  (Mail) -- Select a newsgroup (natural order)
(See MAILCALL and MAILFILE in the man page for a mention of this
behaviour, although I have neither of these environment variables set.)

I'm finding that this sometimes fires spuriously -- I have no unread
mail, and yet the "(Mail)" indicator appears in trn4, and persists until
something changes in my mailbox -- I can make it go away by making and
committing a trivial change to my mailbox file.

I noticed this occasionally on jessie (trn4 4.0-test77-11), but it seems
much more frequent for me (annoyingly so) on bullseye (4.0-test77-13).


I have half a theory about what's going on:

Here's the logic that trn4 uses to check for new mail (in general, code
about it is protected by "#ifdef MAILCALL"):


if (stat(mailfile,) < 0 || !filestat.st_size
|| filestat.st_atime > filestat.st_mtime)
/* don't flag new mail */
else
/* flag new mail */

So, that can flag new mail if the mailbox atime == mtime (to a whole
number of seconds), which seems like a thing that could happen if the
MUA is very on the ball about checking the mailbox file.

My MUA is mutt (run on the same machine as trn4). Between jessie
(1.5.23-3+deb8u6) and bullseye (2.0.5-4.1), mutt started using inotify
to watch mailboxes (1.11.0, "inotify is used for local mailbox
monitoring on Linux"). So it seems plausible that the condition above
could happen more often these days; if the mutt process is active, it
could plausibly access the mailbox in the same second that new mail
arrives.

In at least one instance where I've reproduced this trn4 behaviour by
sending myself mail, the timestamps seemed to support my theory:

$ stat /var/spool/mail/jacobn
...
Access: 2022-08-12 17:25:57.799257318 +0100
Modify: 2022-08-12 17:25:57.0 +0100
Change: 2022-08-12 17:25:57.799257318 +0100
 Birth: 1970-01-01 01:00:00.0 +0100

I haven't thought too hard about how this theory interacts with me, the
human, actually reading the mail in my MUA, updating the status flags,
and committing them to the mailbox file.


I haven't thought hard about what the correct fix would be, either.
Obviously it's tempting to change > to >=, but I don't know if that's
completely safe.
Comparing to bash's mailcheck.c as another implementation of this sort
of feature (which doesn't cause me trouble), I find that it's much more
stateful (remembering previous mtimes etc), but at its heart is a
similar-looking check, which treats atime==mtime as *not* a cause for
new mail:
https://git.savannah.gnu.org/cgit/bash.git/tree/mailcheck.c#n463
(I think bash is only looking at second-granularity timestamps, same as
trn4.)


(I'm raising this as much to record my investigations as in the hope it
will be fixed. I haven't reported it upstream. If it annoys me too much
I'll probably just turn off the feature.)

Bug#1012619: want /etc/updatedb/updatedb.conf.d/

[Jacob Nevins]

The rsbackup package would also benefit from this -- it keeps snapshots
at /var/lib/rsbackup/snapshots.

Bug#1012617: want /etc/updatedb/updatedb.conf.d/

[Jacob Nevins]

The rsbackup package would also benefit from this -- it keeps snapshots
at /var/lib/rsbackup/snapshots.

Bug#990901: putty: CVE-2021-36367

[Jacob Nevins]

For the record,

contains upstream's response to the wording of CVE-2021-36367.

Bug#947765: pngcrush: pngcrush(1) man page does not document '-ow' (etc?)

[Jacob Nevins]

Package: pngcrush
Version: 1.8.13-0.1

There's been an option "-ow" to overwrite the input file since 1.7.22,
but I missed it as it's not mentioned in the Debian man page. (It is
mentioned in the usage message.)

I haven't checked to see if the man page might be out of date in other
ways too.

I'm on buster, but I also checked pngcrush.sgml in the latest package
from unstable and the master branch on salsa.

Bug#850096: Make git snapshot? (2011 → 2016)

[Jacob Nevins]

In 2017, Sylvain Beucler wrote:
> it's best to bug upstream into making a proper release, this would
> benefit to everybody.

There's now been an upstream release: 2019.1 (and 2019.1.1 shortly
afterward).

Bug#932990: freeciv: railroad and transformation in adjacent tiles

[Jacob Nevins]

David Christensen writes:
> Please see attached game save file freeciv-T0202-Y01510-manual.sav.bz2:

(This save game was created with Freeciv 2.5.6, using the 'classic'
ruleset.)

> 1.  Swamp near Kobenhavn with roads being upgraded to railroads.

I assume this is the tile highlighted if you paste
[l tgt="tile" x=37 y=12 /]
into the chatline.

> 2.  Adjacent swamp tile being transformed to swamp.

I assume this is [l tgt="tile" x=36 y=11 /], where *Ocean* is being
transformed to Swamp.

> When "Turn Done" is pressed:
> 
> 1.  Swamp is converted to ocean (bug).
> 
> 2.  Ocean is converted to swamp (correct).
> 
> 3.  Grassland adjacent to both of the above is converted to ocean (bug).

The unwanted terrain transformations are by design. Due to pollution,
catastrophic climate change has led to terrain changes. See Cities /
Pollution in the built-in help.

On the Messages tab after pressing Turn Done, I have among others these
messages:
| Global warming has occurred!
| Coastlines have been flooded and vast ranges of grassland have become deserts.

On the previous turn, the user interface shows:
| Shows the progress of global warming:
| Pollution rate: 5%
| Chance of catastrophic warming each turn: 14%

(In the Gtk client, this is shown as a tooltip for the 'sun' icon.)

(If you don't like this rule, you can turn it off in the server
settings for future games:
Game / Options / Remote server / Geological / Global warming
or '/set globalwarming disabled' from the server command line.
However, once a game has started, this option can't be changed.)

Bug#929513: closed by Markus Koschany (Bug#929513: fixed in marsshooter 0.7.6-4)

[Jacob Nevins]

I confirm that this fixes my original problem; marsshooter in testing
works for me now.

Thanks for the quick fix, and to Bernhard for the diagnosis; sorry I
didn't get around to getting a proper backtrace.

Bug#897909: mypaint: Unable to install MyPaint when Gimp 2.10 is installed

[Jacob Nevins]

I wrote:
> There's a patch (to mypaint rather than libmypaint) to resolve the
> conflict without a new version of mypaint, by renaming mypaint's locale
> to 'mypaint12', in the upstream tracker at
> .
> 
> This is the approach previously suggested by Chris Waters in
> .
> 
> I haven't tested it myself, but it looks plausible.

I have now tested this patch on my Buster system. It appears to work.

What needs to happen next, to fix this in Buster? I probably won't be
able to upload to the Debian archive myself.

Now that we have a simple and apparently workable solution, should the
buster-ignore tag be removed from #906144, to make this an RC bug once
again?

=-=-=-=-=-
What I did, in detail:

Starting with buster's mypaint_1.2.0-4.1, I added the above patch
verbatim to the debian/patches stack, updated debian/changelog, and
built new binary packages. I didn't have to make any changes.

Starting with buster's libmypaint_1.3.0-2.1, I simply edited
debian/control to remove the Conflicts:

--- debian/control  2019-02-09 11:22:40.0 +
+++ ../../libmypaint-1.3.0/debian/control   2019-06-02 12:50:07.776325535 
+0100
@@ -59,7 +59,7 @@
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends},
-Conflicts: mypaint-data
+Conflicts: mypaint-data (<< 1.2.0-4.1jtn1)
 Description: brush library for mypaint - common files
  MyPaint is a pressure- and tilt-sensitive painting program which works well
  with Wacom graphics tablets and other similar devices. It comes with a large

(that version being the name I gave to my local mypaint build)
and updated debian/changelog and built new local binary packages.

Before installing, I verified that my mypaint-data and libmypaint-common
binary packages no longer had any files in common (where the buster
packages have a lot of .mo files in common).

Testing:

I started with GIMP (and hence buster's libmypaint_1.3.0-2.1) installed.
Before changing anything, I had a quick play with GIMP's "MyPaint
brushes" feature, which I'm not familiar with. (It doesn't seem to have
any brushes by default, but I was able to scribble.)

I installed my new local libmypaint and libmypaint-common packages (the
ones GIMP uses), and verified there was no change in GIMP's behaviour as
far as I could tell.

I installed my new local mypaint and mypaint-data packages. They
installed fine. MyPaint runs and appears functional.
I have an en_GB locale, and MyPaint talks about "colour" rather than
"color", so I infer that the .mo files are installed correctly.

Bug#929513: marsshooter: Segfaults a few seconds after starting

[Jacob Nevins]

Package: marsshooter
Version: 0.7.6-3
Severity: important

When I start marsshooter, either from the desktop menu or command line,
it runs for a few seconds (13-18s in my tests), and then segfaults.

Before it dies it's displaying the main menu with a game demo in the
background, and playing music. I haven't spotted a pattern to when it
dies.

If I manage to start a tutorial before it segfaults, it seems I can
carry on playing that as long as I like until I go back to the main menu
(shortly after which, it will segfault). Being in the options menu, or
trying to start a new proper game, is not sufficient. (I've not
succeeded in getting past the game setup screen fast enough to see if
being in a proper game would stop the segfault.)

My screen is 1680x1050 (but it still segfaults if I'm running it in a
small window). I'm running Xfce. My graphics setup is as follows:

$ inxi -G
Graphics:
  Device-1: AMD RV710 [Radeon HD 4550] driver: radeon v: kernel 
  Display: x11 server: X.Org 1.20.3 driver: ati,radeon 
  unloaded: fbdev,modesetting,vesa resolution: 1680x1050~60Hz 
  OpenGL: renderer: AMD RV710 (DRM 2.50.0 / 4.19.0-5-amd64 LLVM 7.0.1) 
  v: 3.3 Mesa 18.3.4 

Here is a rubbish backtrace with no debug symbols, in case it's useful.
I'll try to get one with debug symbols later, if I remember.

(gdb) bt full
#0  0x7f50157c27f4 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
No symbol table info available.
#1  0x7f50157c2ca6 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
No symbol table info available.
#2  0x7f50157c35c7 in _Unwind_Resume ()
   from /lib/x86_64-linux-gnu/libgcc_s.so.1
No symbol table info available.
#3  0x5568ad09def0 in NoSpecial::radius() const ()
No symbol table info available.
#4  0xbf7ca95e439b58b8 in ?? ()
No symbol table info available.
#5  0x4223e3a2be24d537 in ?? ()
No symbol table info available.
#6  0x43d72748c297b58e in ?? ()
No symbol table info available.
#7  0xbfeec96cc2af18c8 in ?? ()
No symbol table info available.
#8  0x3ebea57bbdf2df33 in ?? ()
No symbol table info available.
#9  0x422437eebf307a55 in ?? ()
No symbol table info available.
#10 0x3ebf078a40270722 in ?? ()
No symbol table info available.
#11 0x3f3ed6823cc24c29 in ?? ()
No symbol table info available.
#12 0x3f80bf2a67f4 in ?? ()
No symbol table info available.
#13 0xa1b90e8dcbd98500 in ?? ()
No symbol table info available.
#14 0x5568ad143b90 in ?? ()
No symbol table info available.
#15 0x5568adc24728 in ?? ()
No symbol table info available.
#16 0x5568adc110a0 in ?? ()
No symbol table info available.
#17 0x7ffe773a7a90 in ?? ()
No symbol table info available.
#18 0x0001 in ?? ()
No symbol table info available.
#19 0x in ?? ()
No symbol table info available.

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages marsshooter depends on:
ii  fonts-dejavu 2.37-1
ii  fonts-gargi  2.0-4
ii  fonts-tlwg-waree 1:0.7.1-1
ii  fonts-wqy-microhei   0.2.0-beta-3
ii  libc62.28-10
ii  libfribidi0  1.0.5-3.1
ii  libgcc1  1:8.3.0-6
ii  libgl1   1.1.0-1
ii  libsfml-audio2.5 2.5.1+dfsg-1
ii  libsfml-graphics2.5  2.5.1+dfsg-1
ii  libsfml-system2.52.5.1+dfsg-1
ii  libsfml-window2.52.5.1+dfsg-1
ii  libstdc++6   8.3.0-6
ii  libtag1v51.11.1+dfsg.1-0.3
ii  marsshooter-data 0.7.6-3

marsshooter recommends no packages.

marsshooter suggests no packages.

-- no debconf information

Bug#929175: Buster d-i RC1: Synaptics touchpad didn't work in installer on HP Mini

[Jacob Nevins]

Cyril Brulebois writes:
> Jacob Nevins  (2019-05-18):
>> My biggest problem: my touchpad didn't work at all in the graphical
>> installer; the mouse pointer is stuck in the centre of the screen and
>> doesn't respond to movement on the touchpad.
> 
> Wondering whether this could be something similar to #926057. I suppose
> an lsmod from the installed system could give some hints.

Included below.

For completeness: some time after the install, I manually installed
xserver-xorg-input-synaptics, as this seemed to be necessary to get full
touchpad configurability in Xfce's settings GUI. The touchpad was
functional before I did this (with the stock Xfce task), but I didn't
make any note of what driver X.org was using before. I may still have an
Xorg.0.log from that time somewhere.

I mention this in case it influences the modules that have ended up
loaded.

Happy to do other experiments with the installer environment or
installed system. Thanks for your attention.

Module  Size  Used by
ctr16384  4
ccm20480  6
bnep   24576  2
arc4   16384  2
b43   454656  0
bcma   61440  1 b43
i915 1728512  3
hp_wmi 16384  0
wmi_bmof   16384  0
snd_hda_codec_idt  61440  1
mac80211  815104  1 b43
sparse_keymap  16384  1 hp_wmi
btusb  53248  0
btrtl  16384  1 btusb
btbcm  16384  1 btusb
snd_hda_codec_generic86016  1 snd_hda_codec_idt
drm_kms_helper200704  1 i915
btintel24576  1 btusb
uvcvideo  118784  0
snd_hda_intel  45056  0
bluetooth 643072  22 btrtl,btintel,btbcm,bnep,btusb
videobuf2_vmalloc  16384  1 uvcvideo
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 28672  1 uvcvideo
videobuf2_common   53248  2 videobuf2_v4l2,uvcvideo
videodev  212992  3 videobuf2_v4l2,uvcvideo,videobuf2_common
snd_hda_codec 151552  3 
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_idt
jitterentropy_rng  16384  0
drm   483328  5 drm_kms_helper,i915
media  45056  2 videodev,uvcvideo
coretemp   16384  0
snd_hda_core   94208  4 
snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_idt
joydev 24576  0
snd_hwdep  16384  1 snd_hda_codec
evdev  28672  12
drbg   28672  1
snd_pcm   114688  3 snd_hda_intel,snd_hda_codec,snd_hda_core
pcspkr 16384  0
cfg80211  761856  2 b43,mac80211
serio_raw  16384  0
ansi_cprng 16384  0
sg 36864  0
snd_timer  36864  1 snd_pcm
ecdh_generic   24576  1 bluetooth
snd94208  7 
snd_hda_codec_generic,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm,snd_hda_codec_idt
rfkill 28672  5 hp_wmi,bluetooth,cfg80211
rng_core   16384  1 b43
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
soundcore  16384  1 snd
i2c_algo_bit   16384  1 i915
wmi28672  2 hp_wmi,wmi_bmof
battery20480  0
video  45056  1 i915
pcc_cpufreq16384  0
ac 16384  0
button 16384  0
acpi_cpufreq   24576  0
ext4  733184  3
crc16  16384  2 bluetooth,ext4
mbcache16384  1 ext4
jbd2  122880  1 ext4
crc32c_generic 16384  5
fscrypto   32768  1 ext4
ecb16384  6
crypto_simd16384  0
cryptd 28672  1 crypto_simd
glue_helper16384  0
aes_x86_64 20480  10
xts16384  3
algif_skcipher 16384  0
af_alg 28672  1 algif_skcipher
dm_crypt   40960  3
dm_mod155648  13 dm_crypt
sd_mod 61440  5
ahci   40960  4
libahci40960  1 ahci
libata270336  2 libahci,ahci
uhci_hcd   49152  0
ehci_pci   16384  0
ehci_hcd   94208  1 ehci_pci
scsi_mod  245760  3 sd_mod,libata,sg
psmouse   172032  0
usbcore   290816  5 ehci_pci,uvcvideo,ehci_hcd,btusb,uhci_hcd
r8169  86016  0
i2c_i801   28672  0
lpc_ich28672  0
realtek20480  1
libphy 77824  2 r8169,realtek
ssb90112  1 b43
mmc_core  172032  2 b43,ssb
pcmcia 69632  1 ssb
usb_common 16384  1 usbcore
pcmcia_core28672  1 pcmcia
thermal20480  0

Bug#906144: mypaint: Unable to install MyPaint when Gimp 2.10 is installed

[Jacob Nevins]

There's a patch (to mypaint rather than libmypaint) to resolve the
conflict without a new version of mypaint, by renaming mypaint's locale
to 'mypaint12', in the upstream tracker at
.

This is the approach previously suggested by Chris Waters in
.

I haven't tested it myself, but it looks plausible.

(Cc'd the existing mypaint bug for this conflict,
.)

Bug#897909: mypaint: Unable to install MyPaint when Gimp 2.10 is installed

[Jacob Nevins]

I've just run into this.

 has more detail as to how this
happened and what the conflict is.

Unfortunately, it has recently been tagged 'buster-ignore', so it won't
be fixed for the Buster release. :(

Bug#927226: libpaper1: Fresh RC1 install doesn't configure /etc/papersize

[Jacob Nevins]

I've just run into this too. Same situation: fresh RC1 install on amd64,
libpaper1 1.1.26. United Kingdom (en_GB) locale. I expected "a4" but got
"letter" in /etc/papersize.

I notice that /var/lib/dpkg/info/libpaper1:amd64.config seems to be
missing its list of paper sizes between __BEGIN_PAPERSPECS__ and
__END_PAPERSPECS__. This might be relevant? Has the referenced
debian/rules machinery gone wrong?

defaultpaper () {
...
   # Try to find a matching paper size.  The data must be embedded here
   # (done automatically by debian/rules) because the rest of the package
   # may not have been unpacked at this stage.
...
__BEGIN_PAPERSPECS__
__END_PAPERSPECS__
}

The equivalent file on a stretch installation has contents like

__BEGIN_PAPERSPECS__
a4 210 mm 297 mm
letter 215.9 mm 279.4 mm
...
__END_PAPERSPECS__

Bug#642539: Patch to support xterm colour escape sequences in pterm.

[Jacob Nevins]

For the record: I think this is still not supported upstream as of 0.71.

(There doesn't seem to be a note of it in all-escapes, either.
)

Bug#509194: putty: Does not accept user@host format in CLI args

[Jacob Nevins]

Tags: fixed-upstream

This is finally fixed upstream in release 0.71.
Fixed in upstream commit 247d1b9b78.
https://git.tartarus.org/?p=simon/putty.git;a=commit;h=247d1b9b78

Bug#905852: /usr/games/sgt-solo: solo crashes when resizing

[Jacob Nevins]

Reproduced, FWIW. It is necessary to have at least one pencil mark to
reproduce this.

The problem is that the code that decides how to lay out the pencil
marks is unprepared for a vertical cell size of zero.

Bug#150757: freeciv: Icon mistake...

[Jacob Nevins]

The current government icon is a hand with a ballot paper. The current
technology icon is a ballot box.

The government icon in 1.12.0 was different; I fished it out of git and
attached it. It's a series of raised hands; not particularly
American/USAn. Arguably the background is (blue background on the left
of the icon) but shrug. Anyway, it's gone now; it was replaced in 2.1.0
(09d53a822d).

I don't see any point keeping this bug open.

Bug#340407: freeciv-server: Auto Settlers should not move on unsave terrain.

[Jacob Nevins]

Control: retitle -1 Auto Settlers should not move on unsafe terrain.

Roman Bertle wrote (Nov 2005, 2.0.7-1):
> if the "Auto Settler" command is given to a settler, worker or
> engineers, the unit moves also on unsave terrain such as glacier, and is
> in high risk to be lost.

The notion of unsafe terrain on which units randomly die was removed
upstream in 2007 (2.2.0, git 63e024da5c), so this is now moot.

Karl Goetz wrote (Feb 2010, 2.1.10):
> Subject: they also move other places
> like next to enemy units, for nations you are at war with.

A brief history of autosettlers' response to threats:

A very long time ago, there was a rather hacky notion of keeping out of
the way of enemy units, that reportedly didn't work very well and was
removed entirely in 2.1.0 (git 69d8d63253, RT PR#12977; "v.2 of the
patch. Autosettlers now fear no evil.")

After that, they learned not to wander into unfriendly territory
(borders) in 2.2.0 (git d0516f2a77, gna bug #14614).

They learned not to pick dangerous worksites and to stop working in the
face of immediate threat in 2.4.0 (git 9186857c3d, gna patch #3384),
using a rather simple and imperfect threat model (notably, only taking
land units into account).

This was made a little more sophisticated in 2.5.0 (git cdb73ed11a,
gna patch #3854), notably taking sea units into account.

They have not learned to avoid danger en route to a worksite (was gna
patch #3383), or consider threats based on attacker movement rate rather
than fixed distance etc (was gna bug #20587, gna patch #3383).

Still, I think there has been sufficient progress since this ticket was
raised that there's little point keeping it open?

Bug#848165: freeciv-client-qt: crash at exit ...leavegame->quit

[Jacob Nevins]

Marko Lindqvist wrote (Dec 2016):
>  As the crash is in atexit handlers when the program is closed, this
> seems like upstream bug #25364: http://gna.org/bugs/?25364

gna.org has gone away, but the Internet Archive captured the final state
of this ticket, which is that nothing has been done upstream to address
this. We have no ticket for it in our current tracker.


The conversation in Gna indicated that this was some interaction with
distro defaults, rather than a simple upstream bug:

mir3x:
| I prepared 3 patchs, try if any of them works.
| It just crashes at destructor of static QString, no idea why, but I saw
| similar reports when qt was built for wrong arch.

mir3x:
| ML can u check with gcc -v if your gcc has --enable-__cxa_atexit ?
| If no then it must be that issue.

Marko: [gcc -v output, presumably from Debian testing, not including
--enable-__cxa_atexit]

mir3x:
| "--enable-__cxa_atexit" is required for the G++ compiler to produce
| static destructors that fully comply with the C++ specification.
| So p1.patch might work.
| But its probably some debian bug, all static c++ classes will segfault.

I've attached the 'p1.patch' referred to, rescued from gna.org. I don't
have any record that anyone tried it.
Index: client/gui-qt/themes.cpp
===
--- client/gui-qt/themes.cpp	(revision 34735)
+++ client/gui-qt/themes.cpp	(working copy)
@@ -36,7 +36,7 @@
 extern QApplication *current_app();
 extern QApplication *qapp;
 extern QString current_theme;
-static QString def_app_style;
+QString def_app_style;
 static QString real_data_dir;
 static QString stylestring;
 

Bug#659644: Increase minima and maxima in CMA

[Jacob Nevins]

Since gna.org has gone away:

In 2.6, the Gtk3 client (intended to be the default client in that
version) has gained options to change the limits. (On reflection, not
sure why we made this client-specific.)

Original Gna ticket (archived):

Gna ticket where this was added (archived):

Upstream commit:

Bug#410558: freeciv-client-gtk: Does always want to connect to localhost

[Jacob Nevins]

Since gna.org has gone away, for the record: this will be addressed in
2.6 when it is released; there is a client option to remember the last
server connected to, although it is disabled by default.

Archived upstream Gna ticket state:

Commit that fixes this:

Bug#854287: putty: ed25519 key not recognized

[Jacob Nevins]

Demetris Demetriou writes:
> Package: putty
> Version: 0.67-2
  [...]
> Using puttygen to generate an ed25519 key.
  [...]
> Using that key file in putty results in:
> Unable to load private key file "[REDACTED]" (file format error)

You've reported this bug against PuTTY 0.67, which predates ED25519
support (that hasn't been released yet).

PuTTYgen 0.67 can't generate ED25519 keys. Was the version of PuTTYgen
you used to generate the key newer than 0.67 (i.e., development code)?

Bug#827666: [Fwd: Freciv in Stretch]

[Jacob Nevins]

On 3 July, Markus Koschany wrote:
> [...] it would be good if 2.5.5 could be released within the next
> four weeks.

Freeciv 2.5.5 has been released today.

Bug#827666: [Fwd: Freciv in Stretch]

[Jacob Nevins]

> We provided both clients in one package back then. The reasons for
> removing the gtk3 client were "it was too experimental" and "Latest
> update of gtk+-3 libraries seem to have broken our gtk3-client
> quite completely" (your quote from #766185)
> 
> I don't mind packaging the gtk3 client separately, just make up your
> mind because it must be supported if it should be part of a stable release.

The problem in #766185 (Oct 2014, 2.4.x) was that freeciv-gtk3 seemed to
be functionally the default client in the default Debian package, or at
least people were bumping into it and its problems not by conscious
choice of a non-default client.

The reason we settled on removal rather than separate packaging at that
time was I think because of the lack of time before impending freeze for
Jessie. I've attached my original message which considered other
options.

I still think having freeciv-gtk2 and freeciv-gtk3 available in separate
packages is the right answer. It would be nice if Debian could promote
our default choice of client for a given version as expressed in
'configure' (maybe a 'freeciv' metapackage?) but that's only a
nice-to-have.

Also, the Gtk3 client has improved since that time. It's not entirely
without problems, but I'm more confident in it than I was; I think we
can support the 2.5.x Gtk3 client.
--- Begin Message ---
One last request for an updated package: can you ensure that users
aren't going to run into freeciv-gtk3 unless they go looking for it?
While it's more or less playable, it really isn't ready for prime time
yet :/

I'm not sure what the experience is at the moment, but I guess from the
desktop files that many users will see "Freeciv" and "Freeciv (gtk3)" as
peers. If so, they might well think "gtk3, that's newer so obviously
better".

I'm not sure what the fix is; in increasing order of disruption:
 - edit the .desktop file to say it's experimental
 - remove freeciv-gtk3.desktop entirely
 - stop packaging freeciv-gtk3 at all
 - split into two packages, with package description for gtk3 version
   implying experimental flakiness

Sorry, this is rather late to say if you're planning to package today.
Just got a bug report from a Jessie user on #freeciv-dev who's using
gtk3; not sure what their thought process was yet.

I can raise a Debian bug for this if you'd prefer.
--- End Message ---

Bug#774711: openssh and putty

[Jacob Nevins]

Matt Taggart writes:
> * ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521
> (2014-11-02,0.64))
> * curve25519-sha...@libssh.org (2015-05-09, 0.65)

This and other items appear to infer which PuTTY releases contain
features by comparing the dates the features were checked in to master
and the release dates of PuTTY releases.

In fact PuTTY 0.64-0.67 inclusive were released from branches.
Elliptic-curve algorithms are not yet in any released version of PuTTY.
 refers.

> If you want to support squeeze(released 2011-02) and newer and putty 
> 0.63(released 2013-08) and newer [...] then the minimum modern options
> you need are: [...]

(The above doesn't change your conclusion here though.)

Bug#334303: pterm doesn't seem to support input methods

[Jacob Nevins]

The original bug reporter doesn't use pterm any more.
(I'm noting this mainly so I stop pestering them asking whether it's
fixed.)

Bug#313061: looking at /etc/fonts/fonts.conf makes pterm die with a BadName error

[Jacob Nevins]

I don't recall ever trying to reproduce this ancient bug report.

I suspect that it's been moot for ages. 0.58 used Gtk 1.2, which I can't
conveniently test with any more.

With both upstream 0.67 (latest release) and 0.61 (earliest release
using Gtk2, so earliest I can still build),
  pterm -fn '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1'
followed by
  cat killpterm.txt
doesn't cause any trouble for me. (On Ubuntu 14.04, not Debian.)

Bug#789374: [Debian] Bug#789374: missing license in debian/copyright [sikkim.svg/saxony.svg]

[Jacob Nevins]

Markus Koschany writes (in Debian BTS and to Marko/myself):
 what do you think about this bug report? According to the license they
 are GPL-2+ but the svg metadata claims something different.

 On Sat, 20. Jun 14:27 Thorsten Alteholz alteh...@debian.org wrote:
 data/flags/sikkim.svg seems to be licensed under CC 2.0 which is
 incompatible with DFSG. Please remove this file from the source tarball.

This was originally added to Freeciv upstream in
http://gna.org/patch/?2011.
Flag is described as PD image in that ticket, but the version of
http://commons.wikimedia.org/wiki/File:Flag_of_Sikkim_monarchy.svg
that was current at the time appears to have had a tag
{{self|cc-by-sa-2.5}}. This isn't quite the same as what the SVG
metadata claims, I think; don't know if that makes any difference.

The current version on Commons is described as This file is ineligible
for copyright and therefore in the public domain because it consists
entirely of information that is common property and contains no original
authorship. So we could use that instead?

 data/flags/saxony.svg is licensed under CC 3.0. Please mention this in your
 debian/copyright.

This was added upstream under http://gna.org/patch/?2205.
The then-current version of the Commons file
http://commons.wikimedia.org/wiki/File:Banner_of_Saxony_(1%5E1).svg
was described as Permission=Own work, all rights released (Public
domain). The current version is described as being in the public domain
for various being-a-state-symbol sorts of reasons.

If so, it looks like the embedded licence metadata for this file is in
error.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784019: freeciv: removal of bz2 support = inability to load old savegames?

[Jacob Nevins]

Package: freeciv-server
Version: 2.5.0-1

I haven't tested this at all, I'm afraid, but noticed this in the
changelog of the new Freeciv packages in experimental:

| - Remove libbz2-dev from Build-Depends.
|   We already support xz compression which is a superior compression format.

I think this means that the new server won't be able to load .sav.bz2
savegames? That would be unfortunate, since the stable package generates
them (and Freeciv is generally able to load savegames from older
versions).

Once you've released a package with support for a compression format, I
think you can practically never remove it, even if you add a newer
format.

Sorry if I've misconstrued the situation.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784019: freeciv: removal of bz2 support = inability to load old savegames?

[Jacob Nevins]

 indeed I deliberately dropped support for bz2 compression because I
 think it is an outdated and deprecated format.
  [...]
 Debian's Freeciv package in stable is not affected and those who have
 old savegames are able to convert them to gz or xz simply by
 recompressing.

I don't see a reason to force people to do so. The location of savegames
and compression format is essentially invisible to many users.

 I can mention that in README.Debian but I really don't see the need
 for supporting three different compression formats.

Is there a significant cost to doing so?

Performance and technical arguments about the compression format are
germane to the creation of new files, but I don't think they trump
convenience and backward compatibility.

I'd have thought that libbz2 is likely to be installed on Debian systems
regardless of Freeciv's choice for some time to come.

I think the user experience will be poor; Freeciv doesn't handle
unsupported compression formats very well. From a quick hacked test, the
user will see the savegames listed in the client UI (without the .bz2
suffix) but it will fail to load without a good explanation.

Clearly this could be improved upstream, but I don't see any reason to
force players to jump through this hoop.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775383: garden-of-coloured-lights: man page doesn't document controls or configuration

[Jacob Nevins]

Package: garden-of-coloured-lights
Version: 1.0.8-2
Tags: patch

The man page for this package is rather sparse; it doesn't explain how
to configure the game or the default controls. (Also, it refers to the
non-existent executable 'garden-of-coloured-lights'.)
diff -ur garden-of-coloured-lights-1.0.8/debian/garden.6 garden-of-coloured-lights-1.0.8-mod/debian/garden.6
--- garden-of-coloured-lights-1.0.8/debian/garden.6	2014-01-16 02:52:02.0 +
+++ garden-of-coloured-lights-1.0.8-mod/debian/garden.6	2015-01-15 00:21:13.008682178 +
@@ -1,17 +1,52 @@
-.TH GARDEN-OF-COLOURED-LIGHTS 6 May 2011
+.TH GARDEN 6 January 2015
 .SH NAME
-garden-of-coloured-lights \- abstract vertical shooter with music elements
+garden \- Garden of Coloured Lights
 .SH SYNOPSIS
-.B garden-of-coloured-lights
+.B garden
 .SH DESCRIPTION
-\fBgarden-of-coloured-lights\fP is a vertical shooter with music elements. The
-enemies, in fact, are kind of musical. Part of what stands out about Garden of
-Coloured Lights are its graphics, that even though are kept quite simple, are
+Garden of Coloured Lights is an abstract vertical shooter with music elements.
+The enemies, in fact, are kind of musical. Part of what stands out about Garden
+of Coloured Lights are its graphics, that even though are kept quite simple, are
 also carefully taken care of. Every ship still has moving parts and mechanisms
 that open and close, and every level is different, even though all of them
 share a common theme.
+.SH KEYS
+.TP
+.B Left, Right, Up, Down
+move the fighter across the screen
+.TP
+.B Z
+fire weapon 1
+.TP
+.B X
+fire weapon 2
+.TP
+.B C
+fire weapon 3
+.TP
+.B V
+slow down movement
+.PP
+Key controls can be modified inside the game options menu.
+.SH CONFIGURATION
+\fBgarden\fP doesn't accept any command line arguments. Configuration is
+via the file \fB~/.garden/init.txt\fP, which also records scores and
+configured key controls.
+
+The following configuration can only be done by editing \fBinit.txt\fP
+(under the heading \fB[Misc]\fP):
+.TP
+.B Windowed
+Use \fBWindowed = 0\fP for fullscreen, \fBWindowed = 1\fP to run in a
+window (default).
+.TP
+.B vsync
+Turning vsync on (\fBvsync = 1\fP) eliminates a graphic shearing effect which
+some people might find annoying, but can slow things down on older systems.
+Default is \fBvsync = 0\fP.
+.PP
 .SH AUTHOR
-garden-of-coloured-lights was written by Linley Henzell
+Garden of Coloured Lights was written by Linley Henzell
 l_henz...@yahoo.com.au.
 .PP
 This manual page was written by Vincent Cheng vch...@debian.org,

Bug#775384: excellent-bifurcation: man page doesn't document configuration

[Jacob Nevins]

Package: excellent-bifurcation
Version: 0.0.20071015-6
Tags: patch

The attached patch describes in the man page how to configure
excellent-bifurcation (in particular, how to enable fullscreen mode).
--- debian/excellent-bifurcation.6	2013-09-07 02:03:37.0 +0100
+++ debian/excellent-bifurcation.6.new	2015-01-15 00:28:01.504666180 +
@@ -2,7 +2,7 @@
 .\ First parameter, NAME, should be all caps
 .\ Second parameter, SECTION, should be 1-8, maybe w/ subsection
 .\ other parameters are allowed: see man(7), man(1)
-.TH EXCELLENT-BIFURCATION 6 11 April 2009
+.TH EXCELLENT-BIFURCATION 6 January 2015
 .\ Please adjust this date whenever revising the manpage.
 .\
 .\ Some roff macros, for reference:
@@ -48,16 +48,33 @@
 charges your weapons
 .TP
 .B C
-switches between the two worlds (screens)
+switches your two forms between the two worlds (screens)
 .TP
 .B A
-turns on or off the autofire mode
+turns on or off the autofire mode (autofire is just like holding down Z)
 .TP
 .B Esc
 return to the main menu
-
+.PP
 Key controls can be modified inside the game options menu.
-.BR
+.SH CONFIGURATION
+\fBexcellent-bifurcation\fP doesn't accept any command line arguments.
+Configuration is via the file \fB~/.config/excellent-bifurcation/init.txt\fP
+(or a different path if the environment variable \fBXDG_CONFIG_HOME\fP
+has been modified), which also records scores and configured key controls.
+
+The following configuration can only be done by editing \fBinit.txt\fP
+(under the heading \fB[Misc]\fP):
+.TP
+.B Windowed
+Use \fBWindowed = 0\fP for fullscreen, \fBWindowed = 1\fP to run in a
+window (default).
+.TP
+.B vsync
+Turning vsync on (\fBvsync = 1\fP) eliminates a graphic shearing effect which
+some people might find annoying, but can slow things down on older systems.
+Default is \fBvsync = 0\fP.
+.PP
 .SH AUTHOR
 excellent-bifurcation was written by Linley Henzell.
 

Bug#766185: support of different Freeciv clients

[Jacob Nevins]

This sounds like a good plan to me.

Markus Koschany writes:
 1. The virtual package freeciv should be dropped and be replaced with
a metapackage. [...]
 2. The metapackage freeciv should always depend on the recommended and
most sophisticated Freeciv client which is currently
freeciv-client-gtk2 thus »apt install freeciv« will avoid any
confusion among users and will always ensure the best gaming
experience.

If we ever do change our recommended client, presumably the experience
for existing users upgrading with the 'freeciv' metapackage installed is
that they keep their existing client, but the new one (which might be
quite different from what they're used to) will be installed alongside
(so they see two menu items, etc)? This seems like a reasonable
compromise.

freeciv-client-xaw3d (big question mark, I'm not sure if it is worth
to support xaw anymore since it lacks many features. It seems there
are still some users who use this client. So one may argue that we
should keep it as long as it is maintainable.

I don't know about the Debian version, but whenever I run it upstream it
is often completely unusable (e.g., http://gna.org/bugs/?22985,
http://gna.org/bugs/?21609), and no effort is going into it currently.

If I'm reading popcon graphs right, there's support for ~25-40 active
popcon-using xaw3d users, as compared to ~150-200 active gtk users and
~50 active sdl users?
https://qa.debian.org/popcon.php?package=freeciv

It might be time to drop it from Debian.

 Obviously Freeciv has to go through NEW for this change and it should be
 implemented for Freeciv 2.5.

(Ah, that's another reason my last-minute plan for Jessie was doomed
that I should have thought of.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#611182: agedu: uses lowercase b as byte unit symbol

[Jacob Nevins]

Jakub Wilk writes:
 agedu uses lowercase b as byte unit symbol. It should use uppercase 
 B instead (as per IEEE 1541).

This has been fixed upstream, as of 23 October.
http://tartarus.org/~simon-git/gitweb/?p=agedu.git;a=commitdiff;h=a5626fd7172c15f234ac0c5eaaf1da465297c83b


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#766185: freeciv-client-gtk: Removal of GTK+3 client

[Jacob Nevins]

 The upstream developers of Freeciv request to stop packaging the GTK+ 3
 client because recent versions of GTK+ 3 libraries apparently broke
 certain functionality which is vital to play and enjoy the game.

In fact there are multiple issues with freeciv-gtk3; what prompted this
was this bug report from a Jessie user that they couldn't found cities:
http://gna.org/bugs/?22833
I think this will probably turn out to be our (upstream) bug -- I doubt
it has anything to do with libraries -- but where we are right now is
that freeciv-gtk3 isn't ready for prime time, and shouldn't be the first
client that users run into.

(http://gna.org/task/?7760 lists some more regressions from Gtk2 to
Gtk3, although most are only cosmetic.)

 My main concern is that our common practice of providing multiple
 clients is at stake here. Actually I don't see any reason to continue
 providing multiple clients because you can argue the same way for all
 other clients. They are not feature complete and probably buggy.

I don't think this issue needs to be inflated to whether multiple
clients are packaged at all; I'd be happy for freeciv-gtk3 to be in its
own package on its own terms, and am only suggesting pulling it entirely
to try to meet Jessie timescales. If we postpone resolution to
post-Jessie then the correct resolution is to split out a
freeciv-client-gtk3 package, not to remove freeciv-gtk3. (And it really
is too late to do anything for Jessie now, for practical purposes, I
think?)

Why this request was so late: I was vaguely aware that freeciv-gtk3 had
been packaged as of 2.4.0, packaged, but like Marko, I assumed that it
was in its own package, and I wasn't aware until recently that it was
included in the same package as the default/recommended client, with no
clear distinction between the two once installed.
(My original request attached, for the record.)

 In my opinion removing the GTK+ 3 client two weeks before the freeze
 is also a rather disruptive change and I would have expected more bug
 reports in the past months from people if the situation was really
 that bad.

Maybe I'm worrying overly; the Ubuntu 14.04LTS package is the same
shape, I think, and I don't recall seeing any fallout from that (either
upstream or in Launchpad). I've only fielded the one person who ran into
freeciv-gtk3 by accident.

In the end it's your decision as Debian maintainer, of course.
---BeginMessage---
One last request for an updated package: can you ensure that users
aren't going to run into freeciv-gtk3 unless they go looking for it?
While it's more or less playable, it really isn't ready for prime time
yet :/

I'm not sure what the experience is at the moment, but I guess from the
desktop files that many users will see Freeciv and Freeciv (gtk3) as
peers. If so, they might well think gtk3, that's newer so obviously
better.

I'm not sure what the fix is; in increasing order of disruption:
 - edit the .desktop file to say it's experimental
 - remove freeciv-gtk3.desktop entirely
 - stop packaging freeciv-gtk3 at all
 - split into two packages, with package description for gtk3 version
   implying experimental flakiness

Sorry, this is rather late to say if you're planning to package today.
Just got a bug report from a Jessie user on #freeciv-dev who's using
gtk3; not sure what their thought process was yet.

I can raise a Debian bug for this if you'd prefer.
---End Message---

Bug#757876: freeciv-client-gtk: can't start a local game

[Jacob Nevins]

Xavier Cartron writes:
 In a terminal, I type freeciv-gtk2, but there is no message then and
 the client can't start a local server.
 
 When I type freeciv-server, everything works fine : 
  [...]
 I tried to launch freeciv-server separately, and with the client I
 choosed Connect to a network game, but I choose the local server. This
 way I can play a local game.

Hm. Can you do freeciv-gtk2 -l foo.log? The server log is redirected
to this file, and might tell us what's upsetting it when it's started by
the client.
(The log file might be rather verbose.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757876: freeciv-client-gtk: can't start a local game

[Jacob Nevins]

Xavier Cartron writes:
 Here is the result in the log 
 
 Ceci est le serveur pour Freeciv version 2.4.2
 Vous pouvez en apprendre davantage sur Freeciv sur http://www.freeciv.org/
 3: in log_init() [log.c::231]: log started
 0: in server_open_socket() [sernet.c::1146]: bind failed: Adresse déjà 
 utilisée
 0: bind failed: Adresse déjà utilisée

An obvious difference between a standalone server and client-started one
is that the former defaults to port 5556 and the latter to port 5557 or
higher (in 2.4.2; history at http://gna.org/patch/?4471).

So, what happens if you do freeciv-server -p 5557?

This is weird in any case; the client is supposed to find a free port to
start the server on, so this shouldn't be able to occur.

 'lsof -i -n -P' shows only this : 

'netstat -a --ip' might be a better diagnostic, as it will show ports
that are in TIME_WAIT state and the like.

Does it matter what you've done previously? I'm wondering if TIME_WAIT
might be causing trouble. Do you get this the very first time you launch
the client after boot, or several minutes after you last quit any
freeciv-related program?

(We messed around with our socket binding upstream recently and we think
we've exposed TIME_WAIT trouble, but that's in 2.5 and not 2.4 -- 
http://gna.org/bugs/?21583 -- so can't possibly affect the Debian
package, and in any case smells different.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757876: freeciv-client-gtk: can't start a local game

[Jacob Nevins]

Xavier Cartron writes:
 - If I do 'freeciv-server -p 5557',, the server starts normally.

Enh. Of course the client might not be choosing 5557. It tries to find a
free port and tells the server to use that.
(Sure would have been useful if we (upstream) had thought to log the
port we were attempting to use, either in the client or in the
server...)

If the client had, for instance, a logical bug where it searched for the
first *used* port, or its test for free-ness always returned false
causing the port to wrap around, I guess that could cause this symptom.
(The relevant code is in utility/netintf.c:find_next_free_port().)

Is there anything unusual about your network stack? Lack of IP
connectivity, real IPv6 connectivity, non-default kernel options,
anything like that?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757876: freeciv-client-gtk: can't start a local game

[Jacob Nevins]

Xavier Cartron writes:
 When I click on Start a new game (démarrer une nouvelle partie in
 french), I see at the bottom of the client window these messages : 
 Starting local server
 Impossible to connect to the server
 And then, nothing happens, and I can't play any game.
 
 Unfortunately, I don't see any error message when launching freeciv with
 a terminal.

When you say launching freeciv with a terminal, what exactly do you
type, and what do you see?

What happens if you type 'freeciv-server' in a terminal (if different to
the above)?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739577: freeciv-client-gtk: unit/tile info tied to middle mouse button only

[Jacob Nevins]

 Overally, it would be nice if there was an alternative way to
 trigger this functionality, perhaps ctrl + LMB or some such.  Some
 googling suggests alt + LMB might trigger it on some platforms,

Alt+LMB is indeed supported by the Freeciv Gtk client as the alternative
to middle-click; this is documented in the 'Controls' section of the
online help.

In general, other modifier+button combinations are pretty well used for
other functions, so I don't see much scope for adding a third
alternative.

 but that moves a window in X11 (and even in fullscreen mode, doesn't
 seem to have any effect here).

It's more likely to be your window manager / desktop environment that
eats Alt+mouse than X11 itself. For instance, I think Xfce has the
behaviour you describe. 

 However, e.g. the thinkpad notebooks can use the middle button
 to emulate a scrollwheel if held, which is extremely useful but
 interferes with this.  (Curiously - just tapping the middle mouse button
 normally retains its function, e.g. pastes in a terminal, but has no
 effect in the freeciv client.)

Not sure why this might be, but the effect of tapping would be to bring
up the info popup only momentarily, which isn't very useful, so I'm not
inclined to spend time investigating the discrepancy.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738502: Not really re: Bug#738502: freeciv-client-gtk: earth-80x50-v3.sav.gz Unknown savefile format version (10) Failure loading savegame!

[Jacob Nevins]

Markus Koschany writes:
 David, the security issues are completely unrelated to your bug report
 and my reply to you only highlighted three options how you could upgrade
 to a more recent version of freeciv.
  [...]
 Regarding the security issues the security team decided that they are
 not critical. Nevertheless I intend to ask Debian's release team to
 include the fixes in the next point release.

Markus,

Thank you for this explanation, and sorry to have started the noise
about the CVEs in this unrelated bug report.

It wasn't entirely obvious outside the Debian project that the security
team had made a positive decision -- all I saw was bug #696306, with
unanswered requests by release managers for a stable upload.
(I now see [wheezy] - freeciv no-dsa (Minor issue) on
security-tracker.debian.org, which I assume is the record of this
security team decision, but it's a bit cryptic. In any case, it seems
like a reasonable decision for the project to have made, given the
nature of the vulnerability.)

Thanks also for considering the fixes for the wheezy point release.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738502: freeciv-client-gtk: earth-80x50-v3.sav.gz Unknown savefile format version (10) Failure loading savegame!

[Jacob Nevins]

Control: forwarded -1 http://gna.org/bugs/?20050
Control: fixed -1 2.3.4-1
Tags: fixed-upstream

David Christensen writes:
 When I choose Start Scenario Game - Earth (classic/small) - OK, it
 doesn't work.  The console window says:
  [...]
 Unknown savefile format version (10).

This is a known upstream bug in 2.3.2 (bug #20050), which was fixed in
2.3.3.

It's thus been fixed for ages in newer versions of the Debian package,
but still affects Debian wheezy/stable (and will do for a while,
presumably).

It would be a low-risk thing to fix in a backport to stable, should
Debian wish to do so -- it's just some tweaks to the scenario file in
question. (See the svn link from the upstream bug ID.)

(There's an argument that the wheezy package needs an update anyway --
it's had open security issues for ages: CVE-2012-5645, CVE-2012-6083.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#545934: (civclient:29856): Gdk-WARNING **: XID collision, trouble ahead

[Jacob Nevins]

 The only seemingly related upstream bug report is
 
 https://gna.org/bugs/?func=detailitemitem_id=16760#options
 
 Tagging this bug report as moreinfo since it was reported against a version
 which is no longer supported by Debian and I can't reproduce it myself.
 If someone can reproduce it with 2.4.0 or 2.4.1 and later, please report back.

Completely by coincidence, after playing with an upstream release
candidate (S2_4 r24328, close to what will be 2.4.2) I found my console
full of
(freeciv-gtk2:1983): Gdk-WARNING **: XID collision, trouble ahead

(I didn't notice any obvious trouble.)

This isn't directly applicable to Debian, since I wasn't using the
Debian package and am running Ubuntu 12.04, but it seems to indicate
that it's a live issue.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730868: freeciv: New upstream version 2.4.1 available

[Jacob Nevins]

Is there any chance of 2.4.1 being packaged soon?

As well as getting the bugfixes into Debian, ideally I'd like to get
them into the next Ubuntu, which is a LTS (long term support) release.
https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule suggests that the
deadline for import from Debian (testing, I guess?) is Feb 6; there
might still be just about enough time to meet that?

(Full disclosure: we are planning a 2.4.2 upstream release soon, but
that will almost certainly not be in time. 2.4.1 would still be an
improvement over 2.4.0.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730868: freeciv: New upstream version 2.4.1 available

[Jacob Nevins]

Markus Koschany writes:
 the current human maintainers of freeciv are quite inactive/busy these
 days. You could always try to update the package yourself and ask
 someone on debian-devel-ga...@lists.debian.org for sponsoring your
 package. This might often be the quickest way to get an urgent fix into
 Debian/Ubuntu.

You're probably right that it's the quickest way, but so far I've been
successfully resisting the temptation to get involved in Debian
packaging -- I already have too many commitments as upstream...

 As soon as Alioth and the git repositories are back online, I can try to
 package 2.4.1. I hope there aren't too many changes.

Since 2.4.0 is already packaged, I *think* 2.4.1 should be a
straightforward rebuild.
I don't see anything scary-looking at
http://www.freeciv.org/wiki/NEWS-2.4.1#Build.2Fportability
nor any significant additions to doc/README.packaging.

 I can't promise that the new release will be uploaded in time before
 the 6th of February. That depends on whether I can find a sponsor for
 freeciv.

Thanks for considering it.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730868: freeciv: New upstream version 2.4.1 available

[Jacob Nevins]

Package: freeciv
Severity: wishlist

We (upstream) are keen that 2.4.1 should get into Debian reasonably
quickly, since it fixes some notable bugs since the currently packaged
2.4.0. Details of the changes at
http://www.freeciv.org/wiki/NEWS-2.4.1.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#602562: Can't see city sizes on white nation

[Jacob Nevins]

This should be closed now that 2.4.0-1 has hit the archive.
(But I'll leave actually closing it to the package maintainers.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700222: freeciv-server: irrigation of swamps broken

[Jacob Nevins]

I wrote:
 http://gna.org/bugs/?16209: all progress on projects is lost when
 loading a savegame into 2.2.1.
 
 So, was there one or more save/load cycles between these two turns?
 
 If this is the case, then you'll see a different situation to me when
 you load those savegames. The bug is that progress is lost on load, so
 loading into a newer version of Freeciv, progress is not lost. I loaded
 into 2.2.7, as the 2.2.x version I had to hand. So I predict that when
 you load these savegames into 2.2.1, you're seeing the full 15 turns
 left in both cases. Is that correct?

I did the experiment myself with vanilla 2.2.1, and it behaves as I say.
So, I'm reasonably convinced upstream bug 16209 is behind this.

In the absence of further information from the original submitter, I
recommend this bug is marked as fixed by 2.2.2-1 and closed.
(But I leave actually doing so to the package maintainers.)

The only Debian release still affected by bug 16209 is
squeeze=oldstable.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#578068: freeciv-server - listen on :: without warning

[Jacob Nevins]

This should be fixed as of the recent 2.4.0-1 upload (as the bug was
fixed upstream in 2.4.0).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#308552: doesn't act on keyboard input when the time machine is used

[Jacob Nevins]

In 2005, I wrote:
 Now that we've bitten the bullet and autoconfiscated, perhaps we
 should make an effort to use monotonic clocks on those systems where
 they're reliably available.

As of 0.63 (not yet packaged) we do this (r9529/r9535 upstream,
committed in May 2012).

(Also the whole basis of timing was changed around the same time in
r9528; I don't know if that gets rid of this symptom. Also, heavens,
this bug has been around since 2005, I don't know if that's the only
change to the timing arrangements in all that time. I wouldn't be
surprised if this bug is long gone.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#334303: pterm doesn't seem to support input methods

[Jacob Nevins]

I don't suppose this was fixed in 0.62-8, when support for dead keys /
compose sequences went in, was it?

(This corresponds to upstream r9567 or thereabouts -- Support for dead
keys and compose sequences on Unix, by instantiating a GtkIMMulticontext
and having that filter most keypresses. I think the patch attached here
must by now be thoroughly obsolete.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#718354: Unruly: unique ignored when width != height

[Jacob Nevins]

 When starting a game with width==height (I tested 6x6, 8x8 and 10x10),
 sgt- unruly immediately complains when a row or column is an exact
 duplicate
 
 When starting a game with width!=height (I tested 10x8, 10x6, 8x6,
 6x8), sgt- unruly does NOT complain when a row or column is an exact
 duplicate. When the game is finished, the field blinks in the
 standard manner when a game is won.

I've found and fixed (upstream, r9976) a bug which caused failure to
display the red warnings about non-unique rows / columns for non-square
grids and caused the game to accept solutions that violated the
uniqueness constraint.

(However, I think the generated puzzles did not _require_ the uniqueness
constraint to be violated in a solution.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696306: freeciv: CVE-2012-5645

[Jacob Nevins]

Moritz Muehlenhoff:
 Freeciv maintainers,
 it's been two months. Can you please upload a fixed package?

For the avoidance of doubt (sorry if you knew this):

No-one you've emailed directly is a Debian maintainer (Marko is
upstream).

We (upstream) made a new release fixing both CVE-2012-5645 and
CVE-2012-6083 on 8th Dec (2.3.3). Since then we've made another release
(2.3.4 on 16th Feb). See #699296 where I request that Debian take these
updates into at least unstable.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700222: freeciv-server: irrigation of swamps broken

[Jacob Nevins]

David Christensen writes:
 Irrigations of swamps is broken.  Please review workers near Aarhus on
 turn 132 and turn 163.

Can you provide a bit more information on what exactly is not behaving
as you expect?

In T0132 we have at [l tgt=tile x=66 y=40 /]:
  [l tgt=unit id=806 name=Archers /], fortified
  [l tgt=unit id=805 name=Workers /], manually irrigating, 14 turns to go

In T0163 at the same tile we have the same Archers and Workers units
doing the same things, with the Workers having 2 turns to go.

There's no evidence of global warming or similar disturbing factors.

I'm going to guess that you say that the Workers have been undisturbed
in the intervening time, and that you'd thus have expected them to have
finished converting the swamp to grassland around T0146.

2.2.1 is rather old, but I don't recall any progress-losing bugs fixed
since then, offhand. There is a hazard though: if you were to stop the
Workers from working, even for a moment, then you do lose all progress;
and it was rather easy to do this if you had Clear unit orders on
selection enabled in the options -- just selecting the unit would lose
everything.
(This behaviour was improved in 2.3.0 -- from that version, if you
immediately set the unit to irrigating again, it will pick up where it
left off. http://gna.org/bugs/?15510)

Is it possible that this is what happened?

Otherwise, without some more information about what happened in the
interim, it's going to be hard to diagnose this. Do you have more
savefiles?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700222: freeciv-server: irrigation of swamps broken

[Jacob Nevins]

I wrote:
 2.2.1 is rather old, but I don't recall any progress-losing bugs fixed
 since then, offhand.

...and then linked to gna #15510, which itself links to exactly such a
progress-losing bug that is present in 2.2.1 and fixed in 2.2.2 (that I
had introduced and fixed myself and subsequently forgotten about).

http://gna.org/bugs/?16209: all progress on projects is lost when
loading a savegame into 2.2.1.

So, was there one or more save/load cycles between these two turns?

If this is the case, then you'll see a different situation to me when
you load those savegames. The bug is that progress is lost on load, so
loading into a newer version of Freeciv, progress is not lost. I loaded
into 2.2.7, as the 2.2.x version I had to hand. So I predict that when
you load these savegames into 2.2.1, you're seeing the full 15 turns
left in both cases. Is that correct?

If this is the explanation, then it's fixed upstream and indeed in newer
Debian versions. It's a bit unfortunate that the current Debian stable
(soon to be oldstable?) is stuck with this buggy version; not sure
what's to be done.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#602562: Can't see city sizes on white nation

[Jacob Nevins]

The default player colours in the next major version (2.4.x) have been
reworked to eliminate white (and near-white) colours, in part due to
this report.
http://gna.org/bugs/?19778


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#699296: freeciv: New upstream version 2.3.3 available

[Jacob Nevins]

Package: freeciv
Severity: wishlist

Notably, this fixes the security issues of #696306, as well as a number
of other bugfixes http://www.freeciv.org/wiki/NEWS-2.3.3.

This would also be an opportunity to fix #677891.

(Even if Debian's in freeze, would getting this into unstable allow it
to trickle into Ubuntu, possibly for 13.04?)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#698183: agedu: New upstream version available

[Jacob Nevins]

Package: agedu
Severity: wishlist

(Well, there's usually a new upstream version available, since it's not
released as such. However:) Debian's version is getting on for three
years old, and while nothing Earth-shattering has happened in svn, there
have been a few improvements (as of r9723):

 - IPv6 support for web server
 - URLs more likely to remain valid over a database rebuild
 - New options --no-eof, --title
 - One memory access bug fix (potential crash?)
 - Typos and reporting fixes
 - HTML markup fixes
 - Man page improvements


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#677891: Should freeciv-client-gtk depend on gtk2-engines-pixbuf?

[Jacob Nevins]

Package: freeciv-client-gtk

Upstream here.

While investigating issues with theming, I noticed that the custom
Freeciv Gtk theme (used by default) uses 'engine pixmap' clauses.

Having dug into Gtk theming a bit, I think this implies that the theme
depends on the files in the gtk2-engines-pixbuf package in order to
display correctly.

However, I don't see that as a dependency in the Debian Freeciv package.
Should it be there?

I guess the symptoms of trying to use the theme without the engine
installed will be:

 - A warning on the console:
   Gtk-WARNING **: Unable to locate theme engine in module_path: pixmap

 - Presumably, failure to display some UI elements as intended.
   - However, I think this could be quite subtle. The yellow paper
 background does not appear to depend on the pixmap engine, so I
 guess the client will look themed at first glance.

But of course you wouldn't see this if you happened to have the engine
installed for some reason. I think historically, most installations will
have had it, but Ubuntu at least seem to have stopping shipping it as
part of their core system since 11.10 (it's now relegated to
universe).

Also, it's possible that the dependency tree from freeciv-client-gtk
somehow pulls in gtk2-engines-pixbuf indirectly; I haven't checked
thoroughly.

However, if I'm right, I think there should be a direct dependency
(especially on Ubuntu).

Note: this is all theoretical so far. I haven't tested any of it, as I
don't have any suitable installations to hand. Perhaps I've
misunderstood something that means a dependency is not necessary to
declare.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#578068: freeciv-server - listen on :: without warning

[Jacob Nevins]

I'd consider this a bug in the clients (all of them) rather than
freeciv-server. As Marko says, if you're running freeciv-server
standalone, you're as likely as not to want other hosts to connect to
it, and if not, you can always specify the --bind localhost argument.

I'm looking to make the clients use --bind localhost for
client-spawned servers (i.e., single-player games) by default for 2.4.x,
which I think will satisfy the intent of this bug. A trivial patch is in
the upstream bug tracker. Feel free to backport to earlier versions for
Debian if you wish; I'm avoiding doing so upstream primarily due to the
risk of it exposing some platform-dependent networking horror that
completely breaks single-player games.

(I don't think #572990 is relevant here, except tangentially as an
example of the sort of platform-dependence I'm scared of.)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572990: #572990 freeciv: Client can't connect to its own server (Can't Start local game)

[Jacob Nevins]

Assuming we believe this was in fact upstream bug #15559, since 2.2.4
has been in unstable since December and in testing since February, it's
probably time to mark this as fixed?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#631775: freeciv-client-gtk: messages box forgets its contents

[Jacob Nevins]

Karl Goetz writes:
 At the end of each turn, the messages box clears its contents. This is
 quite annoying when you forget to check it

This is true (but not new).

These days, there is actually a record of messages from past turns
stored the the server, if configured at runtime (the event cache). But
there's no way for the client to retrieve it on demand; it's sent to the
client when it first connects to a game. Perhaps some more facilities in
this area would be useful.

 as it lacks a hotkey for access (as far as i can find).

F9?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554411: freeciv: FTBFS with binutils-gold

[Jacob Nevins]

In May, I wrote:
 A patch has been committed upstream which is intended to deal with this
 (as of r17431), [...]

For the avoidance of doubt: this patch went in between the 2.2.0 and
2.2.1 releases, so Debian now has it.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#572990: freeciv: FTBFS with binutils-gold

[Jacob Nevins]

The upstream fix for this bug has just been released in Freeciv 2.2.4.

(The conditions where this bug bites are:
1. Socket option IPV6_V6ONLY defaults to on (as in Linux with
   net.ipv6.bindv6only=1);
2. localhost resolves to 127.0.0.1 but not ::1.

This caused the server to accept IPv6 connections, and the client to
only attempt to connect to 127.0.0.1 as localhost.)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#600523: zerofree: allow filling empty space with nonzero octets

[Jacob Nevins]

Package: zerofree
Version: 1.0.1-2
Severity: wishlist
Tags: upstream, patch

This patch adds a -f [fillval] option to zerofree allowing unused
blocks to be filled with some other octet.

Why? There's a well-known write performance degradation issue with solid
state drives (SSDs) due to the drive firmware being unaware of which
blocks are unused by the filesystem. Modern SSDs allow the OS to tell
them about unused space. http://en.wikipedia.org/wiki/TRIM describes
the issue.

However, only recent SSDs support this. I've seen reports on the
Internet[*] that some older SSDs have firmware which will spot a write
of erased values to a block and treat the block as empty, giving the
same rejuvenation as the TRIM command would. 0xFF is a particularly
likely erased value, the erase state of the underlying Flash typically
being interpreted as a 1 bit.

  [*] for instance
http://www.ocztechnologyforum.com/forum/showthread.php?67034-Wiping-with-BC-Wipe-to-recover-write-performance

zerofree was approximately the right shape to do this job, hence my
patch.

I've provided two patches: one to the actual code (for Ron and Debian),
and one to the manual page (for Debian).

(Note that I haven't verified that this actually makes any difference on
any real SSD yet; so far I've just tried it on a filesystem image and
checked that fsck is happy with the result.)
--- zerofree-1.0.1/zerofree.c	2007-08-12 10:38:31.0 +0100
+++ zerofree-1.0.1-nz/zerofree.c	2010-10-17 18:59:26.0 +0100
@@ -10,14 +10,16 @@
  *
  * 2007-08-12  Allow use on filesystems mounted read-only.   Patch from
  * Jan Krämer.
+ * 2010-10-17  Allow non-zero fill value.   Patch from Jacob Nevins.
  */
 
 #include ext2fs/ext2fs.h
 #include stdio.h
 #include unistd.h
 #include string.h
+#include stdlib.h
 
-#define USAGE usage: %s [-n] [-v] filesystem\n
+#define USAGE usage: %s [-n] [-v] [-f fillval] filesystem\n
 
 int main(int argc, char **argv)
 {
@@ -31,13 +33,14 @@
 	unsigned char *buf;
 	unsigned char *empty;
 	int i, c ;
-	unsigned int free, nonzero ;
+	unsigned int free, modified ;
 	double percent ;
 	int old_percent ;
+	unsigned int fillval = 0 ;
 	int verbose = 0 ;
 	int dryrun = 0 ;
 
-	while ( (c=getopt(argc, argv, nv)) != -1 ) {
+	while ( (c=getopt(argc, argv, nvf:)) != -1 ) {
 		switch (c) {
 		case 'n' :
 			dryrun = 1 ;
@@ -45,6 +48,19 @@
 		case 'v' :
 			verbose = 1 ;
 			break ;
+		case 'f' :
+			{
+char *endptr;
+fillval = strtol(optarg, endptr, 0) ;
+if ( !*optarg || *endptr ) {
+	fprintf(stderr, %s: invalid argument to -f\n, argv[0]) ;
+	return 1 ;
+} else if ( fillval  0xFFu ) {
+	fprintf(stderr, %s: fill value must be 0-255\n, argv[0]) ;
+	return 1 ;
+}
+			}
+			break ;
 		default :
 			fprintf(stderr, USAGE, argv[0]) ;
 			return 1 ;
@@ -77,7 +93,7 @@
 		return 1 ;
 	}
 
-	empty = (unsigned char *)calloc(1, current_fs-blocksize) ;
+	empty = (unsigned char *)malloc(current_fs-blocksize) ;
 	buf = (unsigned char *)malloc(current_fs-blocksize) ;
 
 	if ( empty == NULL || buf == NULL ) {
@@ -85,6 +101,8 @@
 		return 1 ;
 	}
 
+	memset(empty, fillval, current_fs-blocksize);
+
 	ret = ext2fs_read_inode_bitmap(current_fs);
 	if ( ret ) {
 		fprintf(stderr, %s: error while reading inode bitmap\n, argv[0]);
@@ -97,7 +115,7 @@
 		return 1 ;
 	}
 
-	free = nonzero = 0 ;
+	free = modified = 0 ;
 	percent = 0.0 ;
 	old_percent = -1 ;
 
@@ -129,7 +147,7 @@
 		}
 
 		for ( i=0; i  current_fs-blocksize; ++i ) {
-			if ( buf[i] ) {
+			if ( buf[i] != fillval ) {
 break ;
 			}
 		}
@@ -138,7 +156,7 @@
 			continue ;
 		}
 
-		++nonzero ;
+		++modified ;
 
 		if ( !dryrun ) {
 			ret = io_channel_write_blk(current_fs-io, blk, 1, empty) ;
@@ -150,7 +168,7 @@
 	}
 
 	if ( verbose ) {
-		printf(\r%u/%u/%u\n, nonzero, free,
+		printf(\r%u/%u/%u\n, modified, free,
 current_fs-super-s_blocks_count) ;
 	}
 
diff -uNr zerofree-1.0.1/debian/zerofree.sgml zerofree-1.0.1-nz/debian/zerofree.sgml
--- zerofree-1.0.1/debian/zerofree.sgml	2009-11-24 18:28:24.0 +
+++ zerofree-1.0.1-nz/debian/zerofree.sgml	2010-10-17 19:45:03.0 +0100
@@ -9,7 +9,7 @@
   !ENTITY dhfirstname firstnameThibaut/firstname
   !ENTITY dhsurname   surnamePaumard/surname
   !-- Please adjust the date whenever revising the manpage. --
-  !ENTITY dhdate  dateFebruary 6, 2008/date
+  !ENTITY dhdate  dateOctober 17, 2010/date
   !ENTITY dhsection   manvolnum8/manvolnum
   !ENTITY dhemail emaillt;paum...@users.sourceforge.netgt;/email
   !ENTITY dhusername  Thibaut Paumard
@@ -54,6 +54,8 @@
 
   argoption-v/option/arg
 
+  argoption-f fillval/option/arg
+
   arg choice=reqreplaceablefilesystem/replaceable/arg
 /cmdsynopsis
   /refsynopsisdiv
@@ -63,12 +65,19 @@
 paracommanddhpackage;/command finds the unallocated,
non-zeroed blocks in an ext2 or ext3
replaceablefilesystem/replaceable (e.g. /dev/hda1) and
-   fills them with zeroes. This is useful if the device

Bug#599671: freeciv-server: intermittent segfault

[Jacob Nevins]

 Version: 2.2.2-1

Unfortunately, there was at least one server-side segfault in 2.2.2,
which has been fixed in 2.2.3: http://gna.org/bugs/?16100
I don't know for sure whether that's what you've run into, but I think
it can happen in any game with AI.

(Another crash in 2.2.2 that's fixed in 2.2.3 is
http://gna.org/bugs/?16592, but I know less about that one.)

(Is it too late to get 2.2.3 into Squeeze?)

 Invalid string conversion from UTF-8 to ISO-8859-1.

Don't know what this is about; probably just as it says on the tin.
(Does Debian still default to ISO-8859-1 rather than UTF-8 in local
terminals?)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#195158: any update to this bug?

[Jacob Nevins]

 Any thoughts on how to move forward from here?

I've just been playing with the various options in the S2_2
development code (soon to become 2.2.3). I haven't checked 2.2.2;
there have been some tweaks in this area since then.

The smallest window I was able to achieve was about 789x557 (but that
doesn't include window furniture, e.g. title bar). That was with the
following combination of options:
  Arrange widgets for small displays set
  Merge the message notebook and the map notebook set
  Split bottom notebook area *not* set
This was on a big desktop system with no attempt made to optimise font
sizes, etc, so perhaps it could be made even smaller.

And I've actually played Freeciv (single-player) in reasonable comfort
on an Eee 901 (1024x600) -- this was trunk code, but I don't think
it's significantly different in this regard. With regards to the GNOME
panels, we run with a single panel vertically down the left of the
screen; it's quite usable and makes a surprising amount of difference.

I think we're probably reaching the limits of what's possible here; we
seem to be more or less below 800x600, and 640x480 looks pretty
hopeless (sorry Eee 701 users). It's certainly a lot better than it
was. Any point in keeping this bug open?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#554411: freeciv: FTBFS with binutils-gold

[Jacob Nevins]

A patch has been committed upstream which is intended to deal with this
(as of r17431), but we haven't actually checked that it helps with
building with binutils-gold, and I was unable to reproduce the original
problem by adding -Wl,--no-add-needed to the linker command line.
Perhaps the original reporter could check that the fix has actually
helped.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#195158: any update to this bug?

[Jacob Nevins]

Hmm. I was just going by the descriptions in SVN. I admit I'm not
actually using the Debian package but the upstream version; nor am I
actually using it on Debian (I'm on Ubuntu Jaunty). However, there don't
seem to be many Debian-specific patches.

 2.1.10 not fitting correctly on my 1024x768 screen, once its loaded
 past the initial screen. I'll have a look at the bug report linked and
 see if i can reearange stuff so it fits.

I just downloaded the upstream 2.1.10 release and tried the Gtk client.
While the initial and pre-game windows I see are 674x565 (probably OK
for 800x600 and smaller than they were), the actual game window can't
usefully be resized less than 674 wide or about 720 high -- the top
section with the map doesn't get any smaller so you can't have a message
window. So, this configuration is no good for 800x600 (OP) or 1024x600
(netbooks). However, I'm surprised you're having trouble at 1024x768; if
you see what I see it should be tight but usable.

However:

 I added 'small_display_layout=1' to .civclientrc, and tried
 using '/small_display_layout' on the player choosing screen pre game.
 Neither of these options made my freeciv layout change.

The latter won't help because that's how you set server options and this
is a client option. The former might work, but what should definitely
work is, once you have a game going, go to Game  Local Options 
Interface  Arrange widgets for small displays (at the bottom). You
need to restart after setting this and saving the setting.

When I try this, it gets better: the window seems usable down to about
674x600, so I think you could play on 800x600 or 1024x600 (although I
haven't tried it). The difference is that the chat/messages area is
moved to the right, allowing the civ/unit info column to grow down into
the vacated area. The limiting factor on height becomes the point where
the selected units disappear off the bottom.

The situation is about the same in the latest upstream 2.1.x and
2.2.0-RC1 code, FWIW.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100217021831.gd26...@chiark.greenend.org.uk

Bug#195158: any update to this bug?

[Jacob Nevins]

In May 2009, Karl Goetz wrote:
 Is there any update to this, from here or upstream?
 with small laptops like YeeLoong or EEEpc becoming popular 1024x600 is
 becoming a common resolution.

Upstream rearranged things to fit in 800x600 in 2.1.9 (r15566), and
added an option to arrange things better for small displays in 2.1.10
(r15683, http://gna.org/bugs/?13524).

I think this can probably be closed now?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100216024924.gc19...@chiark.greenend.org.uk

Bug#560248: ltris: FTBFS: uses LC_ALL without including locale.h

[Jacob Nevins]

Package: ltris
Version: 1.0.12-1
Tags: upstream, patch

I tried rebuilding this package from source on Ubuntu Jaunty and ran
into this error:

main.c: In function ‘main’:
main.c:41: error: ‘LC_ALL’ undeclared (first use in this function)
main.c:41: error: (Each undeclared identifier is reported only once
main.c:41: error: for each function it appears in.)

main() uses 'setlocale (LC_ALL, )', but neither it nor any of the
local headers include locale.h.

I think this might happen to work in some build environments; at least
on my system, the libintl.h they do include looks like it includes
locale.h for some but not all optimisation levels.

Nevertheless, it's fragile. The attached patch adds an explicit
dependency.

I think the latest upstream version (2.0.13) is affected as well.
--- src/gettext.h.orig	2005-10-04 19:20:09.0 +0100
+++ src/gettext.h	2009-12-09 22:57:24.0 +
@@ -24,6 +24,8 @@
 
 /* Get declarations of GNU message catalog functions.  */
 # include libintl.h
+/* Get declarations of setlocale() and LC_ALL.  */
+# include locale.h
 
 #else
 

Bug#560247: ltris: keyboard control is rather twitchy

[Jacob Nevins]

Package: ltris
Version: 1.0.12-1
Severity: wishlist
Tags: patch

Even at the maximum 'Horizontal Delay' setting of 5, I find the keyboard
controls too twitchy -- it can be hard to move by a single column.

The attached trivial patch ups the range from 0-5 to 0-9.
--- src/manager.c.orig	2008-03-29 11:39:17.0 +
+++ src/manager.c	2009-12-09 22:27:20.0 +
@@ -376,7 +376,7 @@
 menu_add( cont, item_create_link( _(Player2), HINT_CONTROLS, cont_player2 ) );
 menu_add( cont, item_create_link( _(Player3), HINT_CONTROLS, cont_player3 ) );
 menu_add( cont, item_create_separator(  ) );
-menu_add( cont, item_create_range( _(Horizontal Delay:),  HINT_HORIDEL,config.hori_delay, 0, 5, 1 ) );
+menu_add( cont, item_create_range( _(Horizontal Delay:),  HINT_HORIDEL,config.hori_delay, 0, 9, 1 ) );
 menu_add( cont, item_create_separator(  ) );
 menu_add( cont, item_create_link( _(Back), HINT_, _main ) );
 /* all keys used */

Bug#554342: cpmtools: accepts -T libdsk-type even though not linked against libdsk

[Jacob Nevins]

Package: cpmtools
Version: 2.7-1
Version: 2.10-1
Severity: minor
Tags: upstream

The executables in the Debian 'cpmtools' package advertise the option
'-T libdsk-type' in their built-in help, and accept the option, but do
nothing with it (as the Debian version isn't built against libdsk).

The man pages (correctly) omit to mention '-T libdsk-type',
contradicting the built-in help. I had to go into the source to work out
whether it did anything or not...

Feels like this should be conditionalised, perhaps on HAVE_LIBDSK_H.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#496063: 'man pterm' uses unicode dashes for option markers, in unicode locale

[Jacob Nevins]

Coming back to this:

Colin wrote:
 Unfortunately, groff doesn't have anything that reliably comes out as
 U+002D HYPHEN-MINUS everywhere. On Debian both - and \- are hacked
 to come out as U+002D, but strictly speaking - has hyphen semantics
 and \- has minus-sign semantics. Upstream disapproves of HYPHEN-MINUS
 as being typographically unsound, which doesn't help manual pages very
 much. Given a choice between the two, at least \- doesn't break lines,
 so I think it's the better choice.

Done upstream (r8641).

 You could behave differently in nroff and troff mode if you felt that
 worked better.

Didn't bother.

 I suggest following pod2man's lead and putting this in a preamble:
 
   .ie !\n(.g .ds Aq \(aq
   .el.ds aq '
 
 Then you can use \*(Aq.

Done upstream (r8640).

(in #518690:)
 I should package a halibut snapshot or backport the relevant patches
 (r8309, r8321, and r8322) from Subversion - or upstream could do a 1.1
 release. :-) Jacob, what do you think?

I'd just package a snapshot. I don't know when a 1.1 might appear --
1.0 was, I think, a fairly artificial milestone -- and I don't think
especial care is being taken to ensure that Halibut source for new
versions of PuTTY, sgt-puzzles, etc is even compatible with 1.0 (I
believe upstream builds distribution tarballs with a snapshot).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#496063: hyphens in halibut

[Jacob Nevins]

Alexander Prinsier wrote:
 So the upstream version of halibut will just output '-' instead of '\-'?

Up until r8641 it did, yes.

 Am I right to think that this means all man pages produced by halibut  
 have to be patched by the maintainers to get '\-' instead of '-'? Or  
 will the maintainer of halibut in Debian patch it to output '\-' anyway?

Is the version of halibut in Debian relevant? If you're packaging the
upstream tarball of agedu, I believe it's what upstream is running
when producing the tarball that counts.

 I'm packaging agedu. It's manpage is also produced by halibut and I'm  
 facing the same issue. For now I just patched the manpage to show '\-'  
 but this really should be fixed in halibut instead.

I see you've now packaged agedu. You'll probably find that a new
upstream tarball will remove the need for your patch (I'm not sure
when upstream's halibut gets rebuilt from SVN).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#541950: mu-cade: man page erroneously documents a7xpg

[Jacob Nevins]

Package: mu-cade
Version: 0.11.dfsg1-4
Severity: minor
Tags: patch

The man page mu-cade(6) contains some text that looks suspiciously
like a description of a different game entirely, a7xpg.

The attached trivial patch removes the erroneous text (without
attempting to replace it).
--- mu-cade.6.orig	2009-08-16 22:40:17.0 +0100
+++ mu-cade.6	2009-08-16 22:42:21.0 +0100
@@ -19,9 +19,8 @@
 mu\-cade \- chase action game
 .SH DESCRIPTION
 The Physics Centipede Invasion
-Smashup waggly shmup, 'Mu\-cade'
 
-The goal of the game is to collect all the gold bullions found in each level and avoid crashing into any of the enemies. As you progress through the levels you will encounter harder enemies, and you can gain a short period of invincibility if you gather gold at high speeds.
+Smashup waggly shmup, 'Mu\-cade'
 .SH OPTIONS
 These command\-line options are available:
 .TP 

Bug#541951: rrootage: man page usage summary doesn't mention -fullscreen option

[Jacob Nevins]

Package: rrootage
Version: 0.23a-8
Severity: minor
Tags: patch

The man page rrootage(6) has a usage summary, but it misses an option
which is documented in the body of the page: -fullscreen.

The attached trivial patch replaces it (and removes some spurious
backslashes).
--- rrootage.6.orig	2009-08-16 22:56:40.0 +0100
+++ rrootage.6	2009-08-16 22:57:19.0 +0100
@@ -18,9 +18,10 @@
 .SH SYNOPSIS
 .
 .B rrootage
-[\\-lowres|\\-mediumres|\\-highres]
+[\-lowres|\-mediumres|\-highres]
 [\-nosound]
 [\-window]
+[\-fullscreen]
 [\-reverse]
 [\-nowait]
 [\-accframe]

Bug#526670: FTBFS with GCC 4.4: dereferencing pointer breaks strict-aliasing rules

[Jacob Nevins]

Martin Michlmayr writes:
 Your package fails to build with GCC 4.4.  You can reproduce this problem
 with gcc-4.4/g++-4.4 from unstable.
  [...]
  ../unix/uxnet.c: In function 'sk_getxdmdata':
  ../unix/uxnet.c:973: error: dereferencing pointer 'sa' does break 
  strict-aliasing rules
  [...]

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530949 gcc-4.4:
warns about idiomatic use of Berkeley sockets appears relevant. That
in turns leads to https://bugzilla.redhat.com/show_bug.cgi?id=448743
which describes how to make this go away (and suggests that the
presence of the warning can imply actual incorrect code).

I've committed a fix upstream http://svn.tartarus.org/sgt/?rev=8612view=rev.
I couldn't conveniently lay my hands on GCC-4.4, but a random Ubuntu
gcc-snapshot package emitted the warnings without the change and no
longer does.

I'm not entirely sure I fully understand the strict-aliasing rules,
however; in particular, I'd appreciate advice as to whether the
remaining cast in sockaddr_is_loopback() is naughty.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#518690: putty-tools: Puttygen doesn't generate keys

[Jacob Nevins]

 If I type, according to the man puttygen(1),
 puttygen ???t rsa ???C my home key ???o mykey.ppk
 I get
 puttygen: cannot handle more than one input file
  [...]

My guess is that those are some Unicode hyphen-like characters on your
command line, rather than ASCII hyphens - -- your mail suggests that
(my mailer will have mangled them in the quoted text) and I expect
puttygen will treat words starting with such characters as filenames
rather than options.

Are you pasting an example directly from the man page? If so, what
happens if you type the option dashes directly on your keyboard?

If this is the problem, the funny characters should be removed from the
examples on the man page (but that's not a Grave bug).



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#417547: sgt-puzzles: Please support keyboard-only play in more puzzles

[Jacob Nevins]

A big pile of patches from James Harvey has recently been committed
upstream to add keyboard support to lots of puzzles. As of r8439
(today's), relative to the current Debian package (r7983), keyboard
control has been added to the following:
  Black Box
  Filling
  Galaxies
  Map
  Mines
  Netslide
  Pattern
  Pegs
  Rectangles
  Sixteen
  Slant
  Solo
  Tents
  Twiddle
  Unequal

This covers all the puzzles specifically requested above.

Thus, I think the only puzzles still without keyboard control are
Bridges, Dominosa, Loopy, and Untangle. (I don't know if any more
patches are on their way.)

(Unrelatedly, a new upstream version would bring an overhauled Loopy
with a different solver and non-square grids.)



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#496063: 'man pterm' uses unicode dashes for option markers, in unicode locale

[Jacob Nevins]

rjk writes:
 Subject: 'man pterm' uses unicode dashes for option markers, in unicode locale
  [...]
 OPTIONS$
The command-line options supported by pterm are:$
 $
[EMAIL PROTECTED]@M-^Pe command [ arguments ]$
^^

and Colin replies:
 I think this is a halibut bug; it turns \- (non-breaking hyphen) into
 \(hy. I suspect that in practice \- would be more appropriate for manual
 page output.

I think this is fixed in upstream halibut[*] as of r8309. We're emitting
- rather than the \- you suggest; a little experimentation suggests
that we're doing the Right Thing, as the former tends to come out as
U+002D HYPHEN-MINUS (what we want) whereas the latter has minus-sign
semantics and tends to come out as U+2212 MINUS SIGN.

  [*] Apparently freshwater halibut do exist. Learn something every day.

rjk also writes:
 Also it uses curly quotes instead of the ascii apostrophe sign in the 
 pterm -e example.

This isn't yet fixed upstream. The options appear to be:
  ' Current; right quote semantics so tends to generate
U+2019  RIGHT SINGLE QUOTATION MARK
  \'Acute accent semantics so tends to generate
U+00B4  ACUTE ACCENT
  \(aq  Apostrophe quote; appears to generate what we want,
U+0027  APOSTROPHE

I'm going to go for generating the latter, but I'm slightly nervous
because that named character is not in the classical troff reference,
http://www.kohala.com/start/troff/cstr54.ps, so I'm worried about its
portability. Opinions?

(There's also an equivalent issue with backticks; \` appears to be the
way to go here. Reading troff documentation suggests that these are
likely to be the only problematic characters.)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#496063: 'man pterm' uses unicode dashes for option markers, in unicode locale

[Jacob Nevins]

I wrote (on hyphens):
 I think this is fixed in upstream halibut[*] as of r8309. We're emitting
 - rather than the \- you suggest; a little experimentation suggests
 that we're doing the Right Thing, as the former tends to come out as
 U+002D HYPHEN-MINUS (what we want) whereas the latter has minus-sign
 semantics and tends to come out as U+2212 MINUS SIGN.

(Although trying it on NetBSD in a UTF-8 locale for the sake of testing
portability, I couldn't find a way to get it to emit a U+002D at all,
not that that's your problem. Ugh, it's all horrible.)

 rjk also writes:
  Also it uses curly quotes instead of the ascii apostrophe sign in the 
  pterm -e example.
 
 This isn't yet fixed upstream. The options appear to be:
   ' Current; right quote semantics so tends to generate
 U+2019  RIGHT SINGLE QUOTATION MARK
   \'Acute accent semantics so tends to generate
 U+00B4  ACUTE ACCENT
   \(aq  Apostrophe quote; appears to generate what we want,
 U+0027  APOSTROPHE
 
 I'm going to go for generating the latter, but I'm slightly nervous
 because that named character is not in the classical troff reference,
 http://www.kohala.com/start/troff/cstr54.ps, so I'm worried about its
 portability. Opinions?

This is now implemented upstream as of r8322, so upgrading the package
to that version or later should be sufficient to fix this Debian bug.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#414784: [putty] [EMAIL PROTECTED]: putty-tools: [PUTTYGEN] [PATCH] requires a final newline]

[Jacob Nevins]

Slightly modified patch applied upstream in r8323.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#503186: [putty] Bug#503186: plink -L listens to IPv6 interface only!

[Jacob Nevins]

Eduard Bloch writes:
 could you please tell us exactly what you are trying to say? In the
 Ubuntu bug report you mention, it's clearly stated that that fix
 is NOT included in 0.60

Yes. We have fixed the bug in upstream SVN since 0.60 was released.
The fix has not yet gone into a new release.

 and might be ported from some development stage into 0.60.
 And I see no progress in this process since July.

We (upstream) can't port it to 0.60 because that's already been
released. It'll almost certainly be fixed in a forthcoming 0.61,
whatever other content that release has, but we don't have a schedule
for that yet.

That was a suggestion to the Ubuntu package maintainer (who, FTAOD,
isn't me) in case they wanted to fix it without waiting for a new
upstream release. It's up to them.

 And in fact, 0.60-3 (Debian package version) is also broken here,
 just tested. 

Yes, that's expected.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#503186: [putty] [EMAIL PROTECTED]: Bug#503186: plink -L listens to IPv6 interface only!]

[Jacob Nevins]

Colin Watson writes:
 [Eduard Bloch:]
 plink -L does not work for me, because it listens only to the v6
 socket on the localhost interface. I.e. the v4 socket is not bound,
 regular v4 programs cannot use it.
 [snip details]
 
 This is a notorious swamp and it took OpenSSH several goes to get it
 right. I think the basic difference between OpenSSH and PuTTY here is
 that OpenSSH loops round and binds to all available interfaces, while (I
 think) PuTTY stops once a single bind succeeds.

This report is against 0.58. Since then (in fact, since 0.60, so only
in development snapshots) we've changed the behaviour, as described at
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/portfwd-addr-family.html;
this was partly prompted by a bug report against Ubuntu,
https://bugs.launchpad.net/ubuntu/+source/putty/+bug/67488.

Have we got it right yet, or are we still blundering around in the
swamp?

(I haven't tried to digest the details of Eduard's bug report re the
finer points of getaddrinfo() invocation etc.)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#501197: sgt-puzzles: minor infelicity in Unequal hit detection

[Jacob Nevins]

Package: sgt-puzzles
Version: 7983-1
Severity: minor

In Unequal, areas outside squares to the top and left are sensitive to
clicks, as well as all of the squares themselves; but areas to the
bottom and right are not similarly sensitive.

I believe this is caused by the Debian-specific patch
104_fix-unequal-hit-detection.diff. I haven't dug into the history, but
I'm guessing this was intended to recentre the hit detection so that
clicks outside of their squares applied to their nearest squares.
However, as of r7400 (Mar 2007), upstream disallows clicks between
squares entirely; I believe the Debian behaviour is a result of the
interaction of these two changes.

So, I'd recommend removing that patch from the Debian package.

(Found while reviewing patches for applicability to upstream. I admit I
didn't actually run the Debian binary package, but I reviewed the source
and built it on Ubuntu, which should be equivalent.)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#413341: gsm-utils: Gsmsendsms fails with SonyEricsson W880 (fix included)

[Jacob Nevins]

The Sony Ericsson K800i suffers from the same problem (unsurprisingly).

I found the patch in this bug wasn't reliable, as it discarded some
status messages that were important, resulting in gsmpb returning
incomplete phonebooks and gsmsmsstore crapping out. Result of hacking
until it worked attached -- this allowed reliable use of gsmpb and
gsmsmsstore for me. (The patch isn't suitable for applying directly to
the package, though! -- it needs redoing properly.)
--- gsmlib-1.10.orig/gsmlib/gsm_at.cc
+++ gsmlib-1.10/gsmlib/gsm_at.cc
@@ -106,11 +106,27 @@
   putLine(AT + atCommand);
   // and gobble up CR/LF (and possibly echoed characters if echo can't be
   // switched off)
+  // Also, some mobiles (e.g., Sony Ericsson K800i) respond to commands
+  // like at+cmgf=0 with +CMGF: 0 on success as well as the OK
+  // status -- so gobble that (but not if that sort of response was expected)
+  // FIXME: this is a gross hack, should be done via capabilities or sth
+  #include string
+  string::size_type loc = atCommand.find( =, 1 );
+  string expect;
+  if (loc != string::npos) {
+  expect = atCommand;
+  expect.replace(loc, 1,  );
+  expect.insert(loc, :);
+  } else {
+  expect = ;
+  }
   do
   {
 s = normalize(getLine());
   }
-  while (s.length() == 0 || s == AT + atCommand);
+  while (s.length() == 0 || s == AT + atCommand || 
+ ((response.length() == 0 || !matchResponse(s, response)) 
+  (expect.length()  0  matchResponse(s, expect;
 
   // handle errors
   if (matchResponse(s, +CME ERROR:) || matchResponse(s, +CMS ERROR:))

Bug#483647: po4a: Please support halibut

[Jacob Nevins]

  Do you know if there are packages which use this format intensively (for
  testing).
  
 sgt-puzzles, cf. #483665

The documentation for PuTTY[*] is also in Halibut format. (And, of
course, Halibut's own documentation.)

  [*] http://www.chiark.greenend.org.uk/~sgtatham/putty/
  http://packages.qa.debian.org/p/putty.html

These three packages probably comprise the bulk of the corpus of
Halibut-format documentation out there.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#400804: putty-tools: puttygen can create world-readable private keys

[Jacob Nevins]

This has ended up in the CVE list (CVE-2006-7162) and as a Secunia
advisory http://secunia.com/advisories/24381.

Secunia had incorrectly listed both 0.58 and 0.59 as vulnerable (they've
recently corrected this). I suspect that the advisory was derived from
this Debian bug report, and I can see that a casual observer might think
it was only fixed in 0.60; for some reason, there are two fixed emails
in this report, and the later one has subject Bug#400804: fixed in
putty 0.60-1.

For the avoidance of doubt: this was fixed in 0.59, and only affects the
Unix version.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#379452: sgt-puzzles: please remember window size across type changes

[Jacob Nevins]

I've finally rolled in the last three patches from this bug (although
I was unable to test on Gtk+-1.2); r7366:7368. Thanks.

It's probably about time for a new version, anyway. Here are the other
major changes since r6879:
 - new puzzles: Unequal, Galaxies, Filling
 - solver improvements to Loopy
 - Guess now has optional alphabetical labels ('L' key)
 - puzzles now have icons


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#409219: halibut: version 1.0 is available

[Jacob Nevins]

Package: halibut
Severity: wishlist

Halibut has quietly hit 1.0. This seems like a good time to refresh the
Debian package.

(FWIW, the PuTTY 0.59 manual was rendered using a version a little
before 1.0.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#323791: #323791: PuTTY window title changes to reverse IP address

[Jacob Nevins]

I've reproduced this (in current code). It surprises me.

We had essentially the same report on Windows:
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/win-canonical-hostname.html
In this case, the Windows network code really was explicitly doing a
reverse lookup. I changed it to just pass AI_CANONNAME to getaddrinfo()
in r5614, and that restored the previous behaviour (namely, just
following CNAMEs).

However, we're already doing that in the Unix code! It seems that
getaddrinfo() is doing an explicit reverse lookup there. If I build with
NO_IPV6, the old-skool gethostbyname() appears to just do CNAME
resolution on Unix, as expected.

Ho hum. If getaddrinfo() can't be persuaded to just do CNAMEs, I suspect
this will have to wait until
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/window-title-keywords.html,
where we can add separate keywords for our current slightly-munged
hostname and the-exact-hostname-I-typed-dammit.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#265541: #265541: putty and pterm don't have an icon associated with their menu entries

[Jacob Nevins]

FYI, upstream has recently gained icons for the Gtk programs (so pterm
now has an official icon for the first time). Also, icons can be
generated at arbitrary resolutions from the source if required.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]