Re: RFC: Handling backports for d-i components

2015-11-03 Thread Cyril Brulebois
Ian Campbell (2015-11-03): > Such as adjustments to be made to build in the older suite that's never > happened to me (just lucky I expect). In that case keeping some sort of > branch around does seem useful. Exactly; from my limited bpo experience, disabling multi-arch was a usual usecase, but t

Re: RFC: Handling backports for d-i components

2015-11-03 Thread Ian Campbell
On Tue, 2015-11-03 at 09:56 +0100, Cyril Brulebois wrote: > Ian Campbell (2015-11-03): > > For flash-kernel (and other bpo things I do outside of d-i) I generally > > push the tag but not the branch. > > > > This is because each bpo upload is essentially a little stub branch > > rooted at the bas

Re: RFC: Handling backports for d-i components

2015-11-03 Thread Cyril Brulebois
Ian Campbell (2015-11-03): > For flash-kernel (and other bpo things I do outside of d-i) I generally > push the tag but not the branch. > > This is because each bpo upload is essentially a little stub branch > rooted at the base release and they do not (at least how I do things) > form a coherent

Re: RFC: Handling backports for d-i components

2015-11-03 Thread Ian Campbell
On Tue, 2015-11-03 at 00:46 +0100, Cyril Brulebois wrote: > Hi folks, > > You're receiving this mail because you're on debian-boot@ or you've got > something ACCEPTED into a backports suite; relevant packages seem to be > the following ones: debootstrap, di-netboot-assistant, and flash-kernel. >

RFC: Handling backports for d-i components

2015-11-02 Thread Cyril Brulebois
Hi folks, You're receiving this mail because you're on debian-boot@ or you've got something ACCEPTED into a backports suite; relevant packages seem to be the following ones: debootstrap, di-netboot-assistant, and flash-kernel. I think it's fair to say that an upload after dch --bpo is easily done