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_...@gnuinos.org> 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_...@gnuinos.org> 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 <edb...@gmail.com> Thu, 10 Dec 2015 19:30:00 +0100 On 10/12/2015, Edward Bartolo <edb...@gmail.com> 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 <rainerweiku...@virginmedia.com> wrote: >> Steve Litt <sl...@troubleshooters.com> writes: >>>> From: Steve Litt <sl...@troubleshooters.com> >>>> 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_pri...@yahoo.com> 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@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
