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, Carlos > > > Meow!
