Re: getting packages to rebuild
Jay Berkenbilt <email@example.com> writes:
>> > Yes, it seems the most recent arm build failed, but yet the current
>> > icu28 (2.8-3) is in testing. Perhaps someone built it manually.
>> > There are no bugs posted again icu28.
>> In testing but not in unstable for arm? Or in testing without arm
> Hmm. In testing and unstable without arm support. How does this
> happen? The debian/control says Architecture: all for relevant
> packages. I don't see any mention of xerces or icu in
Architecture: all is never autobuild. The -all you upload is shared
for all archs. Not-for-us only affects Architecture: any packages.
Assuming you ment "any" you have to talk to the buildd admin for those
archs why they set the state.
>> > Hmm.... what does Not-For-Us mean? My packages all had either
>> > Architecture: any or Architecture: all, so I don't see why this would
>> > happen.
> There's a lot of information hidden beneath the surface, it seems. Is
> there a place through which I could have discovered this, other than
> asking on debian-mentors? :-)
http://buildd.net has some links but otherwise you have to ask and
maybe write up some more infos.
>> http://www.buildd.net/buildd/Packages-arch-specific is a global list
>> for such packages while buildd admins can put packages into the
>> not-for-us state for a single arch which seems to be your case.
>> You need to talk to the mips buildd admin to revert that.
> I'm not seeing xerces or icu packages in these lists. Am I missing
There is the global list and the individual archs wanna-build
states. xerces seems only to ne n-f-u in the later. They are out of
sync so to speak.
>> >> mips, mipsel, powerpc: libs/xerces24_2.4.0-2: Not-For-Us [extra:out-of-date]
>> >> Why do you support even less archs?
>> > I'd like to know that too. I don't think it's anything I did. How
>> > would I find out?
>> Ask the buildd admins since its not on the global list.
> And how would I go about asking the buildd admins? Is there a list
> for this? Are there specific people whose email addresses I should
> use? Sorry if I'm being thick-headed about this, but this seems to be
> one area where documentation is (uncharacteristically) sparse.
Only <arch>@buildd.debian.org or the respective buildd admins listed