Hi Aitor et al,

netman/changelog contains this information:

netman (0.1.1~468c97d-jessie2) unstable; urgency=medium

* New release. Closes: #468c97d
* Changed debian/netman-backend.postinst
* Changed debian/rules.

-- Aitor Cuadrado Zubizarreta <aitor_czr@???> Wed, 11 Nov
2015 11:21:20 +0100

netman (0.1.0-c296e06-jessie1) unstable; urgency=medium

* Initial release. Closes: #c296e06
* Added .gitignore.
* Added netman.desktop entry.

-- Aitor Cuadrado Zubizarreta <aitor_czr@???> Thu, 24 Sep
2015 10:19:13 +0200


#number refers to patches that I want to avoid processing. This means
to remove such a hashed number altogther.

My version:

netman (0.1.1-jessie2) unstable; urgency=medium

* New release.

-- Edward Bartolo <edbarx@???> Thu, 10 Dec 2015 19:30:00 +0100

On 10/12/2015, Edward Bartolo <edbarx@???> wrote:
> Hi Aitor et al,
>
> I am still thinking what I should do to the netman/debian directory so
> that dpkg-buildpackage succeeds to spew out the two netman .deb
> packages. I think, the trouble lies with tracking patches which I
> don't have and don't want to use for the first properly debianized
> netman source. I am suspicious changelog, control and patches are
> preventing me from getting dpkg-buildpackage do its job.
>
> Therefore, it looks like I have to devoid patches/ of any patches,
> recreate changelog to only contain one version and finally edit
> control to reflect all building requirements for netman.
>
> Readers may wonder why someone may wish to manually edit package
> configuration files instead of using tools. The reason is simply to
> understand what these files contain and their function.
>
>
> Edward
>
>
>

> On 09/12/2015, Rainer Weikusat <rainerweikusat@???> wrote:
>> Steve Litt <slitt@???> writes:
>>>>       From: Steve Litt <slitt@???>
>>>>  Subject: Re: [DNG] Debianising my uploaded version of netman.

>>>>
>>>
>>>> Anyone know a good source of GIT learning that's self-discoverable and
>>>> has a reasonable learning curve from know-nothing to expert?
>>>
>>>
>>> On Wed, 9 Dec 2015 16:57:01 +0000 (UTC)
>>> dan pridgeon <d_pridge@???> wrote:
>>>
>>>> This may help:
>>>> http://git-scm.com/book/en/v2
>>>
>>> Very nice! I've read a few pages, and so far, this appears to be
>>> *exactly* what I needed.
>>
>> It's presumably rather "what you're supposed to get", considering
>> howlers like
>>

>>     This is in sharp contrast to the way most older VCS tools
>>     branch, which involves copying all of the project’s files into a
>>     second directory.

>>
>> http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
>>
>> CVS creates branches by adding special tags to all RCS files of a
>> project but it certainly doesn't copy the files "to a second directory"
>> and anyone whoever worked with a CVS repository can be expected to now
>> that. Considering that this means the time necessary for creating a
>> branch is proportional to the number of files, this is a very slow
>> operation.
>>
>> O(1) branching didn't fell from the sky because only Linus Torvalds
>> looked hard enough for it but was introduced with Subversion which
>> - when branching - "creates a new directory entry that points to an
>> existing tree.". J. Random Know-it-all likely just won't notice that
>> because a branch has to be checked out prior to using it locally for
>> anything and this (like any other checkout) creates a copy of the files.
>>
>> The "revolutionary git concept" of "treating the content as a
>> filesystem" also came from Subversion.
>>
>> NB: As incomplete list of git commands, this text is probably good
>> enough and also as introduction to "version control concepts" provides
>> one keeps in mind that the author doesn't know any SCM but git.
>>
>> _______________________________________________
>> Dng mailing list
>> Dng@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>