Hello Guillem Jover! Thanks for your interest in the kfreebsd port.
I've personally had to invest alot of time into keeping util-linux usable on kfreebsd in the past, since noone else wanted to even discuss it. I'm not willing to do that anymore. (Which might already be obvious?) We need to solve the underlying problems rather then just repeatedly attack symptoms. Someone interested in kfreebsd needs to learn from the hurd porters on how to keep util-linux working on their platform. A simple testbuild of upstream rc releases to make sure trivial patches can be submitted and merged upstream before the final version is released is needed. This is not hard, someone just needs to do it. I'm not interested in maintaining kfreebsd patches and given past experience that noone else (including you IIRC?) is ever willing to take on forwarding their existing patches upstream. I'm going to tell people to post their patches upstream. Many people seem to jump to conclusions that they will have a problem when submitting hackish patches upstream, but in reality upstream is very liberal when it comes to accepting portability patches. Please keep in mind that the current package in unstable is urgent to get in and replace the current version in testing. (ie. don't delay it with a NMU now.) If you're not interested in solving the real issue and also maybe think that this is not a patch for upstream, just a temporary way to avoid building up the buildd queue, then please add your view on these bits to this bug report and also include a description what/why the glibc update is stalled and can not be hurried instead. I'd personally much rather see the util-linux package continue to FTBFS on systems where it will actually not work at runtime. (eg. when doing backports to stable.) Where we currently stand I don't see why we would want to work around this in util-linux instead of solving the issue in glibc as already proposed. Please enlighten me. (Sorry for maybe sounding harsh, but I'm very against going back to where we came from just piling stuff on until we get stuck in a dead end. I hope you can see that doing the work to get us unstuck was not a fun task. I'm not going to repeat it so would ofcourse prefer we never go anywhere near that state again. Upstream first, then I have no problem cherry-picking... If we can't manage to work like that then I'll just try to voice my "no" as much as possible in an attempt to get us back on the right track.) Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
