IRC channel logs


back to list of logs

<damo22>hmm "git add ." did not add all files
<damo22>so strange
<damo22>$ git add -A
<damo22>$ git status
<damo22>HEAD detached at upstream/0_git904baec6
<damo22>nothing to commit, working tree clean
<damo22>but when i switch branches i have dirty tree
<damo22>its like when i switch branches it doesnt clean up some of the files that are not in the second branch
<damo22>/hurd/ext2fs: ../../libdiskfs/disk-pager.c:99: fault_handler: Unexpected error:
<damo22>Disk quota exceeded.
<youpi>damo22: 0_ is simply the 0~ in the debian version with ~ turned into _ because git interprets ~
<damo22>youpi: im building an up-to-date rumpkernel package now
<damo22>if it compiles and completes i will push to git.zammit
<damo22>i still need to test it on rumpdisk
<damo22>gah its trying to use sysroot from netbsd
<damo22>so the nbmake-i386 script fails
<damo22>it fails on the last step trying to build the pci-userspace lib
<damo22>/part3/demo/git/rumpkernel-0~20191130/pci-userspace/src-gnu/pci_user-gnu.c:135:13: error: 'device_open' reading 128 bytes from a region of size 4 [-Werror=stringop-overread]
<damo22> 135 | if (device_open (master_device, D_READ, "irq", &irq_dev))
<damo22>is that a false positive?
<damo22># build libpci/librumpdev_pci_pic.a:
<damo22>...nbmake[4]: don't know how to make /part3/demo/git/rumpkernel-0~20191130/ Stop
<youpi>damo22: it's a false positive in that dev_name_t is indeed a char[128], but it's 0-terminated
<youpi>possibly there's a gcc attribute to tell that to the compiler
<pussies_slayer_9>Hi, do you think that it would be possible to implement the DRM/KMS linux api in a hurd translator?
<pussies_slayer_9>I guess the difficult part would be that a part from the fact that the api is huge, kernel side drivers might not need to be ported
<wleslie>one delightful thing I've recently discovered is that DRM is mostly MIT or HPND, meaning it is gplv3 compatible
<damo22>youpi: i pushed rumpkernel to but it doesnt quite build at the last step
<damo22>i cant figure out why it is looking for crti.o
<wleslie>also dri3 appears to be mostly a capability system
<damo22>wleslie: i think there is a kernel component to talk to the hardwarwe
<wleslie>yeah, it's the kernel side I was looking at
<damo22>oh nice
<wleslie>thinking it'd be gplv2-only. there are a few files that are, but maybe I can get away with not using those. the bigger effort is that it uses a lot of other linux interfaces that need to be replaced (virtual inodes, slab allocation etc). it's work, but it's not onerous.
<damo22>wleslie: perhaps look at netbsd's drm
<wleslie>and yeah, looking for crti.o is a bit weird. I wonder which crti.o it needs - maybe it's looking in a netbsd-build specific location.
<wleslie>oh I did. the issue with taking it from netbsd is there's quite a bit of four-clause code there.
<damo22>yeah i think the build system uses --sysroot= and then looks for crti.o in a netbsd tree
<wleslie>erm, but I should confirm that actually impacted DRM. it impacted a lot of pci stuff, and even some virtio
<damo22>but i cant even see the line that calls gcc
<wleslie>is this the final link?
<damo22>it seems to call "ar crsD" and then fails
<damo22>but it made the .a
<damo22>so there must be another line that its failing on silently after htat
<damo22>good q
<damo22>i didnt provide any parallelism to the debian package build
<damo22>not sure if it uses any by default
<damo22>dependall ===> /part3/demo/git/rumpkernel-0~20191130/
<damo22>nbmake[4]: don't know how to make /part3/demo/git/rumpkernel-0~20191130/ Stop
<damo22>the call was cd pci-userspace/src-gnu && /part3/demo/git/rumpkernel-0~20191130/ dependall
<damo22>gtg to work
<wleslie>catch you later damo
<damo22> its here if anyone wants to try fixing it
<damo22>i just kicked off a clean build and force pushed the last commit
<damo22>and it failed at the same spot