Bug#870904: RFS: dvdisaster/0.79.5-2
On 07/08/17 10:48, Adam Borowski wrote:
> On Sun, Aug 06, 2017 at 07:40:31PM +1000, Carlos Maddela wrote:
>> * Package name : dvdisaster
>> Version : 0.79.5-2
>> More information about my changes can be seen in the 'experimental/master'
>> branch of the git repo here: https://anonscm.debian.org/git/pkg-opt-media/dvdisaster.git.
>> It attempts to fix the builds for Hurd and kFreeBSD, which I do not
>> have access to, hence the need to release to experimental first.
> It's trivial to get a working Hurd and/or kFreeBSD install: just install
> qemu or virtualbox (the former is more capable, the latter easier to use),
> then give it a debian-installer iso. Then it's nearly the same as any other
> Debian installation, just kFreeBSD has funny-named filesystems instead of
> the bunch we're used to.
>
>> Changes since the last upload:
>>
>> * Team upload.
>> * Bump Standards Version to 4.0.0.
>> * Remove unnecessary calls to dpkg-parsechangelog from debian/rules.
>> * debian/watch: Avoid repacking upstream tarballs unnecessarily.
>> * Fix more typos in error messages and docs.
>> * Fix FTBFS on Hurd and kFreeBSD.
>> * Remove incorrect use of 'Origin: vendor' from DEP-3 patch headers.
>> * Improve support for Hurd and kFreeBSD systems, although Hurd still
>> builds without SCSI.
> Good so far.
>
>> * Mark bug, which we should have done in previous release, as closed.
>> (Closes: #838294)
> For this one, please instead send a mail to 838294-done@bugs.debian.org,
> with the first line being "Version 0.79.5-1". Otherwise, you'd feed the bug
> tracker incorrect information. (Well, it doesn't matter much for an
> unimportant bug, but one of the purposes of the sponsoring process is to get
> used to how to deal with Debian's infrastructure properly.)
>
> Ie, changelog entries are supposed to close only bugs they include a fix
> for.
Thanks for pointing this out. I have uploaded another version without this.
>
>
> Not uploading yet to give you a chance to try Hurd/kFreeBSD yourself, but if
> you don't feel like doing that, just say so. While some deride such uploads
> as "throwing shit at buildds and seeing if it sticks", human time is much
> more costly than computer time, and as long as you don't test-build
> libreoffice this way, it should be ok. Of course, this only provides
> _compile_ testing, without information if the package actually works.
I am trying to set up another box with these installed on them, but I
don't have the resources right now. Running them in qemu is impossibly
slow on my current box.
Thanks for taking the time to consider my upload,
Carlos
>
>
> Meow!
Reply to: