08.06.2013 15:31, Andreas Henriksson wrote: > Hello Michael! > > I'm mostly offline until next week, but have a quick moment to give > you a reply on this..... (please beware that I've only had a few > minutes to look into it all.)
And I think that "next" week is now current, too... I too was out of the city during the weekend and wasn't able to reply sooner than now. Thank you for the the comments. > It seems the initial bug report mail hasn't reached me... :/ Well, I just submitted a bugreport. Before, I also wrote to the address listed in Maintainer: field, -- I sent almost the same thing as in the bugreport, but were just asking if your guys need any help or not and what's up with that issue. After some days without reply I filed the bugreport. > On Sat, Jun 08, 2013 at 02:21:53AM +0400, Michael Tokarev wrote: >> diff -Nru iproute2-3.9.0/debian/changelog iproute2-3.9.0/debian/changelog >> --- iproute2-3.9.0/debian/changelog 2013-05-08 16:27:40.000000000 +0400 >> +++ iproute2-3.9.0/debian/changelog 2013-06-07 21:54:32.000000000 +0400 >> @@ -1,3 +1,14 @@ >> +iproute2 (3.9.0-2.1) unstable; urgency=medium >> + >> + * Non-maintainer upload. >> + * Add debian/patches/suseconds-to-long.diff to fix FTBFS on sparc >> + (Closes: #711540) > > Not a big issue, your way probably works too... but using the > upstream commit fixing this would IMHO be better. I didn't know there's an upstream commit addressing this. I don't even know where iproute2 is maintained upstream, -- probaly it'd be better if I looked. I just tried to fix the immediate issue (which is rather trivial), basically leaving the full expertise to someone who is more familiar with the package. >> + * Urgency is set to medium because due to the above bug, the package >> + is holding a long and complicated list of other packages which >> + grows and becomes more complicated. > > I fail to see this! > > Someone would have to have introduced a versioned dependency or > change from iproute to iproute2..... Who has done so? > > You mentioned ifupdown, which has the same version in unstable & testing!!! > > You also mentioned netcf, which primary reason for not migrating (yet) > is that it's too young..... secondarily that buildds on some arch > are trying to catch up.... doesn't seem at all related to iproute2. Well. This all may have something to do with my incomplete understanding of how buildd works. This is what I have in mind: https://buildd.debian.org/status/package.php?p=netcf Dependency installability problem for netcf on sparc: netcf (= 1:0.2.3-3) build-depends on one of: - ifupdown (= 0.7.43) - netscript-2.4 (= 5.2.12) The exact version is not in build-depends, it is from internals of buildd, it is the version which were available at the time of build but it weren't installable. And it _looks_ like inability to install ifupdown on SID boils down to the fact that iproute[2] just isn't available on SID for sparc, and ifupdown depends on iproute. This is the middle of the chain, but it is the most non-obvious step I think. So as far as I can see, netcf can't be _built_ on _sid_ because one of its build-deps aren't installable on _sid_ (not testing!), so there's no netcf available on sid, so any other build-dependent packges can't be built either. So we're at the situation we're at, with a long(ish) and non-obvious chain of unsatisfyable build-deps. My understanding is that a package isn't available as build-dep on sid before it is built itself on all necessary arches. Yes you're right that netcf isn't reached 10 days yet (it passes today), but even if it did, that wont be of any help because of the above. And yes, netcf is just one of several issues we have with libvirt & qemu. I'm trying to resolve them all at the same time. Maybe DELAYED/3 was a bit too soon, especially since we both had no time to look at it during the weekend. But on the other hand, the issue and the fix are so trivial it's a pity this thing is holding anything at all. If it actually does -- note I stated at the very beginning that I'm not exactly sure I understand the working of buildds right. > No time to look at more of these, but again... I fail to see > how iproute2 could be blocking anything from migrating. > > Please educate me on what I'm missing... (maybe it'll be obvious next > week when I'm not in such a hurry.) > > If you still think the NMU is needed, then don't hold back with > delayed uploads! Thank you for the trust! However, it is always nice, I think, to ask the maintainer first and to let him to have a chance to review, correct or maybe even fix the upload, or to implement maybe a better fix he was planning. And as I mentioned above, and as you already found out, I'm not exactly familiar with the package, and I didn't know there's an upstream fix for that. How about me cancelling the delayed upload instead, until there's some time to do that left? ;) > PS. you mentioned a binNMU which it's clearly not since you're modifying > the source of the package. Yes, that was a typo on my part, dunno why I used "bin" prefix ;) Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
