IRC channel logs


back to list of logs

<gnu_srs1>youpi: James Clarke (jrtc27) did add his support to GR: Proposal D, probably on behalf of kFreeBSD. Why don't you on behalf of Hurd?
<gnu_srs1>If you can add yourself to you can make your voice heard to Debian too!
<damo22>gnu_srs1: what is GR?
***Server sets mode: +nt
<damo22>how do i set the default translators on a disk image?
<damo22>eg /dev/console is not set
<damo22>does rsync under hurd set translator bits?
<damo22>ok its easier if i shrink my / and dump the disk
<damo22>i get the same error on qemu with trying to mount a rumpdisk partition beyond 128GB boundary
<damo22>i think its because libstore uses size_t
<damo22>so thats 2^32
<damo22>store_set_size (struct store *store, size_t newsize)
<damo22>what happens if your store is > 4G
<damo22>the problem is in libparted
<damo22>size_t start;
<damo22>start = device_start * PED_SECTOR_SIZE_DEFAULT;
<damo22>that will overflow "start"
<damo22>problem is recnum_t is 32 bits
<damo22>gnumach only supports devices up to 2^32 blocks
<gnu_srs1>damo22: GR is (Debian) General Resolution, and the subject for discussion now is: Init systems and systemd
<gnu_srs1>youpi: When cross-building glibc-2.30 I get a libhurduser.a (no libhurduser_pic.a) containing io_set_some_opemodes but not in
<gnu_srs1>What am I missing?
<gnu_srs1>Libraries are built with -no-pie -fno-PIE, should I use -pie. Configure reports: checking whether -fPIC is default... no checking whether -fPIE is default... no
<gnu_srs1>When building Debian glibc both are set to yes.
<youpi>damo22: size_t is 64bit inside hurd (because it's built with LFS enabled, see in man feature_est_macros the LARGEFILE macros
<youpi>libparted however possibly isn't built with LFS support, that should be fixed if not
<youpi>damo22: the device_t interface is limited to 32bit integer indeed, we need to increase that
<youpi>gnu_srs1: (io_set_some_openmodes): I don't know
<youpi>gnu_srs1: building libraries with -fPIE is not needed as long as -fPIC is used
<damo22>something happened to my system and my original pci-arbiter cleanup patch is now broken on my system, should i upgrade my packages?
<youpi>the fact that -fPIE is enabled by default in debian doesn't matter
<youpi>damo22: possibly
<youpi>gnu_srs1: like I said, I don't have time to delve into it
<youpi>why should I second proposal D rather than proposal E for instance?
<damo22>youpi: what packages do i need to upgrade to get the latest changes you made for the arbiter?
<damo22>just "hurd"?
<youpi>honestly I don't remember off-hand
<youpi>probably hurd, hurd-libs0.3, libpciaccess
<damo22>ah yes
<youpi>gnu_srs1: does your libhurduser_pci.a contains e.g. __io_read ?
<youpi>damo22: normally nowadays translator bits are stored in xattr. It seems rsync's -X option can preserve them
<damo22>rsync on hurd does not support X
<damo22>at least the version i have
<youpi>you don't have version 3.1.3-7 ?
<youpi>oh it seems the support is disabled there
<youpi>probably something to fix in it
<damo22>how do i enable LFS in libparted? would it be a simple flag
<youpi>it would, but also possibly ABI concerns
<damo22>i tried setting size_t to store_offset_t in libparted
<damo22>for the gnu_read
<damo22>it didnt seem to make any difference
<damo22>i still get ext2fs panic get_hypermetadata
<youpi>did you try the dd test first?
<youpi>rather than immediately getting all the complexity of ext2fs + parted
<youpi>better debug layers one by one
<damo22>so, i need to dd , and skip 512*2^23 ?
<damo22>around that boundary?
<youpi>try to see how far you can go, yes
<youpi>and making sure that it's behaving correctly
<damo22>i can fdisk /dev/wd0
<youpi>so there is getxattr etc. support in glibc on GNU/Hurd, it just seems that rsync was not taught to use it
<youpi>that'd be useful to do
<youpi>fdisk with logical partitions?
<youpi>primary partitions only touch the MBR
<damo22>yeah im only in primary partitions
<youpi>then that's not a good test :)
<damo22>but its on a real disk
<damo22>at least
<damo22>in qemu
<damo22>i sorted out my issues
<youpi>ok, but I mean fdisk is not actually accessing sectors beyond limitations
<damo22>sure now i will use dd
<damo22>hmm interesting /dev/wd0 says its 2GB size in fdisk
<damo22>but its a 320GB hdd
<damo22>Disk /dev/wd0: 2 GiB, 2147483648 bytes, 4194304 sectors
<youpi>normally stat does support 64bit size
<youpi>but possibly that's not properly reported by libstore
<damo22>root@zamhurd:~# dd if=/dev/wd0 of=/dev/null skip=4194303 count=2 bs=512
<damo22>dd: error reading '/dev/wd0': Input/output error
<damo22>1+0 records in
<damo22>1+0 records out
<damo22>i hit the end of the 2GB
<youpi>you can use bs=1048576 to make computations easier :)
<youpi>so there's the dd case to be fixed first
<youpi>no need to delve into libparted/ext2fs before that works
<damo22>err = rump_sys_lseek(bd->rump_fd, (off_t)bn * bd->block_size, SEEK_SET); is returning -1
<damo22>but bd->media_size = 320GB
<damo22>hmm maybe rump_sys_lseek returns off_t
<damo22>it does !
<damo22>Disk /dev/wd0: 298.9 GiB, 320072933376 bytes, 625142448 sectors
<damo22>it mounts past 128GB
<damo22>i read 100MB starting from 200GB
<damo22>aaand 100MB starting from 300GB
<damo22>i think its working
<gnu_srs1>youpi: I've now built glibc-2.30 with checking whether -fPIC is default... yes; checking whether -fPIE is default... yes and libhurduser_pic.a is created, e.g. containing __io_read
<youpi>damo22: yay !
<youpi>damo22: was rump built with the LFS flags?
<youpi>gnu_srs1: was it not containing __io_read before?
<youpi>really, there is no reason why fPIC/fPIE should have anything to do with __io_read getting defined or not
<gnu_srs1>It was not built before. Problem is that the cross-compiled binaries have hardcoded: file ./x ...dynamically linked, interpreter /tools/lib/,
<gnu_srs1>so they are not executable in a native hurd environment, even downloading the cross-compiled libs and settin LD_LIBRARY_PATH.
<youpi>damo22: oh, ok, both block_size and bn were 32bit, so the computation was limited to 32bit
<youpi>gnu_srs1: /lib/ does exist on a Hurd system
<youpi>LD_LIBRARY_PATH is read by, so it can't be what tells where is
<gnu_srs1>cross-compiling -> hardcoded to /tools/lib/
<youpi>I'm surprised that the interpreter would get set to /tools
<youpi>but probably there is a configuration option to set that
<gnu_srs1>All cross compiled stuff goes into /tools as it is set up now.
<gnu_srs1>LD_LIBRARY_PATH=. ./whoami: Killed
<gnu_srs1>/tools/lib/ -> /home/srs/test/
<gnu_srs1>Do I need to set up env?
<youpi>normally, gcc uses ./src/gcc/config/i386/gnu.h:#define GNU_USER_DYNAMIC_LINKER "/lib/"
<youpi>AGAIN, like I said, it's which reads the environment
<youpi>so there is no point in looking for an environment variable
<youpi>you have to fix your toolchain into setting the proper interpreter path
<youpi>normally that's define like I wrote above
<youpi>and that's used in ./src/gcc/config/i386/gnu-user.h: { "dynamic_linker", GNU_USER_DYNAMIC_LINKER }
<youpi>then passed to the linker
<youpi>now if your setup does things differently, I don't know
<gnu_srs1>And LD_LIBRARY_PATH still reads /lib/so?
<youpi>I don't understand that sentence
<youpi>it does not make technical sense
<gnu_srs1>I want to use the downloaded libraries in ./test instead of the native ones.
<youpi>look, I don't understand what you are trying to achieve, and do not have time to try to guess
<gnu_srs1>Since I cannot test the cross-compiled files in an Linux amd64 environment, I want to try them in a native Hurd i386 environment.
<youpi>does /tools/ exist?
<youpi>does /tools/lib/ exist?
<gnu_srs1>I created it yes
<gnu_srs1>ls -l /tools/lib/ /tools/lib/ -> /home/srs/test/
<youpi>does it work when you run it by hand?
<youpi>i.e. just running /tools/lib/
<youpi>then debug that first
<youpi>because that's supposed to be able to work
<gnu_srs1>/tools/lib/ -bash: /tools/lib/ No such file or directory
<youpi>anything else will fail anyway if that does not work for a start
<youpi>file /tools/lib/
<youpi>file -L /tools/lib/
<youpi>does they report the same as for /lib/ ?
<gnu_srs1>file /tools/lib/ /tools/lib/ symbolic link to /home/srs/test/<
<gnu_srs1>file -L /tools/lib/ /tools/lib/ ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /tools/lib/, for GNU/Hurd 0.0.0, with debug_info, not stripped
<gnu_srs1>file /home/srs/test/ /home/srs/test/ symbolic link to
<youpi>it's very odd that has an interpreter info
<gnu_srs1>Natively: file /bin/ls: /bin/ls: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Hurd 0.0.0, BuildID[sha1]=a3cf1784aa57ec0cd262f6d9df9f34d5198b40c0, stripped
<youpi>yes, /bin/ls has an interpreter,
<youpi>but *is* the interpreter, so it does not make sense that it'd have an interpreter
<gnu_srs1>When cross-compiling I don't want to override the Linux amd64 /bin/ -> therefore everything goes to /tools
<youpi>sure, that's not the question
<youpi>the actual technical problem you have is that your /tools/lib/ is marked as requiring an interpreter, set to itself
<youpi>that can at best just loop around
<youpi>so something is wrong in your glibc building
<gnu_srs1>file /lib/ /lib/ symbolic link to
<gnu_srs1>file -L /lib/ /lib/ ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=730303a2e277416d23350292a4a3474fe9aec9e6, stripped
<gnu_srs1>Same as for /tools/lib/
<youpi>above you wrote that for /tools/lib/ you had "interpreter /tools/lib/"
<youpi>so it's not "Same"
<gnu_srs1>OK, now I see the difference.
<gnu_srs1>Seems like double linking was not OK: now: file /tools/lib/ /tools/lib/ symbolic link to /home/srs/test/
<gnu_srs1>file -L /tools/lib/ /tools/lib/ ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, with debug_info, not stripped
<gnu_srs1>LD_LIBRARY_PATH=. ./whoami: ./whoami: cannot find name for user ID 1000
<youpi>(14:47:09) gnu_srs1: file /home/srs/test/ /home/srs/test/ symbolic link to
<youpi>that's what was nonsense
<youpi>double-linking is not a problem, you can use many symlinks levels
<youpi>but you need to end up with, not
<gnu_srs1>./ symbolic link to /home/srs/test/
<gnu_srs1>Yes, I made a mistake in the symlink. tks, all good :)