IRC channel 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

<damo22> http://paste.debian.net/plain/1251814

<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 libacpica0.so.0 libacpica0.so

<youpi>you don't need to cd there

<youpi>just ln -sf libacpica0.so.0 $(DESTDIR)/$(libdir)/libacpica0.so

<damo22>ah

<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

<damo22>ok

<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?

<youpi>public

<damo22> https://salsa.debian.org/hurd-team/libacpica

<youpi>great

<damo22>oh yea, you made it lowercase

<damo22>thx

<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/libacpica0.so.0 | grep " U " | grep " acpi_os"

<damo22>ok

<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?

<damo22>yes

<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

<youpi>two*

<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?

<youpi>upstream

<damo22> /facepalm

<biblio>youpi: damo22: doxygen -> qtbase5-dev. I did apt-get source qtbase5-dev and got this error https://paste.debian.net/1251823/

<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/qdoc_wrapper.sh 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 qdoc_wrapper.sh

<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> libLLVM-14.so.1 => /lib/x86_64-linux-gnu/libLLVM-14.so.1 (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

<biblio>makes*

<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: https://reviews.llvm.org/D15120

<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>bugs

<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 https://github.com/doxygen/doxygen/pull/9514

<youpi>(which is already available in version 1.9.4-2+hurd.1)

<youpi>(as a reminder: https://www.debian.org/ports/hurd/hurd-devel-debian)

<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>missing??

<youpi>€ apt-cache policy qtbase5-dev

<youpi> 500 http://deb.debian.org/debian-ports sid/main hurd-i386 Packages

<youpi>and http://buildd.debian.org/qtbase-opensource-src 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 https://people.debian.org/~sthibault/graph-total-top.txt

<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

IRC channel logs

2022-08-27.log