[Pkg-electronics-devel] RFS: fritzing

[Scott Howard]

Thanks for packaging fritzing, btw - it's a good tool to have in Debian.

2010/10/31 Enrique Hernández Bello <ehbello at gmail.com>:
> 2010/10/26 Scott Howard <showard314 at gmail.com>
>> 2010/10/24 Enrique Hernández Bello <ehbello at gmail.com>:
>> 1) instead of CDBS and explicitly using quilt, would you consider
>> using source format 3.0 (quilt) and debhelper 7 [2]. It should make
>> your debian/rules simpler. It  appears that you are using source 3.0
>> (quilt), but you still have a debian/README.source and explicitly call
>> quilt in your debian/rules. Both of those are probably unnecessary.
>>
> CDBS is comfortable. Do you think that my debian/rules will be more simple
> without it?

CDBS is fine, it's just easier (for me) to figure out what is going
wrong with builds using debhelper (since you were having a problem
with dh_fixperms).
You have the build working, so no need to mess with it. I would look
into getting rid of the explicit quilt dependency since you are
already using source 3.0 (quilt) format to clean up the rules (and
eliminate one of the cdbs mk files, I believe)

> CDBS helper calls to debhelper orders. I don't know why dh_fixperms does not
> work.

I not comfortable with CDBS, but I'm curious why it's happening. Does
anyone else know?

>
>>
>> 3) Consider reformatting your debian/copyright to DEP-5 [3] (this is
>> nit-picking, but good form for a new package).
>>
>> 4) Consider formatting your patch descriptions to DEP-3 [4] (this too
>> is nit-picking, but good form for a new package).
>>
>
> DEP documents mentioned above are really nit-picking. Are they really
> useful?

My sponsors have made me use them in each of my uploads (even when
adopting someone elses package I had to retroactively label each
patch). They are just drafts as of now - but if it isn't much more
work, why not do it? There is no drawback (except your time) and the
benefit is machine parsing of your patches and copyright information
by the debian QA team.

> If I don't increment the release number, I can't upload it to mentors
> repository. What do you suggest? What is the common way to version a
> "pre"-release package? Perhaps adding a suffix like "~mentors1"?
>

Mentors is unique in that they allow repeated uploads of the same
version number for exactly this reason (that we are working on
packages for the same debian release version).

Regards,
Scott