IRC channel logs
2021-11-07.log
back to list of logs
<damo22>hmm "git add ." did not add all files <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: <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>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># build libpci/librumpdev_pci_pic.a: <damo22>...nbmake[4]: don't know how to make /part3/demo/git/rumpkernel-0~20191130/buildrump.sh/src/obj/destdir.i386/usr/lib/crti.o. 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 git.zammit.org 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 <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 <damo22>it seems to call "ar crsD" and then fails <damo22>so there must be another line that its failing on silently after htat <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/buildrump.sh/src/sys/rump/dev/lib/libpci <damo22>nbmake[4]: don't know how to make /part3/demo/git/rumpkernel-0~20191130/buildrump.sh/src/obj/destdir.i386/usr/lib/crti.o. Stop <damo22>the call was cd pci-userspace/src-gnu && /part3/demo/git/rumpkernel-0~20191130/buildrump.sh/src/obj/tooldir/bin/nbmake-i386 dependall <damo22>i just kicked off a clean build and force pushed the last commit