- IRC, OFTC, #debian-hurd, 2012-09-24
- IRC, freenode, #hurd, 2013-07-10
- IRC, freenode, #hurd, 2013-10-01
- IRC, freenode, #hurd, 2013-10-22
- IRC, freenode, #hurd, 2013-12-28
- IRC, freenode, #hurd, 2014-02-05
- IRC, freenode, #hurd, 2014-02-25
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:
<youpi> it does actually work
<youpi> simply dpkg-reconfigure keyboard-configuration
<youpi> and reboot
<youpi> (see http://www.debian.org/ports/hurd/hurd-install
<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
<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> http://xkbcommon.org/ ¡û 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
<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
<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
<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""
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
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
<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 snapshot.debian.org
<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)
<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 x.org people
<bu^> oh ok, nice, I'll look at it
<bu^> we are talking about this one ?
<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 http://www.kbd-project.org
<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