Building on Nate's answer.

On Sat, Jul 04, 2015 at 07:23:52AM -0500, Nate Bargmann wrote:
> * On 2015 04 Jul 05:02 -0500, John Jensen wrote:
> > Hi All,
> >
> > I've been following this list for a long time. I'm a supporter of open
> > source and the philosophy around it. I studied programming years ago but as
> > the work where I live, at the time, was in other areas I moved on to other
> > things. If one wnated to learn C to contribute to the community what is the
> > most direct approach? What books would be most relevant? Do those of you
> > who program use IDEs and if so which? There's an IDE called CODE::BLOCKS
> > (?) that I've looked and I've read is quite good.
> >
> > I have a book on C basics, C Primer Plus, that I'll have to work through to
> > get my mind back into that thought process, but after that where?
>
> Knowing C is a good start as you've already surmised. A lot of
> programmers regard "The C Programming Language" for ANSI C by Kernighan
> and Ritchie as definitive. C as implemented by GNU follows the C
> standard but also adds its own extensions they you may or may not need
> to be aware of.

[snip discussion of build systems]

> If your package uses third party libraries you'll want to get familiar
> with their documentation. In most all cases the GNU C library
> documentation will prove indispensable. When you need to access the
> kernel API directly, the book "The Linux Programming Interface" by
> Michael Kerrisk, maintainer of the Linux man pages, goes plenty well in
> depth:
>
> http://www.man7.org/tlpi/

The related package is manpages-dev (sections 2 & 3).
non-free/manpages-posix-dev is something you should also have if you want
to write portable code; it's section 3posix.
contrib/susv4 is the latest (HTML? PDF?) version of the POSIX standards.


> As for an IDE, I use GNU Emacs for my editor and GDB debugger
> interface. I'm still working to get comfortable with it. I handle
> building and source code management directly from a terminal (Xfce
> Terminal to be precise). This is less objective and a quite more
> personal decision that you will need to sort out for yourself. Plenty
> of options exist for you to try.

I use vim (occasionally nvi) and sometimes nedit for an editor.
Most editors in the repository will do.
Besides gdb (and the various UIs for it), other tools that come in handy
are strace (traces syscalls, showing return values) and ltrace (likewise
but for library calls). I've also heard of xtruss (X11 calls) and ptrace.


> Finally, there is source code management. Right now the most popular
> SCM in the Linux world is Git. Learn it on a most basic level as it in
> use by most projects you will encounter. Second place is Subversion.
> Distant third place contenders are Mercurial, Bazaar, and CVS.
> Knowledge of these SCMs is only needed if the project uses them,
> otherwise just knowing they exist is sufficient.

Often, low-level projects that aren't in git are in CVS.
As far as I know, the two packages I've used that are still in hg
(mercurial) are OSS4 and Firefox. Emacs just switched from Bazaar
to git.

Understanding the Debian packaging system is probably going to be
helpful; here's the New Maintainer's Guide:
https://www.debian.org/doc/manuals/maint-guide/index.en.html

debian/rules is written in Make, so you will need to understand that.

You'll probably need to understand shell scripting, but you may know
it already. Just ask if you want anything more.

HTH,
Isaac Dunham