[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions before my first upload attempt



On 2015-08-21 13:21, Danny Edel wrote:
> On 20/08/15 18:33, Thomas Schmitt wrote:
>>   Else: Is there a shortcut description how to quickly set up
>>   Debian package development in a virtual machine and how
>>   to keep it up to date ?
>>   (Hardware is plenty but my own VM scripts date back to Debian 6.)
> 
> Hi Thomas,
> 
> Debian actually has ready-made VM scripts for you.
> 
> You want to take a look at the "sbuild" system, it can create a minimal
> sid tarball chroot-"virtualmachine" and use it to build packages for
> you. Using sbuild will be as close as it gets to the official buildd
> machines, helping you to prevent FTBFS¹. sbuild machines install a bare
> minimum of packages plus your specified build-dependencies into a
> throwaway directory, build the package and delete everything except the
> build log and created .deb, returning to a clean state.
> 
> Pointer: https://wiki.debian.org/sbuild
> 
> Once sbuild is setup, you can call either "sbuild --dist sid" from
> inside the source directory (quick result, but I wouldn't recommend it)
> or call "debuild -S" on your host machine first:
> This will create a .debian.tar.xz and a (signed) .dsc file in "..", then
> you can call "sbuild --dist sid your-package_version.dsc". If that goes
> through, you know your dsc is good and you can upload it to mentors with
> "dupload --to mentors my.changes". (That's why I recommend this two-step
> route, since than you have "this" dsc that built correctly. Btw, the
> dupload step will check if you signed correctly)
> 
> For bonus points, if you are on a machine that can chroot different
> arches (for example amd64 hosts can create a i386 chroot) you can verify
> it compiles on both.
> Just call another sbuild-createchroot with --arch i386 and then call
> "sbuild --dist sid --arch i386 my.dsc" to build on it.

I agree that sbuild is ultimately the best way to go. I myself use it,
and keep chroots of various distributions on it.

The reason I posted the qemu-based approach was that it was, at first
sight, not as complex as the sbuild approach, seeing as it only required
one command.


Reply to: