IRC channel logs


back to list of logs

<youpi>zamfofex: perror2 looks like the error that was recently mentioned on the list, patch already commited upstream
<zamfofex>Also: Indeed, when i try to run ‘cp’ on ‘/dev/null’, I do get that error, so maybe there is actually an issue regarding it.
<zamfofex>youpi: Are you referring to this patch? <> Because it seems unrelated. The patch seems to be already applied in the version in Guix, and I’m actually getting an error in line 108 of the current sources (on ‘master’ on gnulib and Guix): <> The line being ‘ASSERT (strstr (buf, err));’
<youpi>zamfofex: no, upstream glibc
<youpi>03ad444e8e086391f53d87c3949e0d44adef4bc3 in glibc
<youpi>and reported on bug-hurd by Bruno Haible on septembre 3rd
<zamfofex>Ah, I see! I guess I’ll disable the tests for grep too.
<Zopolis4>where are the debian hurd ports managed?
<Zopolis4>it dosent look like theres anything in hurd-debian-ports
<youpi>? there's a debian/directory
<Zopolis4>that hasnt been updated in 3 years
<youpi>why should it?
<Zopolis4>because... the packages get updated?
<youpi>which packages?
<Zopolis4>i feel like im misunderstanding something here
<Zopolis4>the apt packages
<youpi>there must be a complete misunderstanding
<youpi>hurd-debian-ports is only about making hurd use the debian-ports archive
<youpi>nothing more
<youpi>(see debian/control for package description)
<youpi>if you're talking about non-hurdish packages porting to the hurd, well it's just pushed upstream
<youpi>at worse as debian patch in the respective debian package
<youpi>but normally that's really rather pushed upstream
<youpi>as it should just be
<Zopolis4>yeah i was just wondering about broken dependencies
<Zopolis4>i.e. cmake with cmake-data and fish with fish-common
<youpi>if you want to check debian-specific patches, checkout the tracker page
<youpi>theres a CVS: Git link there
<youpi>broekn dependency is a completely different story
<youpi>just look at what is available
<youpi>the arch:all package is newer
<youpi>and the arch:hurd-i386 is out of date
<youpi>that's all
<youpi>just because cmake doesn't build, there's a testsuite bug
<youpi>just waiting for somebody to have a look and fix
<youpi>fish is just the same
<youpi>(though a build failure, not testuite failure)
<Zopolis4>i was going to try to fix fish but i have no cmake for fish
<Zopolis4>and building under software emulation is sloooooooooow
<Zopolis4>ah well
<youpi>you can install the older cmake-data from
<youpi>why software emulation ?
<youpi>don't you have kvm?
<Zopolis4>running on windows
<Zopolis4>no admin
<youpi> actually
<Zopolis4>oh only one test fails
<jab>sorry for the ping, just saw that rump support was still being worked on for the Hurd. Anyone know an ETA? 6 months? 1 year? before it is merged?
<Pellescours>the rumpdisk driver for ahcisata is already upstream and can work, for the rest it depends on the people working on it. I’m not able to give you an ETA
<youpi>jab: volunteer-based usually means there is no ETA
<jab>youpi: too true.
<Zopolis4>would someone mind running this on a hurd machine?
<Zopolis4>oh right nvm
<Zopolis4>wrong os
<Zopolis4>is the most up-to-date version of the hurd glibc? it seems like it hasnt been updated in a while, latest branch is around a year old
<zamfofex>Zopolis4: I think you are looking for <>
<damo22>Zopolis4: i believe work was done and now hurd is on upstream glibc
<Zopolis4>like entirely?
<damo22>yeah theres a debian package but it just grabs the upstream source and compiles it
***FragByte_ is now known as FragByte
<Zopolis4>just to be clear-- this means that I can (in appropriate cases) use realpath instead of PATH_MAX?
<Zopolis4>also is there any easy way to grep all of the fail logs for debian packages?
<Zopolis4>like all of the failing hurd packages
<Pellescours>Zopolis4: may help you