Hi! On Thu, 2015-05-28 at 15:23:21 +0200, Andreas Henriksson wrote: > 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.
Doing that for a project that takes portability as a second thought gets tiresome pretty quick. Sure, the current upstream is receptive to portability patches, which in current times seems it is already something one should be thankful for, but having to play catchup and detangle system assumptions after the fact can take some effort. Of course, that the project is named util-*linux* does not help either. I've also got my hands pretty full, so while I can take a look from time to time, I cannot and wont guarantee any timeliness. > 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 don't think this is reasonable. Having to do this with any package that might have portability issues would imply having to replicate the Debian infrastructure, or would require forward porting the packaging to the new upstream. Uploading rc versions to experimental, and going from there after notifying porters if there are FTBFS is something else entirely, though. > I'm not interested in maintaining kfreebsd patches That's obviously your prerogative, but for an Essential:yes package I find it a bit questionable. > and given past experience that noone else (including you IIRC?) is > ever willing to take on forwarding their existing patches upstream. I just checked, and I can only find one instance where I filed a Debian specific bug report and you asked for unrelated assistance with fsck, where it seems I missed replying to that. It was also a while after I had left the GNU/kFreeBSD team, so the timing might have not helped either. And in any case I've forwarded my share of patches to util-linux upstream over the years, quite unsuccessful with previous upstream, much better with the current one. > 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. While this is also your prerogative, I've always considered my reponsibility as the maintainer to interface with upstream, knowing any idiosincracies or requirements they might have, like subscribing to post-only mailing lists or registering to bug tracking systems if need be. Requiring this on a single package might look fine, but when one applies that to hundreds of packages then it stops scaling. Also, I think that trying to carry no patches in Debian as a personal policy to hold onself to sounds great, but I also think there's always room for exceptions. Personally I'm on the opposite spectrum, and I have no remorse on diverging from upstream whenever it is needed, for whatever reason. > 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.) We are pretty early in the release cycle, I don't see why there would be any urgency in a migration to testing TBH? And well, the current mess was caused by the move of the sysvinit tools, if not for that the FTBFS would not have gotten the buildd queues stuck. So personally I see it as a matter of responsibility. In any case the packages are not going to migrate anyway, at least as reported by the excuses output. But if they migrated today and a subsequent upload was performed after that, this would be pretty satisfactory IMO. > 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. The build failure is real. :) The sysfs code, which is the one that contains that specific code path, is in theory also usable on kFreeBSD systems as they have a sysfs implementation (linsysfs), but I'm not sure to what extent, probably not in this case. Fixing the code to not use sysfs would be quite some work, and it is something the Hurd is also affected by, as it does not even have any kind of sysfs support. So after consideration the fix seems entirely correct to me, and I can send the patch and another one to handle the run-time case upstream if that might smooth things up. OTOH I don't have any idea when a glibc upload might happen, and why it might be stalled. You'd have to ask the glibc maintainers. glibc uploads tend to be sparse. > 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.) In this specific case that applies as well to GNU/Linux with older kernels. And as mentioned above, I've now prepared a patch that takes care of the run-time error. > 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. This is the usual approach with portability, when it comes to using “new” features that might be supported by the host kernel, but not by the build system. > (Sorry for maybe sounding harsh, Same here. :) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
