IRC channel logs


back to list of logs

***Server sets mode: +nt
<almuhs>I'm checking the videocard of my R60e, and this have the same chipset than T60. Some months ago, I got to start Xfce in this, using Debian GNU/Hurd 2017. But now It shows the same error than T60. Can be this an error in any upgrade?
<youpi>it could be an issue with the vesa driver finding the VBE
<almuhs>what is VBE?
<swivel>vesa bios extensions
<almuhs>swivel: thanks ;)
<damo22>almuhs: drm needs kernel drivers, so we probably want to use rump for that
<damo22>use the netbsd implementation of graphics drivers?
<almuhs>I didn't installed any special driver, only the defaults
<damo22>there is no driver for intel gfx in hurd
<almuhs>yes, but in other times, with R60e, I got to run Xorg anyway
<damo22>yeah because of VESA implementation which uses bios extensions
<almuhs>so I researching about the differences between R60e and T60
<almuhs>R60 and T60 can have different BIOS chipset, It's true
<damo22>almuhs: check your cmos settings, maybe there is a legacy video option
<damo22>or VBE/VESA setting
<almuhs>in BIOS menu?
<almuhs>ok, wait a minutes
<almuhs>R60e has Display configured as "Analog(VGA)"
<youpi>(FWIW, starting Xorg with the vesa driver seems to be working inside qemu, so it doesn't seem like a general issue with xorg's vesa driver accessing the VBE)
<damo22>hmm, maybe someone should copy qemu's implementation of VBE and put it in coreboot
<almuhs>I'm using Lenovo BIOS
<almuhs>in Lenovo BIOS doesn't appears any option about VESA
<swivel>doesn't Xorg give you some useful logging when it fails to start? I've little experience with hurd, but on linux Xorg logs are indispensible when troubleshooting this stuff
<youpi>he posted them on the list
<youpi>ah, sorry, I didn't know Almudena is a female name :) will try to remember
<almuhs>in my docs, I have notes about R60e required many attempts to run Xorg. But now I don't get It
<youpi>almuhs: just to make sure, are you booting in legacy or UEFI mode?
<youpi>that might make a difference in enabling VBE
<almuhs>R6oe and T60 are 2006 models. These doesn't have UEFI ;)
<youpi>(bios manufacturers tend to avoid exposing too many options to users, VBE is and oldie that they'd probably want to hide as much as possible)
<youpi>ah :)
<youpi>you could also try to run a Linux system without the intel or fbdev xorg driver, only the vesa driver
<almuhs>I tried It yesterday, with Debian 10. In this T60, Debian GNU/Linux with VESA didn't detected screen
<almuhs>I explained that in a email
<youpi>so it'd not be a hurd-specific issue
<almuhs>It seems not
<youpi>oh right, I missed that
<almuhs>despited of, using fbdev driver, I got to run Xorg
<almuhs>in Debian 10
<youpi>yes but that's using the fb drivers inside the Linux kernel
<almuhs>by I don't know how I got to run Xorg some months ago, with Debian GNU/Hurd 2017
<almuhs>i have documented that runs Xorg was a difficult task, and required many attempts, but I don't remember how exactly I got this
<almuhs>in R60e this time
<almuhs>(i have a T60 and R60e with same processor (Intel T2400) and graphics (945GM/GMS/GME) )
<almuhs>i have another T60 wide screen, in which I got to run Xorg easier than R60e some months ago. I can add this to the test ;)
<almuhs>I documented these tests here (in spanish, sorry):
<almuhs>damo22: btw, the "halt" command doesn't shutdown properly in Thinkpad *60 machines. It keeps the machine like hibernation
<almuhs>T60 widescreen also has the same graphics chipset. Installing xorg...
<almuhs>fuck... more dependencies conflicts
<almuhs>i have to continue tomorrow. the update has caused a serious dependency problems with glibc
<almuhs>seriosly, we need more Debian GNU/Hurd maintainers. The repository conflicts are more than common
<almuhs>I go to sleep
<damo22>yeah halt is broken because we need full ACPI parser
<damo22>ive cleaned up that irq patch, but im not sure how to handle vm_allocate_contiguous, should it be an RPC on the mem device?
<youpi>damo22: no, making it a variant of vm_allocate() should be fine
<youpi>it's really down to the kernel, at that point
<janneke>my hurd sees hd0s1, the linux partition (start ext2fs: ext2fs: device:hd0s1: panic: get_hypermetadata: could not mount because of unsupported optional features (0x2c0))
<janneke>but it does not see hd0s2: start ext2fs: ext2fs: device:2:hd0s2: No such device or address
<janneke>i'm going to re-install and move ext4+gnu/linux to sda2 and ext2+gnu/hurd to sda1 and see what happens
<janneke>sadly, the interweb say that the hurd has a 2GiB partition size (something that might have been true ~20y ago) but i cannot find much information on current limitations
<youpi>the wiki has the latest information
<janneke>youpi: thank you
<janneke>that's indeed my problem then, the ssd is 160GB
<youpi>(remember to use -o hurd when running mke2fs from linux)
<youpi>160GiB disk size is not a problem per se
<youpi>as long as you don't put data beyond the 128GiB limit
<janneke>(yeah, i know but thanks!)
<janneke>right, i had gnu/linux on 0-140GB and hurd from 140GB onwards
<youpi>(for almuhs: the dependency/conflict problems are not a question of debian hurd "maintainers", but a question of people investigating the build failures, there is no need for any particular status to be able to contribute to this. Just investigate, find a fix, submit it upstream, and once accept it backport to debian)
<youpi>once a fix is available, it's extremely easy for me to build&upload it to unreleased while waiting for the main debian archive to get it
<youpi>the 99% time part is before build&upload
<youpi>there's also currently a bsdmainutils dependency fuck-up, that's for all archs, not just hurd
<youpi>and as a reminder, when upgrading, better use first apt-get upgrade, and only then apt-get dist-upgrade
<almuhs>youpi: thanks by the info. (I read it in the log). But I need to know how to create a deb package, and how to upload it to backport
<youpi>what for?
<youpi>really, providing a patch is the 99% part of the time
<youpi>there's one thing you need to know: building a package. That's as simple as apt-get build-dep thepackage and dpkg-buildpackage
<youpi>(well, "apt-get source thepackage" too, of course)
<almuhs>and, if i find an error in the dependencies required for this package. how can i edit this dependency in package configuration?
<azeem>dependencies are in debian/control
<gnu_srs>youpi: Regarding libdrm there is already a patch available, see #909436. But that patch is similar to the kFreeBSD build, i.e. no kernel support for drm :(
<youpi>as already explained, better forward to upstream
<youpi>ah it seems it was
<almuhs>there are many packages that is missing. By example, there is "libreoffice-common", but not libreoffice. Can I build this packages from sources?
<youpi>gnu_srs: it seems the patch needs to be refresh. While skimming over it, I saw at least one bug: DRM_IOCTL_NR shouldn't be n & 0xff, but n & 0x7f. See glibc/sysdeps/mach/hurd/bits/ioctls.h's explanation about how the ioctl request is encoded, the number is 7bits only
<youpi>almuhs: there are not more than 30% packages missing, really
<youpi>libreoffice is a terrible beast, you can't expect it to be buildable :)
<youpi>the -common part is available only because it's an arch:all package
<almuhs>i've seen similar problems with golang packages
<youpi>there are some build failures in golang packages
<youpi>that'd need to be investigated
<youpi>but probably only after glibc 2.31 is uploaded, since it will fix a few things
<almuhs>and openjdk has same problems
<youpi>build issues, need to be investigated
<almuhs>oh, ok
<youpi>you know, if you go looking at bleeding edge, you'll bleed for sure
<youpi>for openjdk, the concern is also to establish a way to get things accepted by Oracle
<youpi>we e.g. added siginfo support for openjdk, but openjdk continued growing in non-portable ways
<youpi>so it'd be significant work to port it
<almuhs>and icedtea?
<almuhs>by example, gentoo use icedtea to avoid openjdk compile problems
<youpi>haven't looked at it, but it seems abandoned ?
<youpi>I mean, it's only supporting java 6 or 7, right?
<almuhs>i think icedtea supports java 8
<almuhs>i think icedtea is simply a fully free compilation of openjdk sources, or any similar thong
<youpi>in debian there isn't an icedtea package any more, but that could be revived
<almuhs>in gentoo is very common. maybe i can find its ebuild
<youpi>I'm just warning that again it's quite a beast
<youpi>to make it ported to non-linux
<almuhs>here is the fully ebuild
<youpi>so java8 yes, better than what we currently have (old java5 from ecj)
<youpi>but I'm still wondering how alive that project is
<youpi>thus whether it's better to spend time on it rather than on openjdk
<youpi>(since openjdk *is* buildable as it is on Debian, and people do spend time on making sure that it is)
<almuhs>gentoo doesn't includes pre-compiled binaries by default, so the only option offered is icedtea
<almuhs>the ebuild only includes the steps to download the sources and compile them
<almuhs>(the download and compilation is automatically done by portage, of course)
<azeem>Debian provides pre-compiled binaries, but they are all built by Debian
<youpi>and they can be cross-built
<almuhs>yes, i speak about the possibility of explore the Gentoo work to port icedtea to Debian GNU/hurd
<almuhs>the dependencies list and the compilation process, mainly
<azeem>it's a bit unclear from the two links above what exactly is the Hurd porting
<youpi>almuhs: the questions of porting icedtea/openjdk are not about dependencies etc. but actual .c code
<youpi>the dependencies etc. are already resolved by the existing debian packaging
<youpi>making an icedtea package on debian could indeed take the work from gentoo
<youpi>but in the end you'll be faced with the same difficult part: actually porting the .c code
<almuhs>yes, it's true
<youpi>note that as I mentioned above debian used to have icedtea packaged, that can be used for a way simpler start
<youpi>but again, it's really a beast, I'd rather recommend starting with smaller projects
<youpi>otherwise you'd just manage not to finish anything
<almuhs>yes, I agree
<almuhs>now I'm also working in smp, anyway
<almuhs>but i'm also using my thinkpad laptops to test Hurd over real hardware
<almuhs>and test possible common applications
<youpi>(smp already being a beast)
<almuhs>yes, but the first steps about detection, enumeration, enabling... are good defined in the intel manuals
<youpi>ok but that's only the tip of the smp question
<almuhs>now i'm refactoring all these work from the work i did the last year
<almuhs>yes, the concurrency problems can be many complex. But the cpus enabling and configuration is a basic step
<almuhs>i'm refactoring to prevent errors from global variables access and ease the debugging
<almuhs>i will try to send little patches for each basic step
<almuhs>damo22 are contributing in ioapic and lapic timer
<almuhs>(i try to avoid the i/o configurations, these are very complex for me)
<almuhs>the detection and enumeration step is almost ready. It works properly, but i'm working in a good code organization. the latest step was add a new file to separate my arch-dependent code and the general mach calls (to find current processor, by example)
<almuhs>*will be, not was
<almuhs>mmm... my T60 freeze during hurd package unpacking
<almuhs>second time i see this problem
<gnutec>Waiting for Hurd
***DNS is now known as snd
*janneke booted the hurd on real iron (for the first time since decades)
<almuhs>janneke: what machine are you using for Hurd?
<janneke>almuhs: a thinkpad x60
<almuhs>installed via qemu?
<janneke>installed via guix system reconfigure
<almuhs>Debian GNU/Hurd?
<janneke>no, Guix GNU/Hurd
<almuhs>and how it works?
<janneke>dunno...login works :-)
<janneke>and uname
<almuhs>test common applications
<almuhs>install nano, vim, emacs, git...
<janneke>now i'm wondering what command to run that shows i'm actually on real iron
<almuhs>screenfetch or neofetch
<janneke>ah, i have no lspci
<almuhs>it required root permissions
<almuhs>or install pci-utils
<janneke>almuhs: installing stuff won't work yet
<janneke>gotta do it with what's installed through guix system reconfigure :-)
<janneke>so...gotta add pciutils in the next round
<janneke>i did install some stuff, like gcc, gdb, git
<almuhs>python can be useful
<youpi>janneke: you can look at the dmesg to see the disk probing for instance
<almuhs>i never tested dmesg in hurd
<youpi>well, dmesg doesn't actually work, I meant the kernel logs
<youpi>which depending on how your box works, will get into /var/log/dmesg, /var/log/kern.log
<youpi>or is waiting for your cat /dev/klog
*janneke looks at /var/log/messages
<almuhs>youpi: after reinstall and upgrade my T60 widescreen, I can confirm that the Xorg problem appeared in any update
<janneke>well, git --help runs, and less
<almuhs>in this T60 widescreen I got to run Xorg with Debian GNU/Hurd 2017. But now I can't
<youpi>then the usual stuff: either try to upgrade progressively to see what package upgrade breaks it, or put printfs etc. in the vesa driver to see where it breaks
<youpi>normally the only packages which are involved are the hurd, libpciaccess, xserver-xorg-core, and xserver-xorg-video-vesa
<youpi>possibly it's the libpciaccess through the pci-arbiter that doesn't work with your VBE
<almuhs>libpciaccess was the cause of the network freezing problem in 2019 release
<almuhs>ok, I go to try downgrade
<janneke>hmm, "who" writes /var/log/dmesg on the Hurd (i see it in the debian vm; we don't have it yet on guix)
*janneke goes to read the faq
<almuhs>i need the snapshot repository of 2017 release
<youpi>janneke: usually that'd be rsyslog & such
<youpi>almuhs: the 2017 qemu image uses so that's probably it
<janneke>almuhs: hmm: lspci: could not open file `/servers/bus/pci'
<almuhs>janneke; execute lspci with root permissions
*janneke mounts /hurd/pci-arbiter
<janneke> lspci hangs...oh well
<janneke>oh, i don't have networking yet -- guix hardcodes that for the qemu VM
<almuhs>youpi: with 2017's libpciaccess0, Xorg works
<youpi>I'd say put printfs in the vesa driver calls to libpciaccess then
<almuhs>i don't know where is vesa driver
<almuhs>and i don't know how to patch this code
<youpi>see the Xorg log
<youpi>use dpkg -S
<youpi>and then you'll know the package that provides the driver file showing up in the Xorg log
<youpi>then apt-get source to get the source code
<youpi>apt-get build-dep to get the build dependencies
<youpi>then add printfs, then dpkg-buildpackage
<youpi>there's nothing really difficult here
<youpi>gnu_srs: I don't remember why you needed setsockopt(SO_SNDBUF), but I finished your patch, and it's now uploaded in debian
<almuhs>vesa.c has more than 1000 lines...
<youpi>that's small by most software
<youpi>the thing is: you *never* need to read it all
<youpi>use your editor to find references to libpciaccess
<hiperbolt>good take youpi
<youpi>really, never think "omg this is so large"
<youpi>we have software that have millions of lines of code
<youpi>but you can enter it, you just need to grep what you are looking for
<youpi>and you'll be able to work in it
<youpi>that's how everybody is doing
<almuhs>#if defined(XSERVER_LIBPCIACCESS) && !defined(HAVE_ISA)
<almuhs>#define VESAProbe NULL
<almuhs>static Bool VESAProbe(DriverPtr drv, int flags);
<youpi>nobody knows by heart anything beyonds thousands of lines
<almuhs>it's strange
<youpi>what is strange?
<almuhs>VESAProbe is set to NULL
<youpi>isn't HVAE_ISA defined?
<almuhs>is LIBPCIACCESS exists
<almuhs>i don't know
<youpi>I don't know either, but grep does know
<youpi>where it is defined
<youpi>and thus under what condition
<youpi>really, you need to take the habit of finding answers with grep etc.
<youpi>so you're able to dive by yourself
<youpi>also remember that you have build logs on
<almuhs>HAVE_ISA is not set in this file
<almuhs>youpi: thanks by the log
<youpi>that's why I say use grep
<youpi>grep is a hammer
<youpi>use hammers
<youpi>they work extremely well
<almuhs>HAVE_ISA must be defined by the compiler or some similar
<youpi>don't try to guess, grep
<youpi>guessing takes time
<youpi>grepping gives the answer
<almuhs>grep doesn't shows any #define HAVE_ISA
<almuhs>by this reason I know it
<youpi>it does show a line that defines it
<youpi>grep -r HAVE_ISA .
<youpi>shows a dozen occurrences
<almuhs>it's a configuration macro
<almuhs> [AC_DEFINE(HAVE_ISA, 1, [Have ISA support])],
<youpi>then check in the build log whether it gets enabled or not
<youpi>whether it used to be enabled or not, and nowadays how it is
<youpi>possibly that's not the actual problem, but it's worth checking it
<youpi>again, no guess work, just checking what seems odd
<almuhs> [AC_DEFINE(HAVE_ISA, 1, [Have ISA support])],
<almuhs> [],
<almuhs> [#include "xf86.h"])
<almuhs>this block is not hide under a if
<youpi>AC_CHECK_DECL *is* an if
<youpi>look in the autoconf documentation to know about that macro
<youpi>it's extremely common, leanr about it
<almuhs> AC_CHECK_DECL (symbol, [action-if-found], [action-if-not-found], [includes = ‘AC_INCLUDES_DEFAULT’])
<almuhs>then I have to find (xf86ConfigIsaEntity
<youpi>so check in the buid logs if the symbol is found, and whether it *used* to be found
<almuhs>checking whether xf86ConfigIsaEntity is declared... no
<youpi>so it's not found
<youpi>check in the old log whether it *used* to be found
<youpi>you always have cross-check, between something that works and something that doesn't
<almuhs>in this not
<youpi>that's the latest only
<almuhs>in the 2016 version is not
<youpi>then that's not the issue
<youpi>and I guess the fact that the probe function gets NULL is not actually a concern
<youpi>since the driver *did* work without it
<youpi>so continue checking for libpciaccess-enabled code in vesa.c
<almuhs>next is this
<almuhs>static Bool VESAPciProbe(DriverPtr drv, int entity_num,
<almuhs> struct pci_device *dev, intptr_t match_data);
<youpi>also, see that the code is not using printfs, but xf86DrvMsg()
<youpi>so use that to print your debugging lines
<almuhs>i need the definition of DriverPtr and struct pci_device. They are not in the vesa code
<almuhs>maybe they are in libpciaccess
<youpi>why do you need that?
<youpi>I believe for a first step all you need is to put debugging prints to check which pieces of code are getting called, are running correctly or returning an error
<youpi>no need to dive into more details
<youpi>once you get a line that seems to produce an error, you'll dive more precisely
<youpi>erf, split
<youpi>why do you need that?
<youpi>I believe for a first step all you need is to put debugging prints to check which pieces of code are getting called, are running correctly or returning an error
<youpi>no need to dive into more details
<youpi>once you get a line that seems to produce an error, you'll dive more precisely
<almuhs>i want to show the device and driver data in the print
<youpi>actually I don't think it will be useful
<youpi>and the thing is:
<youpi>before spending time on printing details
<youpi>rather spend time on printing which pieces of code actually get called
<youpi>so that you only spend time on printing details *there*
<youpi>thus reducing the amount of time you spend altogether
<almuhs>i want to show the call to this function
<almuhs>static Bool
<almuhs>VESAPciProbe(DriverPtr drv, int entity_num, struct pci_device *dev,
<almuhs> intptr_t match_data)
<almuhs>into, no to
<youpi>then just put an x86msg call in it
<youpi>no need for anything more fancy
<youpi>I'd just recommend putting the call in other functions as well
<youpi>you can use __func__ to get the function name as a char*
<youpi>then you can just copy/paste the same print line in all the functions you'd like
<almuhs>func() ?
<youpi>you can also use __LINE__ to get the line number as an int
<youpi>no, __func__
<youpi>that way you can have a single line of code that you just copy/paste everywhere you'd like to check that the driver is going through it
<almuhs>what is the syntax of xf86DrvMsg?
<almuhs>ok, i see
<almuhs>youpi: "func undeclared". maybe do you refers to put the function name in the message?
<youpi>no I mean __func__
<youpi>with double-underscores both on left and right
<youpi>exactly __func__
<youpi>no more no less
<almuhs>double underscores. It was missing
<almuhs>my IRC client doesn't shows underscores
<youpi>change IRC client :)
<youpi>if it doesn't print you verbatim what we say, with C code that can be a *real* concern
<almuhs>what IRC client do you recommends? I'm using Xchat
<azeem>it might think it was markdown
<azeem>though not sure xchat does that
<youpi>perhaps you can disable it
<youpi>personally I use pidgin, to manage not only IRC, but also XMPP, discord, etc.
<almuhs>I used pidgin many years ago to XMPP
<almuhs>*for XMPP
<youpi>(and ditto for __LINE__ which has double-underscores on left & right)
<almuhs>I go out. I will try to open IRC in pidgin
<youpi>yay, the pflocal fix fixed the pflocal crash during building at-spi2-atk
<youpi>probably it'll fix some other packages that were posing problem
<youpi>(that was really a pain)
<AlmuHS>hi from pidgin
<AlmuHS>ok, XD
<youpi>good :)
<AlmuHS>added prints. I've just packaged vesa. now rebooting
<AlmuHS>packaged and installed, btw
<youpi>I was about to ask :)
<youpi>(too used to students who forget to save, forget to compile, forget to run from the proper directory, etc.)
<AlmuHS>yes, I had this error many times
<youpi>all beginners have
<AlmuHS>upload the binary before compile :)
<youpi>non-beginners also have, but remember to check whether they thought doing it
<youpi>and thus compensate
<swivel>irssi for me but i like console tools
<AlmuHS>Hurd loading finished
<youpi>AlmuHS: Mmm, actually you shouldn't need to reboot?
<youpi>if you have all the toolchain etc. in your hurd, you can recompile, install, retry starting Xorg
<youpi>without rebootin
<youpi>spending some time on making that loop as small as possible is what will save you a lot of time in the long run
<AlmuHS>yes, but I was not sure about the previous version could be loaded in memory
<youpi>Xorg reloads the .so each time it starts
<youpi>it doesn't stay in memory
<AlmuHS>btw, where can i see the prints of vesa driver?
<youpi>in the same log
<azeem>just today I made some fixes in a failed build in a schroot and then forgot to copy them over before I later continued the build
<youpi>(that's why I told you to use the xf86 msg calls)
<AlmuHS>yes, I used It
<AlmuHS>but I don't see the messages into Xorg log
<youpi>do you have "driver for VESA chipsets" showing up ?
<AlmuHS>VESA appears in the log
<youpi>I really mean the 4 words I mentioned
<youpi>in some previous picture you showed, it was printing "VESA: driver for VESA chipsets: vesa"
<youpi>do you still have this?
<youpi>did you put a print in the VESAPciProbe function for instance ?
<youpi>did you try to put bogus C code to make sure that it was getting compiled-in?
<AlmuHS>[551245.972] (II) VESA: driver for VESA chipsets: vesa
<youpi>ok, so at least it does get loaded
<youpi>yes, you can put #error foo for instance
<youpi>just to make sure what you think is getting compiled, is actually getting compiled
<AlmuHS>oh, I didn't put any bogus
<youpi>do try
<youpi>as I said, always cross-check
<youpi>otherwise you'd assume something, and possibly it's actually not happening
<youpi>did you put a messabge in VESAPreInit ?
<AlmuHS>yes, it's true
<youpi>baiscally, I'd say add a message to each function that is referenced from the VESAInitScrn structure
<youpi>to make sure of what gets called from Xorg
<AlmuHS>I added prints in the lines hide under libpciaccess directive
<youpi>AIUI they'd get called in the Probe, PreInit, ScreenInit, SwitchMode order
<youpi>and thus you can add prints in the last one that does get called (and possibly does stuff that prevents the next from getting called)
<AlmuHS>I have prints in Probe and PreInit, but not ScreenInit
<AlmuHS>neither SwitchMode
<youpi>(don't put prints only inside the libpciaccess code, but also before, to be sure whether you're entering them at allà)
<AlmuHS>I'm editing file through ssh using nano, It's so lazy
<youpi>better use a more advanced editor, to be efficient
<AlmuHS>like what?
<swivel>unless you're unfamiliar with the more advanced editor, then it becomes far less efficient ;)
<swivel>e.g. spending 15 minutes figuring out how to quit
<youpi>well, anything you are used to :)
<AlmuHS>I usually use graphical editors
<youpi>you should learn using a text editor
<youpi>that'll save you in so many situations
<youpi>(the exact editor doesn't matter that much actually, just make sure to learn its features in order to be efficient)
<AlmuHS>i learned a bit about vi
<AlmuHS>not vim, vi
<youpi>then I'd advise learning vim for real
<youpi>it's available basically on all unices
<youpi>even the dumbest unix boxes you might have in a drawer
<swivel>even bare vi is pretty powerful and tends to be available everywhere... but once you go down the vim rabbithole things get pretty weird in a good way, just can make it awkward to interact with classic vi
<janneke>hmm, any hope my x60's e1000e network adapter works?
<AlmuHS>janneke: only with netdde
<youpi>janneke: netdde seems to have a driver for that
<AlmuHS>janneke: my t60 network adapter works (ethernet, not wifi)
<janneke>ah, i think we have netdde...
<janneke>i haven't found the kernel messages eiter
<youpi>didn't the cat work?
<AlmuHS>try to enable netdde manually following this instructions
<janneke>qemu's PAUSE feature is handy...
<janneke>ah /dev/klog -- i missed that
<janneke>AlmuHS: thanks!
<janneke>youpi: cat /dev/klog works
<AlmuHS>you can use "more" to read the log easily
<AlmuHS>or even "less" to allow up and down
<AlmuHS>less /dev/klog
<youpi>note that it's consumed
<youpi>so you'd rather cat to a file, and then read that file
<AlmuHS>cat /dev/klog > klog
<AlmuHS>less klog
<janneke>yeah, thanks!
<janneke>hmm, rekado added the netdde package, but it seems i failed to install it
<janneke>oh well, sounds like good news
*janneke -> zZzzz
<AlmuHS>explain more
<janneke>i need to run "guix reconfigure" from linux again and install the netdd package (tomorrow!)
<janneke>thanks, good night!
<AlmuHS>youpi: there are not any of my messages in the Xorg log
<AlmuHS>in /var/log/Xorg.0.log
<youpi>is the date of the file really recent?
<youpi>to make sure, put a message in VESAIdentify
<youpi>that's the one printing "driver for VESA chipstes"
<AlmuHS>00:08. Yes, It's recent
<AlmuHS>(00:11 in spain)
<swivel>FWIW at some point on debian/linux Xorg stopped logging @ /var/log/Xorg.0.log and started logging in ~/.local/share/xorg/Xorg.0.log , I believe it coincided with shifting from Xorg run as root to run as a regular user w/modesetting driver. May or may not relate to what you're doing.
<youpi>that's why I asked for checking the time of the file
<AlmuHS>the time is recent, but maybe the /var/log has only basic info
<AlmuHS>.local/share/xorg doesn't exists in my machine