[Debian-ports-devel] debian-ports archive moving

[Helge Deller]

Hi Michael,

On 31.05.2016 10:40, Michael Cree wrote:
> On Mon, May 30, 2016 at 10:41:58PM +0200, John Paul Adrian Glaubitz wrote:
>> On 05/30/2016 10:17 PM, John David Anglin wrote:
>>> I'm not sure.  My time is limited and I don't think I have time to research haskell binNMUs on
>>> other architectures
>>
>> That's why my suggestion was to use the script that Michael has written. If we can make the
>> binNMUs a tad bit less manual, we had one problem less to care about. 
> 
> The script halves the manual work but does not completely remove it.
> 
> The procedure I use is:
> 
> Run ben to get a transition tracker for haskell which shows which
> haskell source packages have uninstallable built binary packages.
> Click through the transition tracker web page of the uninstallable
> packages to check that they are in the "Built" state of the
> wanna-build database.  If they are in built add them to the args
> of my script and then run my script.  It dumps nmu commands if it
> can find that the binary package is uninstallable due to a missing
> package.
> 
> One needs to give the nmu command output a quick eye-over as it can
> output an unnecessary nmu if the package is uninstallable due to
> something other than the haskell world.  It also occasionly can
> miss generating an nmu because it guesses the binary package name
> from the source package name but gets it wrong for a few haskell
> source packages that don't fit the usual naming scheme.  But it is
> right over 95% of the time.
> 
>>> On hppa, I tend to trigger rebuilds without doing any research as to why
>>> any given haskell package is missing.
>>
>> This is bad, really. Please don't do that.
>>
>>> Some people don't like the lack of info in the rebuild comment.
>>
>> And for a very good reason. The comments are necessary to understand what exactly
>> happened. I mean, how exactly do you decide whether you trigger a binNMU if
>> you actually haven't researched why the binNMU is necessary?
> 
> Indeed,if we are going to schedule binNMU's for each others ports then
> a message is essential to know why others scheduled the binNMU.
> 
>>> I also worry that the timing of binNMUs will vary from one arch to another.
> 
> Particularly on ports where arches have substantially different
> amounts of the repository built.
> 
>>> I'm sure the script will be very helpful.  Could it run as a cron job and email results?  That
>>> would save considerable time.
> 
> The manual work to run the ben tracker first and check wanna-build
> would probably defeat a cron job at present.
> 
> It would be nice, though, to have a fully automated method that could
> run the whole process as nomeata's haskell script for the official
> debian arches does.
> 
> I have included hppa in my analysis and attach a list of binNMUs
> for hppa to start getting haskell packages installable.  Maybe
> someone would like to schedule those.

I just triggered those.
 
> I also added hppa to my ben tracker and I see that hppa has quite a
> few packages that need rebuilding against libpng1.6 [1]. 

Thanks! I'll work through this list.

> I see a
> directory type chroot used in the build logs and presumably an old
> version of libpng has been left hanging in the chroots from an earlier
> build and this has defeated the already scheduled binNMUs against
> libpng1.6.  I now use tar based chroots on the alpha buildds to avoid
> this very problem.
> [1] http://www2.phys.waikato.ac.nz/cree/transitions/libpng.html

Thanks for the hint!
I tried btrfs before, but that gave problems as well.
Now I'm at directory chroots, which work quite well as long as one
monitors them closely. I will look into the tar-based ones soon though. 
 
Helge