On Saturday, June 18, 2011 10:04:33 PM Gerfried Fuchs wrote: > Hi! Hi, > * George Danchev <firstname.lastname@example.org> [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 squeeze. > 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>
Description: This is a digitally signed message part.