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

Re: bootstrap-vz debian package and some other stuff



Marcin,

> All stuff required to build should be included within tarball. If something is
> missing I think you can fix it as you've got RW access to upstream, don't you?

Yes I do, but I'm not sure if that's the case. The mentioned problem lies
here[1], where a `git` subprocess is called to return the last tag or commit,
which will be used later to build links compatible with both GitHub and Read The
Docs.

>From what I've understood about the package repository structure, even if we
move the entire `.git/` folder to the chroot, so it can have access to its
history, the commits in there will be different. This is caused by the way
`git-buildpackage` imports the upstream tree on another branch.

> Yeee, this is for libs we're packaging app, beside maybe it's worth to work on
> latest upstream?

This wasn't mentioned, but I've also checked the Python/AppStyleGuide[2]. It was
in there that I've found the information about `dh_auto_clean` override. I'm not
following *every* tip in there, but mostly the ones that apply to python
packages in general.

And yes, the intention is to work with the latest upstream. What happens is that
I had to build the package in the current repository state to understand how it
is being done.

> From mine POV we can work together ;-)

Nice! Can we discuss those details about packaging off-list? I guess not
everyone here is interested in knowing every tiny bit of it. :-)

> What I'd suggest is that you add your self into uploaders filed, so you won't
> have to create NMUs.

Done. I've also pushed the changes to Alioth's repository.

> If you're interested how branches and patches workflow looks like just read
> README.source and let me know if this stuff is ok with you. If you'll have any
> problems or questions just ping me.

I haven't used any *-buildpackage before, but the workflow described in the
README.source looks pretty straightforward to me. I'll reach you if I got stuck
with it.

Thank you,
Tiago.

[1]: https://github.com/andsens/bootstrap-vz/blob/f3be3e4/docs/conf.py#L310
[2]: https://wiki.debian.org/Python/AppStyleGuide

On 13 May 2015 at 12:06, Marcin Kulisz <debian@kulisz.net> wrote:
> On 2015-05-13 00:32:01, Tiago Ilieve wrote:
>
> snip
>
> Hi Tiago,
>
>> By now I couldn't build the Sphinx documentation on a clean chroot as
>> it is using Git to find out the what is last commit and create some
>> links using this information. This fails because there isn't a full
>> Git repository in there, only the source extracted from the tarball.
>
> All stuff required to build should be included within tarball. If something is
> missing I think you can fix it as you've got RW access to upstream, don't you?
>
>> Anyway, I've already done some small fixes (following the Style Guide
>> for Packaging Python Libraries[1]) regarding the current package
>> version (0.9.0-2):
>
> Yeee, this is for libs we're packaging app, beside maybe it's worth to work on
> latest upstream?
> I think there are going to be changes required just due to migration from json
> to yaml etc.
>
>> * d/control: Update `Build-Depends`, add `dh-python` and remove the
>> redundant `python` entry
>> * d/control: Update `Depends`, remove `${shlibs:Depends}` to avoid a
>> warning during build
>> * d/rules: Override `dh_auto_clean` to remove the `*.egg-info`
>> directory, which was preventing `debuild` from running more than one
>> time
>>
>> I'm not really sure about how to upload these changes to the package's
>> Vcs-Git repository, so I've put them on GitHub[2] until I figure this
>> out. I'm also a little bit confused if this dch entry should be
>> `0.9.0-3` or `0.9.0-2.1` (Non-Maintainer Upload). I'll wait a little
>> more for a reply from Marcin to see if we can work together on this.
>
> From mine POV we can work together ;-)
> What I'd suggest is that you add your self into uploaders filed, so you won't
> have to create NMUs.
> If you're interested how branches and patches workflow looks like just read
> README.source and let me know if this stuff is ok with you. If you'll have any
> problems or questions just ping me.
> --
>
> |_|0|_|                                          |
> |_|_|0|         "Heghlu'Meh QaQ jajVam"          |
> |0|0|0|         -------- kuLa ---------          |
>
> gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
> 3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3



-- 
Tiago "Myhro" Ilieve
Blog: http://blog.myhro.info/
GitHub: https://github.com/myhro/
Montes Claros - MG, Brasil


Reply to: