IRC channel logs
2026-03-18.log
back to list of logs
<azert>does anyone know how to rebuild glibc the debian way? <youpi>azert: depends what you want to do with the result <youpi>if you want to install the result on your system, better start from the debian packaging and use dpkg-buildpackage <p4r4D0xum>while building util-linux on i686, does util passes year 2038 problem check or is it disabled? <azert>youpi I am trying to add an rpc to gnumach and test it, I figured out I can hack my way using mig <azert>I am going to send a patch to the mailing list <youpi>p4r4D0xum: it has to be disabled manually <p4r4D0xum>youpi: Thank you, sam_ thought it may be crossdev bug <jab>azert: what rpc are you adding ? <sneek>jab, nexussfan says: alright. <jab>sneek: later tell nexussfan I'm not sure what browser trisquel uses. I know rms told me that he only uses icecat. *shrugs shoulders* <p4r4D0xum>Gotta go to bed, but I will find that gentoo-hurd repo fragment, I promise! <diegonc>I just downloaded the image debian-hurd-amd64-20260314.img.tar.xz and fsck fails badlly on the data partition (2) <diegonc>I had extracted the archive and immediately run `losetup -P` and `fsck.ext2 -f` on loop0p2 <jab>diegonc: you might try this sh script to download and run a hurd vm image <Alicia>I'm not sure if I've tried the same version of the image, but I've only seen some minor errors with fsck on a new image, which it fixes <diegonc> sudo fsck.ext2 -fy "${disk}p5" || true <diegonc>this won't fly with the new image. it only has two partitions (swap + os) <diegonc>to be honest I didn't try to boot it. but fsck has very serious erorrs like "Free block count wrong", "Block bitmap differences" <diegonc>not only the innocuous "delete inode x has zero d tiem" <Alicia>that's why there's an if, so it doesn't try to do stuff with p5 if it doesn't exist :) <sam_>youpi: i'd be happy to support it on libc-alpha and IMO it's the right thing to do <sam_>youpi: there is precedent as well with helper stubs like pthread being merged into libc, and we could still change it later if needed <Alicia>originally because the 32bit image didn't have an extended partition, but conditionality makes it still work for newer 64bit images, so I'm in no rush to remove it (plus if you're working with an older image it might be nice not to break that) <sam_>just it took me by surprise at first until I figured out what was happening <diegonc>Aliica: oh I see, the " # 32bit doesn't use the extended partition" puzzle me <diegonc>but it should end in the else branch on amd64 too <sam_>(also, what's the tg- prefix? i figured out the others) <diegonc>a branch management for git, pretty much like quilt is for patches :) <diegonc>well, it boots. in spite of the fsck errors :/ <youpi>sam_: Is that patch still needed? <youpi>see the discussion, ideally applications using RPCs should really link against machuser/hurduser <youpi>I don't think we want to merge the library in libc <azert>I think we need a way to make sure that installing an updates gnumach or Hurd with new or slightly updated rpcs allows applications to use them without having to recompile glibc <azert>I don’t know if this libmachuser and libhurduser are there for, but I don’t see how libmachuser is updated with gnumach but it should <azert>I think that the way things stand, we are putting a barrier to development <azert>also considering that Debian is not an homebrew distro <azert>it’s a fragile piece of porcelain <azeem>question is, who is "we" in this case. I think youpi is taking care that this is not a problem on Debian as the packages are being built/uploaded in a coordinated fashion <azeem>if you just develop yourself, I think the expectation is that you also just build all of it yourself, and I don't think you will get around building glibc for long <azert>azeem: what I’m really arguing, is that making a new rpc should be as easy as making a new syscall. And the only barrier I see to that is the tools <azert>If it involves just updating a small library, that’s better then the full glibc <azert>of course I’ll end up adding a function to also glibc, for posix compatibility. But not just to add an rpc <azeem>that's my understanding of how it works as well <damo22>is there a way to move lib*user out of there? <gnu_srs1>youpi: Se above. i also dont like changing glibc ; just to add a rpc; is there a way to move lib*user out of there? <gnu_srs1>(10:03:55) azert: azeem: what I’m really arguing, is that making a new rpc should be as easy as making a new syscall. And the only barrier I see to that is the tools <sneek>Welcome back diegonc, you have 1 message! <sam_>youpi: I can live with that, but right now, both guix+debian are patching it, and if I decide not to for our end, then all the bugs are only going to be reproducible on gentoo <sam_>youpi: and even Hurd itself I think needed patching for some utilities directory <sam_>I've added the patch on our side now but I feel like we're going to end up using it forever, and also any new ports will end up using it, and then at some point it makes sense to just do it in glibc <youpi>or rather just fix things up <youpi>that's the whole point of the comment inside the patch <sam_>sure, but my point is nobody else is doing that, because debian+guix have the patch applied <youpi>and also the only sane way to get to libmachuser/libhurduser not being built along glibc, as requested above <sam_>and the fact that the Hurd itself doesn't build without it shows that this is easy to regress on <youpi>and as long as nobody works on the issue, the issue remains <sam_>ok, I'll see about fixing things then <youpi>thanks for your future fixing! <youpi>(putting libmachuser/libhurduser inside mach & hurd will probably make the bootstrapping a bit more complex, though) <sam_>for us it's convenient to add a suppression env var in the hurd build environment overall, rather than for each affected package <sam_>zack has a patch so hopefully will be in next autoconf release (soon) <sneek>Welcome back nexussfan, you have 1 message! <sneek>nexussfan, jab says: I'm not sure what browser trisquel uses. I know rms told me that he only uses icecat. *shrugs shoulders* <nexussfan>yeah i would assume any bootloader compatible with multiboot can run hurd