On Sun, Aug 29, 2010 at 02:19:24PM +1000, Anibal Monsalve Salazar wrote:
>On Mon, Aug 16, 2010 at 11:25:59AM +1000, Nathan Scott wrote:
>>----- "Christoph Hellwig" <hch@xxxxxxxxxxxxx> wrote:
>>>Hi Nathan, hi Anibal,
>>>if seen the constant flipping between native and non-native uploads
>>>for the xfsprogs Debian packages between the two of you and it's
>>>slightly annoying. I know Nathan likes maintaining the Debian
>>>packages in git, which also makes life for us XFS developers trying to
>>>build debian packages a lot easier.
>Sorry about the unintended nuisance. When I had access to the SGI ptools
>repo it was very easy to keep my uploads to Debian with an updated
>>>What about a compromise? We'll add a debian-<dist> branches to the
>>>xfsprogs-dev repository where we can track the exact packages uploaded
>>>to Debian, including the -2/-3 etc packages revisions that only get
>>>uploaded to Debian,
>>IMO, the -2 and -3 revisions are unnecessary and there's really no need
>>for a separate branch ... if Anibal had a kernel.org account and merged
>>changes in before uploading, there'd be no issue, I think - Anibal? It
>>would make life simpler, for sure.
Hi Christoph and Nathan, :)
Any news about access to kernel.org to merge changes before uploading?
Having the xfsprogs Debian package as native is okay for me if that is
what you guys want. Some Debian maintainers think it isn't a good idea,
>On the same subject, I talked to Andreas during LinuxCon2010 in Boston
>about getting access to the acl and attr git repos to update the debian
>directory before uploading packages to Debian. He was very positive
>>>And one last request, any chance to get xfsprogs for -testing rebuilt
>>>against libblkid now that util-linux-2.17 has finally made it into
>>>testing? Beeing able to use blkid for alignment detection will be
>>>very important so that XFS on Debian can deal with 4k sector disks and
>>>hardware RAID arrays out of the box.
>>Sure, I'll take a look at that for next upload.