IRC channel logs


back to list of logs

<damo22>youpi: how do i generate the ioctl request parameter for ioctl 10 on the i group?
<damo22>i keep getting ENOTTY
<damo22>innapropriate ioctl for device
<youpi>damo22: generate what exactly?
<youpi>the .defs definition?
<youpi>it's just following the structure you're giving in the _IOR/W parameter
<youpi>#define SIOCADDRT (112000 + 10)
<youpi>that's not it
<damo22>i dont have the right header or something to generate with _IOR
<youpi>really, follow _IOR/W
<damo22>something is missing from my headers
<youpi>did you define the proper _IOT ?
<youpi>really, do read _IOR, and iotcl()
<damo22>isnt it supposed to be in <bits/ioctls.h> ?
<youpi>see the comment
<youpi>it says it's #defined along the structure
<damo22>where do i put the _IOW() ? in hurd/ioctl_types.h ?
<damo22>or in pfinet/linux-src/include/linux/route.h
<youpi>there's already bits/ioctls.h
<youpi>where there's already the ADDRT ioctl (but with a definition that can't work since there's not struct rtentry defined yet)
<damo22>so i need to patch glibc?
<youpi>you can define it by hand in your test program, but eventually it's supposed to be defined there, yes
<youpi>damo22: usr/lib/i386-gnu/*.so*
<youpi>rather put a * instead of hardcoding i386-gnu
<damo22>yeah i wasnt sure how to handle that
<youpi>cd $(DESTDIR)/$(libdir) && ln -sf
<youpi>you don't need to cd there
<youpi>just ln -sf $(DESTDIR)/$(libdir)/
<youpi>also, usually PREFIX etc. already contain a heading /, so do not put a / between $(DESTDIR) and $(libdir), that's a dup
<youpi>also, could you put it on salsa, so it can be co-maintained?
<damo22>i dont have rights to upload a new package to salsa?
<youpi>salsa is not about uploading
<youpi>it's just a gitlab
<damo22>oh i can create personal project
<youpi>you have developer right there
<youpi>no, create a project in the hurd-team
<youpi>(and similarly for i386-gnu in libacpica-dev.install)
<youpi>also add PREFIX ?= /usr/local
<damo22>the pfinet patch breaks default routing :(
<damo22>i should split it into two
<damo22>i think i forgot to set the rt_genmask
<youpi>damo22: so do you have the authorization on gitlab to create the project inside hurd-team? possibly I need to make you owner to be able to do that
<damo22>will check now
<damo22>i can create it seems, do i make it public or private?
<damo22>oh yea, you made it lowercase
<youpi>U acpi_os_acquire_lock etc., I guess this will be added to acgnuex.h?
<damo22>hmm, i may have missed it
<youpi>there are also semaphore, etc.
<youpi>basically nm ./debian/tmp/usr/lib/i386-gnu/ | grep " U " | grep " acpi_os"
<youpi>grep "acpi_" event
<youpi>(there's an acpi_ds function)
<damo22>but i added the missing symbols to the acpi_init.c which are compiled from hurd side and linked to the lib
<damo22>theyre all hooks as far as i know
<youpi>you mean in the hurd translator?
<youpi>I'd say rather put it in libacpiac
<damo22>well yes, we can do that, but its more to maintain
<youpi>that library is compiled for user-level execution, better let it be complete
<youpi>more to maintain?
<youpi>it has to be maintained somewhere
<damo22>lol ok
<youpi>maintaining it in libcacpi is actually less work
<youpi>since acpica devs can then update them if e.g. prototypes change
<damo22>true, if we are the only users of the lib, we can define the hooks
<damo22>i have them all ready in another file
<youpi>I don't understand
<youpi>I mean
<youpi>acgnuex.h is for the GNU os
<youpi>to define how libacpica is supposed to be used there
<youpi>so we define there what we want
<damo22>oh ok yes
<damo22>i can put them in there
<damo22>i need to make dinner now
<gnu_srs1>youpi: Upgrading hurd and installing latest emacs gives:Cannot open load file: Too many open files, debug
<gnu_srs1>ERROR: install script from emacsen-common package failed
<youpi>yep, seen that, needs investigation
<gnu_srs1>and:apt-get install --reinstall emacsen-comon; E: Unable to locate package emacsen-comon
<youpi>already mentioned earlier on irc
<youpi>common takes to m
<gnu_srs1>Ok: Wth two m: E: Internal Error, No file name for emacsen-common:hurd-i386
<gnu_srs1>But I can download it, and dpkg -i fails too?
<youpi>damo22: please remember to push the upstream branch, and tags :)
<youpi>ah, the tag is there, but the upstream branch is not :)
<youpi>(and thus the tag doesn't work)
<damo22>what do i call the upstream branch?
<damo22> /facepalm
<biblio>youpi: damo22: doxygen -> qtbase5-dev. I did apt-get source qtbase5-dev and got this error
<youpi>so it's /usr/lib/qt5/bin/qtattributionsscanner which needs to be investigated?
<biblio>youpi: i think qtbase-opensource-src-5.15.4+dfsg/src/corelib/ one
<youpi>run it in gdb to see how it's failing
<biblio>youpi: ok
<damo22>i saw an error in your log that says __float128 not supported on the target
<damo22>but that was just from #include <stddef.h> in gcc 12?
<biblio>damo22: in blogs people suggested to specify -std cpp 11 specification. So, I did in debian rules for qt. still getting this error
<biblio>damo22: yes it is from stddef.h.
<damo22>is that a bug in gcc 12? can you try gcc 11?
<youpi>gcc does support __float128
<youpi>it's clang that doesn't
<youpi>I guess it's just a matter of enabling it in llvm
<biblio>damo22: it is generating from
<damo22>/usr/lib/gcc/i686-gnu/12/include/stddef.h:433:68: error: __float128 is not supported on this target
<damo22>does clang compile gcc headers
<youpi>clang uses gcc's libstdc++
<youpi>(at least on debian)
<biblio>damo22: youpi: /usr/lib/qt5/bin/qdoc is doing the actual compilation here
<youpi>ldd /usr/lib/qt5/bin/qdoc | grep LLVM
<youpi> => /lib/x86_64-linux-gnu/ (0x00007fd424800000)
<youpi>and it's using llvm for that
<youpi>which is very not surprising
<youpi>nobody wants to write a C parser :)
<youpi>let alone a c++ parser
<biblio>youpi: now it make sense :D
<damo22>llvm takes ages to compile, even on linux
<biblio>damo22: older llvm doenost support __float128 they added a patch later.
<damo22>14 isnt that old
<gnu_srs1>youpi: is it safe to upgrade more images to latest glibc? I was about to look into the pthread problem with gcc-12.
<biblio>damo22: right. I will check if we can add some parameter to qdoc to make it work.
<youpi>gnu_srs1: see my mail for the version that is safe
<damo22>demo@zamhurd:/part3/test-pfinet$ clang test2.c -c
<damo22>test2.c:3:1: error: __float128 is not supported on this target
<youpi>"older llvm doenost support __float128 they added a patch later", yes, and on linux it does work
<youpi>really, it's most probably just about enabling it for the hurd target
<damo22>so we support simd intrinsics?
<youpi>why wouldn't we?
<youpi>it's completely os-independent
<biblio>youpi: damo22:
<damo22>i thought i386 port was restricted
<damo22>to instructions that can run on old hw
<youpi>it can use cpuid to detect new instructions
<youpi>(and simulate if instructions are not available)
<youpi>see clang/lib/Basic/Targets/OSTargets.h where HasFloat128 seems to be defined per OS
<youpi>(which to my mind doesn't make sense but welll.)
<gnu_srs1>youpi: The image having problems already have glibc 2.34-7~0 installed!
<youpi>which problem ? emacs?
<youpi>aiui it's the new emacs 28 that has troubles
<gnu_srs1>dpkg -i and apt-get install fails, see above.
<youpi>see above
<damo22>i was reading the IOT stuff, it looks like i can have maximum 3 simple types that are different in a row with any number of repeated elements?
<damo22>eg, char x3, int x4, long x3
<damo22>is there a max count?
<youpi>not "any" number
<youpi>see the count macros
<gnu_srs1>(12:40:29) youpi: aiui it's the new emacs 28 that has troubles: Thanks, downgraded to 27.1+1-3.1
<damo22>max 31 on first 2 and max 3 on last one
<youpi>biblio: just to make sure: do you build with -B?
<youpi>there's no use in fixing builds without -B
<youpi>e.g. building the documentation or such
<youpi>of course it's usually better to fix bugs :) but fixing builds without -B is not a priority
<biblio>youpi: let me check.
<biblio>youpi: I used dpkg-buildpackage -us -uc
<biblio>youpi: what will be the next steps to fix doxygen -> qtbase5-dev ? 1. wait for clang fix for hurd 2. patch stddef.h for not using __float128 for now
<biblio>youpi: I can also try with gcc-9
<biblio>QT configure has only options "-c++std <edition> .... Select C++ standard <edition> [c++2a/c++17/c++14/c++11]"
<youpi>biblio: first try with -B
<youpi>but also better actually *fix
<youpi>not work around by #ifdefing in stddef.h
<youpi>which will just stab us in the face another way
<youpi>also, "wait for fix"
<youpi>is usually not a way to see things progress
<youpi>bugs don't usually magically solve themselves
<youpi>also I'm unsure why you are trying to build qtbase5-dev, when it's already in the archive
<youpi>concerning doxygen, there is
<youpi>(which is already available in version 1.9.4-2+hurd.1)
<youpi>(as a reminder:
<biblio>youpi: I am trying with -B. I was trying to build doxygen. But it depends on qtbase5-dev package which was missing. apt-get source downloaded qtbase-opensource-src-5.15.4 package to build it.
<biblio>youpi: i think, i checked before qtbase5-dev was available.
<youpi>€ apt-cache policy qtbase5-dev
<youpi> 500 sid/main hurd-i386 Packages
<youpi>and shows it's installed
<biblio>youpi: now it is available :D
<youpi>that version has been available for 15days already
<biblio>youpi: i showed not available with the latest img. I checked 3 days ago. Ok i will check other packages from
<youpi>had you run apt update firsT?
<biblio>youpi: yes I apt-get update after starting new img
<biblio>youpi: but now it is showing available now.
<biblio>youpi: I wonder how it was able to build with __float128 issue ?
<youpi>as I already mentioned several times, -B
<biblio>youpi: oh sorry my -B is still running
<biblio>youpi: got it now.
<biblio>youpi: it worked with -B. thanks.
<Pellescours>When I use hurd on sata, grub failed to be configured, wasn’t any patch that should have fix that?
<jab>Pellescours: you are pretty brave. I haven't actually tried installing Hurd on real hardware
<Pellescours>jab: It’s not on real hardware, it’s just I configured qemu to provide my disk with sata
<jab>Pellescours: ah. gotcha