[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libburn/libisofs/libisoburn - point release, t-p-u or bpo

On Saturday, June 18, 2011 10:04:33 PM Gerfried Fuchs wrote:
>    Hi!


> * George Danchev <danchev@spnet.net> [2011-06-18 14:45:43 CEST]:
> > [libburnia story]
>  I can't speak for the stable release team, but I guess they won't
> approve the changes you have outlined here. They sound pretty intrusive
> and like complete overhauls to me.
>  Speaking with my backports team hat on, if the changes that you will do
> to the package that you take from testing are kept to a minimum (you
> mentioned newer binary packages - I would take it they are also in
> testing, not only in the planned backport?) 

That is correct, jigit/(>1.18/1.19) splits two more binary packages as 
compared to jigit/1.16 currently found in squeeze. I talked to Steve (Sledge) 
who is the maintainer of jigit (hence, debian-cd@ in CC) and he said he was 
willing to backport 1.19 when it enters testing. Meanwhile I'm busy uploading 
libburn/libisofs/libisoburn 1.1.0 to sid (synched version number could be seen 
as a coincidence), resp. wait for them to enter testing and backport the whole 
thing, source and binary package set won't change across stable, testing, and 
unstable, actually I don't expect any sourceful changes except the changelog 
entries.... Whatever, no rush is intended in order to see these brought to 

> I don't see much of a
> problem to have them offered through backports.

Good. There are few dependent packages on these libraries like brasero, others 
depend on cdrskin (k3b) and suggests xorriso (grub-common, debirf) apps. I 
don't expect any breakages as both the API and ABI are tightly controlled 
upstream (which reminds me I should revive the symbols files at some point to 
track the API extention history).

>  Also, as you need them for the cdbuilder host, and I can just guess
> that DSA is administering that box too, they are fine with taking
> packages from squeeze-backports if they are told so through an RT
> ticket.

Okay, that should be easy :-)

pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: