IRC channel logs
2026-08-07.log
back to list of logs
<damo22>youpi: i am doing a full build of latest samba on hurd, it seems to be working <damo22>then we can promote smbfs to hurd? <damo22>or is that a big dep you want to avoid <damo22>do we have a fully fledged secondary repo for extras that isnt backed by incubator? <damo22>incubator seems to be for experimental new features, not for stable things that just havent been upstreamed <youpi>honestly I don't remember the rationales <youpi>there are probably questions of licence, copyright assignment, etc. <youpi>(not sure I have ever known the rationale actually, these were set up before I took maintenance) <damo22>but in general, if a binary for hurd requires a huge dependency, are you less willing to have it in the main hurd/ repo? <youpi>dependencies are not really a problem, now that distributions have staged builds <youpi>it may be a problem for distribution installation, though <youpi>but distributions can always stuff binaries in separate packages <youpi>if dependencies pose problems to them <damo22>okay then i will continue pushing to get smbfs upstreamed <damo22>its a useful thing to be able to mount windows shares <youpi>haven't done that for 20 years, personally ;) <damo22>some instrumentation that generates raw data only comes with windows and the only interface they give is a share <damo22>it would be cool if i could use a hurd vm to copy off the data <youpi>damo22: in debian packages we don't modifiy upstream source directly in the git, but as patches in debian/patches/, so they are properly identified to be upstreamable <youpi>and this change should really rather be pushed directly to upstream <youpi>why is it needed, actually? that changes the ABI, it's a very involved thing, and it'd be better to match what is done on linux <damo22>sneek: later tell youpi the off_t needs to be 64 bit for samba to work correctly, it was done in the 3.0.5 patch in the incubator as well <azeem>damo22: the new ci reports on commit-hurd no longer have an attachment <azeem>maybe it would also be possible to make it staged, i.e. try a baseline CI first, and if that fails, only report that (for now), otherwiese, report all? Currently it sends quite a bit of mails <damo22>the reason there are 6 mails is because there are 6 failures, it builds 24 or so combinations and the rest are passing <damo22>ideally it would combine all failures into one mail <damo22>i dont know how to do that in my ci <damo22>since they run in parallel in separate jobs <damo22>if we fixed the user32 bugs there would be zero expected failures <damo22>youpi: i dont know which is correct, but i posted a link to you via sneek earlier <damo22>i have updated smbfs for hurd to use the non-deprecated samba api <damo22>and added a new parameter for minimum protocol level <damo22>youpi: in incubator smbfs/master smb.h there is #define _FILE_OFFSET_BITS 64 <sneek>Welcome back youpi, you have 2 messages! <sneek>youpi, damo22 says: the off_t needs to be 64 bit for samba to work correctly, it was done in the 3.0.5 patch in the incubator as well <youpi>damo22: that bug report is an oldie :) <youpi>which is indeed discussion the real problem <youpi>if a library is suddenly choosing to make off_t 64b, it'll break applications that use libraries that don't <youpi>so normally a library that wants to support 64b off_t should not define _FILE_OFFSET_BITS themselves, but only obey to it <youpi>so applications that doesn't make it 64b, won't get 64b support, that's fine <youpi>now, it's not surprising that smbfs would want to support 64b, since the hurd RPCs use 64b offsets etc. <youpi>but if the libsmbclient library doesn't have support for 64b offsets, smbfs has to cope with it <youpi>and forcing libsmbclient 64b is unfortunately the not proper approach, because then it'll break applications with 32b offsets <youpi>see e.g. ./source3/lib/adouble.h:#if _FILE_OFFSET_BITS == 64 || defined(HAVE_LARGEFILE) <youpi>Mmm, but do samba headers still use off_t ? <youpi>or such, which are affected by _FILE_OFFSET_BITS <youpi>ah, yes, in smbcli_read for instance <youpi>ideally it'd compile both versions, and make the header expose either of the two depending on _FILE_OFFSET_BITS <damo22>so my merge request should be dropped <youpi>well, ideally samba would be fixed into supporting _FILE_OFFSET_BITS == 64 <youpi>and then smbfs can define it to 64 happily <youpi>otherwise, smbfs indeed has to do the conversion itself on 32b architectures <youpi>compile the interfacing with libsmbclient in a separate .c file compiled without _FILE_OFFSET_BITS , that converts into off64_t to interface with the rest of the code that is compiled with _FILE_OFFSET_BITS == 64 <youpi>or otherwise, compile the whole code without _FILE_OFFSET_BITS , but make sure to use off64_t everywhere needed for the RPCs <damo22>does that mean samba smbcli_read(... off_t) will only support 32b offsets into the filesystem? <youpi>that's an issue of samba itself <damo22>i dont have bandwidth to fix that <damo22>youpi: i cant seem to find if off_t is signed or unsigned <youpi>it has to be signed, one has to be able to call lseek(fd, -1, SEEK_CUR) <damo22>so thats why there must be a 2G limit on some files in windows :D <damo22>because one bit is consumed for the sign bit <damo22>not sure how to resolve that in smbfs because i cant easily translate the stat64 coming from netfs <youpi>glibc does such stat / stat64 conversions <jab>sneek later tell gnucode you are such a cool person broskie! <jab>sneek: later tell gnucode you rock! <vicki_sins>I really am interested in the Hurd project. I absolutely love the microkernel set up and deeply enjoy modularity when it comes to really anything. so I'm genuinely excited to see how things turn out - unfortunately rn I'm currently indisposed to testing but I look forward to testing it <vicki_sins>are there any resources to donate to specifically this project? <vicki_sins>inb4 I just read the Site - is there anyway I can act as a mirror for devs, compiling remotely, et al.