IRC, OFTC, #debian-hurd, 2012-09-24

<allesa> hello, I'm trying to get familiar with the Hurd and would like to
  change the keyboard layout in use. It seems all the information I can
  find (relating to console-driver-xkb) is out of date, with the latest
  info relating to it being that this package should not be used anymore…
<allesa> does anyone know how changing keyboard layouts currently works?
<allesa> ah, never mind. I assume it doesn't currently work:
<allesa> *
<youpi> it does actually work
<youpi> simply dpkg-reconfigure keyboard-configuration
<youpi> and reboot
<youpi> (see
<youpi> )
<allesa> mhm, I got that far — but selecting my layout gave me no joy, even
  after restart. Seem to be stuck with the layout chosen during
  installation (d-i). Just to check I'm using the right version — still on
  the installer isos from 15 July?
<allesa> wait… progress is being made — slowly and subtly… 
<allesa> Ok, so the XKBLAYOUT is changing as you described, but XKBVARIANT
  seems to be ignored. Could this be right?
<youpi> yes, the hurd console only supports keymaps
<youpi> (currently)
<allesa> Ah OK, thanks for your help on this. I imagine this is not
  something that just requires simple repetitive work, but some actual
<allesa> to fix that is…
<youpi> some hacking yes

IRC, freenode, #hurd, 2013-07-10

<pinotree> ‘¡û sounds interesting for our console

IRC, freenode, #hurd, 2013-10-01

<pinotree> teythoon_: df: `/dev/cons': Operation not supported
<pinotree> missing/stub implementation in the console translator?

IRC, freenode, #hurd, 2013-10-02

<teythoon_> pinotree: yes, df does file_statfs which fails

IRC, freenode, #hurd, 2013-10-22

<C-Keen> hello hurders! I happened to watch samuel's gnu hackers talk and
  wanted to start to use the hurd more regularily. However I noticed that
  when I use the preinstalled image, there seems to be some issue with the
  console driver
<C-Keen> when I start emacs the mode line is drawn 3 times above the bottom
  of the screen
<C-Keen> is this know or did I miss a step in setting it up? Or should I
  use the debian installer and start from scratch again?
<youpi> C-Keen: it's probably unknown, and not an issue on your side. Did
  you try to upgrade to the latest packages?
<C-Keen> youpi: doing that now
<C-Keen> my base image is debian-hurd-20130504.img
<youpi> still an issue with the latest packages indeed
<youpi> it seems emacs and the hurd console don't agree on the number of
<youpi> C-Keen: you can set TERM=vt100 to work around the issue
<C-Keen> ah alright.
<youpi> or TERM=linux
<C-Keen> youpi: can you start the emacs in X? I get an empty window here
<youpi> I never tried
<youpi> I never use emacs :)
<C-Keen> I see ;)
<youpi> it seems there's a bug in cud1 indeed
<C-Keen> what's cud1?
<youpi> see man 5 terminfo
<braunr> yes it's a terminfo problem
<braunr> the hurd console isn't well defined there
<youpi> braunr: actually it seems like a bug in emacs
<youpi> cud may or may not scroll the screen, depending on the

IRC, freenode, #hurd, 2013-12-28

<braunr> ahem, looks like the last xkb-data package dropped
  /usr/share/X11/xkb/compat/default :/
<ivanshmakov> braunr: Looks more like an upstream issue; check, e. g.,
<ivanshmakov> braunr: Slightly more surprising is that xkb-data 2.8 was
  packaged for Debian last Sunday. While the upstream has released 2.10.1
  back in October, as per
<gg0> ivanshmakov:
<ivanshmakov> gg0: ACK, thanks. (No idea how did I read 2.10.1 as 2.8, as I
  was looking on essentially the same information.)

IRC, freenode, #hurd, 2013-12-30

<ZenWalker> on debian/hurd, with startx, show the error "cannot open
  keyboard (no such file or directory)"
<braunr> ZenWalker: what version of xkb-data do you have ?
<ZenWalker> braunr: 2.10.1-1
<braunr> ZenWalker: there is a bug in that package
<braunr> you can confirm it by spotting an error during system startup that
  mentions a missing "compat/default" file
<braunr> this prevents the hurd console from starting
<braunr> and without the hurd console, xorg can't find the input device
<braunr> hopefully it will be fixed soon
<ZenWalker> braunr: yes, "couldn't open include file "compat/default""
<ZenWalker> thanks

IRC, freenode, #hurd, 2013-12-31

<braunr> youpi1: fyi, xkb-data doesn't provide compat/default, which
  prevents the hurd console from starting

<ZenWalker> braunr: X works with xkb-data 2.5.1-3 :)

<braunr> maybe xkb-data isn't the problem
<braunr> maybe we need to fix the hurd-console
<braunr> youpi: we should probably fix the hurd with regard to xkb-data
  before releasing the next packages
<braunr> it's very unlikely that xkb-data will be fixed
<braunr> they say compat/default is unused since march 2012

IRC, freenode, #hurd, 2014-01-01

<DusXMT> Is anyone else having problems with the console?
<gg0> downgrade xkb-data to
<DusXMT> ty

IRC, freenode, #hurd, 2014-01-04

<mihi> does anybody know if the fact that aptitude looks shitty on the hurd
  console is a bug in the console implementation or some broken
  term{cap,info} config?
<youpi> ncurses is pending a terminfo fix, possibly related
<youpi> you can try to recompile your hurd terminfo entry, adding xenl to
  it, and see whether it fixes it
<mihi> hmm, just did an aptitude upgrade, and now after a restart the Hurd
  console does not even start any more (did not mess with my terminfo yet)
<mihi> Couldn't open include file "compat/default"
<youpi> yes, xkb-data broke, downgrade it
<mihi> youpi, to which version?
<youpi> well, the previous one :)
<mihi> (or can aptitude or another tool show me what version I had
<youpi> you can simply take the but-last on
<mihi> youpi, thanks, that helped. And adding xenl to hurd.ti and
  recompiling helped, too :)

IRC, freenode, #hurd, 2014-01-13

<gnu_srs> Couldn't open include file "compat/default" from the console
<teythoon> that has been reported on the ml and as debian bug
<teythoon> a workaround is both in the upcoming hurd package as well as in
  the ones i provide in hurd-ci
<gnu_srs> Any workaround for the hang in the console for now?
<teythoon> there is no hang
<teythoon> there is simply no getty
<gnu_srs> how come?

<gnu_srs> and the xkb-data problems I thought was causing problems with the
  hurd console to start, not the mach console.
<teythoon> gnu_srs: exactly, the missing xkb data prevents your
  hurd-console from running

IRC, freenode, #hurd, 2014-02-05

<bu^> btw, does the console handle other keymaps than the qwerty US one ?
  Samuel thibault talked about this during his fosdem conference
<braunr> it does
<braunr> check /etc/default/hurd-console
<bu^> how ? I mean which lib does it use, because I face a similar issue
  with my programms and would like a "smart" way to handle this (meaning
  not reimplement something doing it worse)
<bu^> thx
<braunr> bu^: xkb
<bu^> I'm not clear with xkb and how much it is related to xorg, I would
  like to be xorg independant, but the hurd console also should be and it
  seems to work
<youpi> bu^: xkb is just a library
<youpi> xorg uses it
<youpi> but other applications can use it
<youpi> it just happens to be maintained by people
<bu^> oh ok, nice, I'll look at it
<bu^> we are talking about this one ?
<youpi> yes
<bu^> btw the way special caracters like é or à breaks the backspace
  (erase) key as it will not count properly the number of caracters on the
<bu^> and I end up with remaining caracters I can't erase
<bu^> I also started to look for this one but didn't find a proper way to
  use it as a library
<youpi> bu^: probably a bogus locale
<youpi> that just works for me

IRC, freenode, #hurd, 2014-02-25

<gg0> to reproduce "task f5ca6e40 deallocating an invalid port 1711, most
  probably a bug." just restart hurd-console