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-d...@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,


> Meow!

Reply via email to