Re: [DNG] Avoid 'git commit -m ...' every time code is tested, after editing.

[aitor_czr]

Hi Steve,

On 02/16/2016 07:47 AM, dng-requ...@lists.dyne.org wrote:

When a version is a release, don't you just give it a tag?

SteveT


Yes, but you can also give a tag to a concrete commit[*], for example:

$ git tag -a 0.1.1-9928033

You can recover it checking out the tag:

$ git checkout 0.1.1-9928033

But after doing that, you must create a branch, because in this status 
you will have a disconnected HEAD and you will lose your changes.


Cheers,

  Aitor.

[*] Somebody will consider it a bit bizarre.
 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Avoid 'git commit -m ...' every time code is tested after editing.

[Daniel Reurich]

On 16 February 2016 3:35:55 PM NZDT, Steve Litt  
wrote:
>On Mon, 15 Feb 2016 14:00:46 +
>KatolaZ  wrote:
>
>> On Mon, Feb 15, 2016 at 01:05:25PM +, Rainer Weikusat wrote:
>> > Edward Bartolo  writes:  
>> > > I need to avoid having to "git commit -m ..." every time I
>> > > add/modify code. I need to 'git buildpackage' without committing
>> > > changes. The reason is to make sure new code works before
>> > > committing.  
>> > 
>> > In my opinion, that's an unfortunate way to use a SCM because it's
>> > than not used as a change management system but more like a release
>> > tracking system. I usually commit every somewhat self-contained
>> > unit of work, eg, every new function or signficant change to an
>> > existing function without even knowing if the code compiles, let
>> > alone works (this requires private branches if more than one person
>> > works on a codebase). This means I get a detailed and commented
>> > history of all changes I made which makes it easy to determine why
>> > something was changed/ written in a particular way and also means
>> > that I can always throw the current working files away (instead of
>> > trying to reconstruct them after an ill-advised change, be it some
>> > idea which just didn't work out or accidentally damaging a file)
>> > without losing a lot of work.  
>> 
>> +1 
>> 
>> Try to use git for what it was conceived: revision management. And a
>> revision is not a release. The strategy suggested by Rainer,
>> i.e. maintaining personal branches where every consistent set of
>> changes is fixed into a commit, is usually the easiest way out. 
>> 
>> Commit often. Branch whenever needed needed. Merge when it
>> works. Release when "perfect" (the last one should be really
>> considered with a pinch of salt :P).
>
>When a version is a release, don't you just give it a tag?
>
Yes.  But that is no excuse for not using private branches to develop on.  If 
you have to revert a commit your probably doing it wrong.  Please keep master 
branches for merging tested and release ready branches only.  

For Devuan packaging projects, devuan/ branches should be marked 
protected and changes proposed via merge requests.  And the owners/masters 
should be the only ones to merge changes and set release tags.

Daniel
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Avoid 'git commit -m ...' every time code is tested after editing.

[Steve Litt]

On Mon, 15 Feb 2016 14:00:46 +
KatolaZ  wrote:

> On Mon, Feb 15, 2016 at 01:05:25PM +, Rainer Weikusat wrote:
> > Edward Bartolo  writes:  
> > > I need to avoid having to "git commit -m ..." every time I
> > > add/modify code. I need to 'git buildpackage' without committing
> > > changes. The reason is to make sure new code works before
> > > committing.  
> > 
> > In my opinion, that's an unfortunate way to use a SCM because it's
> > than not used as a change management system but more like a release
> > tracking system. I usually commit every somewhat self-contained
> > unit of work, eg, every new function or signficant change to an
> > existing function without even knowing if the code compiles, let
> > alone works (this requires private branches if more than one person
> > works on a codebase). This means I get a detailed and commented
> > history of all changes I made which makes it easy to determine why
> > something was changed/ written in a particular way and also means
> > that I can always throw the current working files away (instead of
> > trying to reconstruct them after an ill-advised change, be it some
> > idea which just didn't work out or accidentally damaging a file)
> > without losing a lot of work.  
> 
> +1 
> 
> Try to use git for what it was conceived: revision management. And a
> revision is not a release. The strategy suggested by Rainer,
> i.e. maintaining personal branches where every consistent set of
> changes is fixed into a commit, is usually the easiest way out. 
> 
> Commit often. Branch whenever needed needed. Merge when it
> works. Release when "perfect" (the last one should be really
> considered with a pinch of salt :P).

When a version is a release, don't you just give it a tag?

SteveT

Steve Litt 
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Installing different version of Linux

[Daniel Reurich]

Hi

Setup a repo for devuan backports using the merged mirror and jessie-backports 
as the target distrobution.



On 14 February 2016 9:55:36 PM NZDT, swdev  wrote:
>Hi there
>
>Long time lurker - first post :)
>
>Thanks for all the hard-work from the Devuan developers.
>
>I installed devuan alpha2 maybe a month ago, and am slowly installing
>other
>apps as I need them.
>
>So far, all is well.
>
>I noticed that I am running Linux 3.16
>
>~$ uname -a
>Linux jrlp02 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3
>(2016-01-17) x86_64 GNU/Linux
>~$
>
>Is there some where I can find pre-packaged versions of Linux - say 4.4
>for
>installation, or would I have to install the source and complie?
>
>Would this be sensible to install and test?
>
>Many thanks
>
>swdev1
>
>
>
>
>___
>Dng mailing list
>Dng@lists.dyne.org
>https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Avoid 'git commit -m ...' every time code is tested after editing.

[Adam Borowski]

On Mon, Feb 15, 2016 at 02:00:46PM +, KatolaZ wrote:
> Try to use git for what it was conceived: revision management. And a
> revision is not a release. The strategy suggested by Rainer,
> i.e. maintaining personal branches where every consistent set of
> changes is fixed into a commit, is usually the easiest way out. 
> 
> Commit often. Branch whenever needed needed. Merge when it
> works. Release when "perfect" (the last one should be really
> considered with a pinch of salt :P).

Commits can be massaged, rewritten, squashed, etc.
A very powerful yet convenient tool can be invoked with:
git rebase -i origin/master
(where "origin" is the remote you push to -- if you never named it yourself,
it's name is just "origin").

You should never edit commits that have been pushed to any public
repository, that's why the above command uses that as the base.

-- 
A tit a day keeps the vet away.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Avoid 'git commit -m ...' every time code is tested after editing.

[KatolaZ]

On Mon, Feb 15, 2016 at 01:05:25PM +, Rainer Weikusat wrote:
> Edward Bartolo  writes:
> > I need to avoid having to "git commit -m ..." every time I add/modify
> > code. I need to 'git buildpackage' without committing changes. The
> > reason is to make sure new code works before committing.
> 
> In my opinion, that's an unfortunate way to use a SCM because it's than
> not used as a change management system but more like a release tracking
> system. I usually commit every somewhat self-contained unit of work, eg,
> every new function or signficant change to an existing function without
> even knowing if the code compiles, let alone works (this requires
> private branches if more than one person works on a codebase). This
> means I get a detailed and commented history of all changes I made which
> makes it easy to determine why something was changed/ written in a
> particular way and also means that I can always throw the current
> working files away (instead of trying to reconstruct them after an
> ill-advised change, be it some idea which just didn't work out or
> accidentally damaging a file) without losing a lot of work.

+1 

Try to use git for what it was conceived: revision management. And a
revision is not a release. The strategy suggested by Rainer,
i.e. maintaining personal branches where every consistent set of
changes is fixed into a commit, is usually the easiest way out. 

Commit often. Branch whenever needed needed. Merge when it
works. Release when "perfect" (the last one should be really
considered with a pinch of salt :P).

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Avoid 'git commit -m ...' every time code is tested after editing.

[Rainer Weikusat]

Edward Bartolo  writes:
> I need to avoid having to "git commit -m ..." every time I add/modify
> code. I need to 'git buildpackage' without committing changes. The
> reason is to make sure new code works before committing.

In my opinion, that's an unfortunate way to use a SCM because it's than
not used as a change management system but more like a release tracking
system. I usually commit every somewhat self-contained unit of work, eg,
every new function or signficant change to an existing function without
even knowing if the code compiles, let alone works (this requires
private branches if more than one person works on a codebase). This
means I get a detailed and commented history of all changes I made which
makes it easy to determine why something was changed/ written in a
particular way and also means that I can always throw the current
working files away (instead of trying to reconstruct them after an
ill-advised change, be it some idea which just didn't work out or
accidentally damaging a file) without losing a lot of work.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan Jessie Alpha4 Installer "Expert Mode" Problems

[David Kuehling]

> Tobias writes

> Hi David, there should be something mounted under
> /sys/firmware/efi/efivars (or /sys/firmware/efi/vars, but that is the
> older interface) for efibootmgr to work. Does "efibootmgr" show any
> output for you?

I do have some stuff under /sys/firmware/efi/vars, but not under
/sys/firmware/efi/efivars.  The stuff in efi/vars seems to be provided
by 'sysfs'.  According to 'man efibootmgr':

  Note: efibootmgr requires that the kernel support access
  to EFI non-volatile
  variables through /sys/firmware/efi/vars or
  /sys/firmware/efi/efivars/.

I guess mounting efivars is not required.  efibootmgr invocation shows:

  BootCurrent: 
  Timeout: 0 seconds
  BootOrder: ,0001,0002,0003,0004,0005
  Boot* devuan
  Boot0001* Hard Drive 
  [..]

David

PS: Please keep the discussion on-list.
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Avoid 'git commit -m ...' every time code is tested after editing.

[Edward Bartolo]

Hi,

Do not reply to this: I used --git-ignore-changes. It works as I need it.

Edward

On 15/02/2016, Edward Bartolo  wrote:
> Hi,
>
> I need to avoid having to "git commit -m ..." every time I add/modify
> code. I need to 'git buildpackage' without committing changes. The
> reason is to make sure new code works before committing. This also
> makes commits more meaningful.
>
> So, in short, I need this:
>
> 1) edit / modify code
> 2) build package to test whether the new code additions/edits work as
> intended
>
> Since I am using git, I think, I also must avoid using
> 'dpkg-buildpackage' but have to use 'git buildpackage' instead.
>
> How can I 'git buildpackage' without committing code additions/edits
> through 'git commit -m ..."?
>
> Please note, that the last question does NOT mean I want to discard
> the changes but I want to test the code additions/edits without
> actually having to 'git commit -m ...'.
>
> Edward
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] I need to be able to push and pull changes.

[Edward Bartolo]

Hi Aitor,

Thanks for explaining what I need to do. Changes 'pushed'.

Edward

On 14/02/2016, aitor_czr  wrote:
> Hi Edward and Daniel,
>
> El 13/02/16 20:50, Edward Bartolo  escribió:
>> Hi All,
>>
>> I can push changes now. I can also pull using 'git pull url'.
>>
>> Please, ignore this mail.
>>
>> KatolaZ helped me solve the issue.
>>
>> The Daniel Reurich's simple-netaid fork now can build packages using
>> git buildpackage. I added the missing .desktop file.
>>
>> Thanks.
>
> I forgot to add db_settitle to simple-netaid-gui.postinst:
>
> #!/bin/sh -e
>
> . /usr/share/debconf/confmodule
>
> db_version 2.0
> db_settitle
>
> [...]
>
>
> wich takes the title from simple-netaid-gui.templates file:
>
> Template: simple-netaid-gui/title
> Type: boolean
> Description: simple-netaid-gui
>
> [...]
>
> You must also rectify the "Description" in this template. I wrote
> "|Description: netma-gui"|instead of "|Description: |netman-gui", and it
> has not been replaced by "simple-netaid-gui"
>
> Cheers,
>
>Aitor.
>
>
>
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Avoid 'git commit -m ...' every time code is tested after editing.

[Edward Bartolo]

Hi,

I need to avoid having to "git commit -m ..." every time I add/modify
code. I need to 'git buildpackage' without committing changes. The
reason is to make sure new code works before committing. This also
makes commits more meaningful.

So, in short, I need this:

1) edit / modify code
2) build package to test whether the new code additions/edits work as intended

Since I am using git, I think, I also must avoid using
'dpkg-buildpackage' but have to use 'git buildpackage' instead.

How can I 'git buildpackage' without committing code additions/edits
through 'git commit -m ..."?

Please note, that the last question does NOT mean I want to discard
the changes but I want to test the code additions/edits without
actually having to 'git commit -m ...'.

Edward
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan Jessie Alpha4 Installer "Expert Mode" Problems

[David Kuehling]

(BTW you replied directly to me, moving the conversation back to DNG.)

> Tobias writes:

> Hi David, I am curious, how does Devuan mount efivars on UEFI systems?
> There was much noise about that topic on the Devuan ML (and IRC)
> recently, but apparently nobody ran an EFI system.

> "mount | grep efi" should produce the relevant output.

Does not seem to mount efivars at all:

  # mount|grep efi
  /dev/sda1 on /boot/efi type vfat
  
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro)

Don't know much about EFI myself, using it for the first time.  The Bios
here seems to boot any disks containing a vfat partition with
efi-compatible boot-loader.

cheers, 

David
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk2.gpg
Fingerprint: B63B 6AF2 4EEB F033 46F7  7F1D 935E 6F08 E457 205F
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng