Bug#1079619: cpmtools package produces garbage output with cpmls

[Jacob Nevins]

Bdale Garbee writes:
> Sure, I can apply your patch in the Debian cpmtools package, since
> it has been accepted upstream.  I try to avoid forks, but gaining
> quicker access to something that is coming in upstream's next
> release seems good.

OK, here it is.
It's expected to be released in cpmtools 2.24.
Subject: libdsk: reset geometry if autoprobe isn't sane

So that weirdness from any misfiring auto-geometry heuristic in LibDsk
doesn't cause trouble later. (We were overwriting the most common
parameters, but not all of them.)
(Triggered by Debian bug #1079619, where a spurious dg_sidedness caused
trouble after LibDsk's Opus Discovery heuristic misfired -- that
heuristic has been improved in libdsk 1.5.20, but this change provides
defence in depth.)
---
 device_libdsk.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/device_libdsk.c b/device_libdsk.c
index 7baaed4..82b79d1 100644
--- a/device_libdsk.c
+++ b/device_libdsk.c
@@ -72,6 +72,7 @@ const char *Device_open(struct Device *this, const char *filename, int mode, con
 const char *Device_setGeometry(struct Device *this, int secLength, int sectrk, int tracks, off_t offset, const char *libdskGeometry)
 {
   char *boo;
+  int probeOk;
 
   this->secLength=secLength;
   this->sectrk=sectrk;
@@ -85,11 +86,22 @@ const char *Device_setGeometry(struct Device *this, int secLength, int sectrk, i
 return lookupFormat(&this->geom, libdskGeometry);
   }
   
+  /* Did the autoprobe guess right about the number of sectors & cylinders? */
+  if (this->geom.dg_cylinders * this->geom.dg_heads == tracks)
+  {
+probeOk = 1;
+  }
+  else
+  {
+/* If not, reset to a minimal geometry (to undo any randomness from
+ * a failed autoprobe), and guess some parameters */
+probeOk = 0;
+dg_stdformat(&this->geom, FMT_180K, NULL, NULL);
+  }
   this->geom.dg_secsize   = secLength;
   this->geom.dg_sectors   = sectrk;
-  /* Did the autoprobe guess right about the number of sectors & cylinders? */
-  if (this->geom.dg_cylinders * this->geom.dg_heads == tracks) return NULL;
-  /* Otherwise we guess: <= 43 tracks: single-sided. Else double. This
+  if (probeOk) return NULL;
+  /* We guess: <= 43 tracks: single-sided. Else double. This
* fails for 80-track single-sided if there are any such beasts */
   if (tracks <= 43) 
   {
-- 
2.30.2

Bug#1079619: cpmtools package produces garbage output with cpmls

[Jacob Nevins]

I wrote:
> So what needs to happen is:
> 
>  - libdsk's dg_opusgeom() needs to get more discriminating, at the
>very least, so it doesn't misfire on disc images like yours (but I
>don't know enough about the Opus Discovery to speculate how);

This has happened; John Elliott has released libdsk 1.5.20, with a fix
that's sufficient to solve this problem.
I've poked Debian bug #1027767 to note that an upgrade to Debian's
version of libdsk would fix this bug.

>  - maybe libdsk could usefully learn about TIM 011 boot sectors
>specifically [...]

(This hasn't happened, and doesn't need to.)

>  - probably cpmtools' device_libdsk.c:Device_setGeometry() needs to be
>more thorough about sanitising DSK_GEOMETRY if it decides the
>autodetected geometry was garbage.

I've sent a patch for this to cpmtools upstream, which has been accepted
and will be in the next upstream release, whenever that is.
That patch alone is also sufficient to solve this problem.

Dunno what you want to do in Debian.
Since a fix in either libdsk or cpmtools would be sufficient to fix this
bug, we could do the thing of assigning the bug to both packages.
If you don't want to wait for either the Debian libdsk maintainer or
cpmtools upstream, I could send you my cpmtools patch to apply in
Debian?

Bug#1027767: libdsk: New upstream version 1.5.20 available

[Jacob Nevins]

Control: retitle -1 libdsk: New upstream version 1.5.20 available

1.5.20, released a couple of days ago, adds a change that's sufficient
to fix Debian bug #1079619, as well as a few other bugfixes and
features.

Bug#1079619: cpmtools package produces garbage output with cpmls

[Jacob Nevins]

> With original packages, I first got this as an output when I used -T
> raw,tim011 (using my diskdefs file):
> 
> cpmls: unknown format ibm-3740
> 
> After not being able to figure this one out, I have added that definition to 
> my diskdefs file (from original cpmtoold diskdefs), but calling
> 
> cpmls -T raw,tim011 demo.img
> 
> still produced garbage. [...]

You need to continue to specify -f, as well as -T:
$ cpmls -T raw,tim011 -f tim011 demo.img 

(-f to tell cpmtools where to look in diskdefs, and -T to tell libdsk
where to look in .libdskrc)

> Thank you all for helping in this obscure retro-computing puzzle...

It's been a fun diversion!

Bug#1079619: libdsk: Opus Discovery heuristic misfiring on TIM-011 image

[Jacob Nevins]

Hello John,

In https://bugs.debian.org/1079619, someone found that building cpmtools
against libdsk stops it being able to read their TIM-011 disc image.

I think this is due to libdsk's dg_opusgeom() mis-detecting the TIM-011
boot sector as an Opus Discovery one, and thus initialising the geometry
with garbage.
(Lots more information in the bug, which I have CC'd on this mail.)

I think dg_opusgeom() needs to become more discriminating, but I don't
know enough about the Opus Discovery to suggest how.
(Arguably there should also be more defenses elsewhere; I might submit a
patch to cpmtools to be more defensive here.)

Bug#1079619: cpmtools package produces garbage output with cpmls

[Jacob Nevins]

I wrote:
> So what needs to happen is:
> 
>  - libdsk's dg_opusgeom() needs to get more discriminating, at the
>very least, so it doesn't misfire on disc images like yours (but I
>don't know enough about the Opus Discovery to speculate how);
> 
>  - maybe libdsk could usefully learn about TIM 011 boot sectors
>specifically, especially if they have geometry information embedded
>in them. (Again, I know nothing about these; do you know of docs/
>people who might know more? Ideally English-language, but
>understand if not.)
>But this isn't strictly necessary; if none of the boot sector
>heuristics misfire, libdsk's dsk_defgetgeom() should return an
>inoffensive default geometry that doesn't cause trouble.
> 
>  - probably cpmtools' device_libdsk.c:Device_setGeometry() needs to be
>more thorough about sanitising DSK_GEOMETRY if it decides the
>autodetected geometry was garbage.

Some more brain-dumping, mainly for the benefit of upstreams trying to
fix this.
tl;dr: I'm reasonably sure there isn't any geometry information directly
included in the TIM-011 boot sector, so it's probably not worth libdsk
learning to spot one.

(This is all freelance research; I started knowing nothing about the
TIM-011 or the SB-180 it's based on, and I'm sure you know a lot more,
so apologies if I got it wrong or missed existing documentation.)

I think:
The boot ROM decides between three formats by issuing a READ ID command
to the FDC, and looking at the length of the first sector it finds.
It loads the first 1024 bytes off the disc into memory starting at
0x8000, and passes control to that, providing format info in the A
register.
(see https://github.com/msolajic/tim011-system-software/blob/main/bootrom.z80
and particularly DISKTYPE)
>From disassembling the boot tracks (I didn't find existing
disassembly/source), the first 128 bytes loads the first two tracks
(total 10 kibyte) -- head 0 cyl 0 then head 1 cyl 0 -- and passes
control to them. (I guess this is the CP/M / Z-system code.)

This boot track is clearly designed to be used on discs of multiple
geometries, since it tests for whether the boot ROM determined the disc
had a 40-track format, and adjusts its own FDC parameters accordingly.
(I don't know the provenance of the boot tracks in this image -- they're
almost identical to
https://bitbucket.org/zzarko/tim011-tools/src/master/empty.img -- or if
there are different ones out there for this platform. I can provide my
partial disassembly if it's of interest.)

I think these are the three formats the boot ROM understands, in libdsk
terms:

FDC sec size1   2   3 (or anything else)
Description =   Hitachi 40 trk  80 trk
Secsize =   256 512 1024
Sectors =   16  10  5
Secbase =   1   17  17
Cylinders = ??? 40  80
Heads = 2
Sides = Alt
Recmode = MFM

(And the provided boot sector is able to cope with being on the
latter two.)

I've also tested that if I nobble dg_opusgeom() in libdsk to always
return DSK_ERR_BADFMT, the original symptom goes away.

I'll alert John Elliott (libdsk upstream) to this bug now.

Bug#1079619: cpmtools package produces garbage output with cpmls

[Jacob Nevins]

> [Zarko Zivanov:]
>> I have previously used cpmtools_2.20 and had no problems. With the
>> recent version from repository, I am getting garbage printed on
>> screen when I try to list the contents of an IMG file (or, actually,
>> many IMG files, this one is just an example).

I wrote:
> I think the significant difference is probably that between 2.20-2 and
> 2.23-1, Debian's package started to be built against libdsk.

(Really, 2.23-3.)

OK, I think I know what's going on.
(Sorry, this is a bit of a braindump.)
I think the main fix is going to have to be in upstream libdsk -- I
think it's a misfiring heuristic there -- but I don't have a complete
strategy yet.

If I look at your image contents with "fsed.cpm -f tim011 demo.img"
with my LibDsk build of cpmtools (which should be similar to Debian's),
I can see that the tracks are misnumbered compared to my plain build --
what ought to be odd-numbered tracks (1, 3, etc) end up together as
track 80+, with the first tracks displayed being what ought to be track
0, 2, 4, ...
So the CP/M directory ends up in the wrong place (diskdefs tells
cpmtools it should be at the start of track 2), and cpmls shows garbage.

Vanilla cpmtools doesn't really have a notion of heads or sidedness --
to it, this disc image is a consecutive set of 160 tracks in ascending
order 0..159, without worrying about the relationship of track number to
(cylinder, head).
libdsk has a more sophisticated notion of heads/sidedness, and supports
image formats where tracks aren't ordered in the obvious way, and has
various heuristics to determine disc geometry from image file contents,
so there's more to go wrong.

Using libdsk's 'dskid' tool (which in Debian lives in the libdsk-utils
package) on your image to see what libdsk guesses about its geometry in
the absence of cpmtools' diskdefs, I can see libdsk has got an idea of
the geometry from somewhere which is utter nonsense ("Heads: 128" etc):

$ dskid demo.img
demo.img:
  Driver:  Raw file driver (alternate sides)
  Sidedness: OutOut
  Cylinders: 110
  Heads:  128
  Sectors:   49
  First sector:   1
  Sector size: 32768
  Data rate: SD
  Record mode:  MFM
  Complement:   No
  R/W gap: 0x2a
  Format gap:  0x52

  Drive status:  0x28

In particular, I think the "Sidedness: OutOut" in libdsk's garbage
geometry is causing our trouble -- that will cause the tracks to be
reordered.

Within cpmtools, the libdsk driver can cross-check this auto-detected
geometry with what diskdefs says, and correctly rejects this as garbage.
However, it isn't careful enough to discard all fields from the
garbage geometry; in particular, "Sidedness" leaks through.
(cpmtools device_libdsk.c:Device_setGeometry())

So where did the nonsense come from?

In the absence of clues about geometry from the disc image format (of
which there aren't any with a raw disc image like this, for which libdsk
correctly auto-selects its 'raw' driver), libdsk tries to infer clues
from the (presumed) boot sector at the start of the disc image.

Reading the libdsk source, what I think is happening is that libdsk is
misdetecting this image as having the boot sector of an "Opus Discovery"
(libdsk lib/dskgeom.c:dg_opusgeom()).
That has very weak magic -- it just checks whether the first byte is
0x18, and if it is, then it reads geometry out of nearby bytes, without
any sanity checking. The result matches the garbage we see from 'dskid'.
And indeed the first byte of your disc image is 0x18 ("Z80 relative
jump", so hardly unlikely to show up in an unrelated Z80 machine's boot
sector).

So what needs to happen is:

 - libdsk's dg_opusgeom() needs to get more discriminating, at the
   very least, so it doesn't misfire on disc images like yours (but I
   don't know enough about the Opus Discovery to speculate how);

 - maybe libdsk could usefully learn about TIM 011 boot sectors
   specifically, especially if they have geometry information embedded
   in them. (Again, I know nothing about these; do you know of docs/
   people who might know more? Ideally English-language, but
   understand if not.)
   But this isn't strictly necessary; if none of the boot sector
   heuristics misfire, libdsk's dsk_defgetgeom() should return an
   inoffensive default geometry that doesn't cause trouble.

 - probably cpmtools' device_libdsk.c:Device_setGeometry() needs to be
   more thorough about sanitising DSK_GEOMETRY if it decides the
   autodetected geometry was garbage.

Workarounds:

One workaround which gets your image working with my libdsk-built
cpmtools is to add "-T rawoo" to the command-line.
This is a fragile bodge, though; it compensates "Sidedness: OutOut" at
a different layer rather than reversing it, and it might not stay
working with different disc images or libdsk versions.

Here's a less fragile workaround, which prevents the misfiring heuristic
running at all, by providing the libdsk layer with information about your
disc format (yes this does duplicate what's alread

Bug#1079619: cpmtools package produces garbage output with cpmls

[Jacob Nevins]

> I have previously used cpmtools_2.20 and had no problems. With the
> recent version from repository, I am getting garbage printed on
> screen when I try to list the contents of an IMG file (or, actually,
> many IMG files, this one is just an example).
> 
> In the archive is example image file with disk definition. Here is
> the command that produces the output that can be seen in ksnip.png
> image from attachment:
> 
> cpmls -f tim011 demo.img
> 
> The same command produces this correct output with cpmtools_2.20:
  [...]
> I have tried to compile cpmtools package from author's source,
> version 2.23 (http://www.moria.de/~michael/cpmtools/) and that one
> also works correctly.

I think the significant difference is probably that between 2.20-2 and
2.23-1, Debian's package started to be built against libdsk.
I can reproduce your symptom in my own libdsk build of 2.23, and it
doesn't happen in a build without libdsk.

(Still looking, please don't rip libdsk support out of the Debian
package just yet...)

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,&filestat) < 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  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
.
Flag is described as "PD image" in that ticket, but the version of

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 .
The then-current version of the Commons file

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]

> 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#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#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
 .
 .PP
 This manual page was written by Vincent Cheng ,

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., ,
), 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?


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.



-- 
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:

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.

( 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.
--- 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#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:
> 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 ).

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 -- 
 -- 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:
> 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:
> 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  (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=detailitem&item_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]

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

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]

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.
 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#700222: freeciv-server: irrigation of swamps broken

[Jacob Nevins]

I wrote:
> : 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#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#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
.


-- 
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#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#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#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]

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).

: 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#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. )

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#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.



-- 
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 .

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#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#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#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 
 #include 
 #include 
 #include 
+#include 
 
-#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 @@
   Thibaut">
   Paumard">
   
-  February 6, 2008">
+  October 17, 2010">
   8">
   <paum...@users.sourceforge.net>">
   
@@ -54,6 +54,8 @@
 
   -v
 
+  -f fillval
+
   filesystem
 
   
@@ -63,12 +65,19 @@
 &dhpackage; finds the unallocated,
non-zeroed blocks in an ext2 or ext3
filesystem (e.g. /dev/hda1) and
-   fills them with zeroes. This is useful if the device on which
+   fills them with zeroes (or another octet of your choice).
+
+Filling unused areas with zeroes is useful if the dev

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: 
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
, 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, ).

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#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#560248: ltris: FTBFS: uses LC_ALL without including

[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 .

I think this might happen to work in some build environments; at least
on my system, the  they do include looks like it includes
 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 
+/* Get declarations of setlocale() and LC_ALL.  */
+# include 
 
 #else
 

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#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#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#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
  [...]

 "gcc-4.4:
warns about idiomatic use of Berkeley sockets" appears relevant. That
in turns leads to 
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 .
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#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#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,
> , 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#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,
, 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#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
;
this was partly prompted by a bug report against Ubuntu,
.

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]