Steve Jones | 2 Jun 2012 17:36

Just a test


This a test to see if it can get through.

I think lfs lists might be /dev/null-ing me because Return-Path does not
match my subscribed email.  If this does get through then that shoud be
the case.

Dose anybody know how to force mutt -> postfix -> "smptd relay host" to
make the Return-Path header match the From header?

-- 
Steve Jones
sjml <at> slohj.org
--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Andrew Elian | 3 Jun 2012 02:12
Picon
Favicon

Re: Just a test

Hi,

On Sat, Jun 02, 2012 at 10:36:19AM -0500, Steve Jones wrote:
> 
> This a test to see if it can get through.
> I think lfs lists might be /dev/null-ing me because Return-Path does not
> match my subscribed email.  If this does get through then that shoud be
> the case.

> Dose anybody know how to force mutt -> postfix -> "smptd relay host" to
> make the Return-Path header match the From header?
Although I haven't used postfix for a while, I do remember trying to
solve this gotcha.

In your ~/.muttrc add this line:
set reply_to=no

In /etc/postfix/sender_canonical:
bob <at> mail.homedomain.com       robert.smith <at> hisisp.net

And if needed for authentication in
/etc/postfix/sasl_passwd
smtp.hisisp.net  robert.smith <at> hisisp.net:superduperpasswd

  postmap sasl_passwd
  postmap sender_canonical
Which should create sasl_passwd.db and sender_canonical.db

Check /etc/postfix/main.cf and add the following, if needed:

(Continue reading)

Steve Jones | 3 Jun 2012 16:51

Re: Just a test

On Sat, 02 Jun 2012, Andrew Elian wrote:

> Hi,
> 
> On Sat, Jun 02, 2012 at 10:36:19AM -0500, Steve Jones wrote:
> > 
> > This a test to see if it can get through.
> > I think lfs lists might be /dev/null-ing me because Return-Path does not
> > match my subscribed email.  If this does get through then that shoud be
> > the case.
> 
> > Dose anybody know how to force mutt -> postfix -> "smptd relay host" to
> > make the Return-Path header match the From header?
> Although I haven't used postfix for a while, I do remember trying to
> solve this gotcha.
> 
> In your ~/.muttrc add this line:
> set reply_to=no
> 
> In /etc/postfix/sender_canonical:
> bob <at> mail.homedomain.com       robert.smith <at> hisisp.net
> 
> And if needed for authentication in
> /etc/postfix/sasl_passwd
> smtp.hisisp.net  robert.smith <at> hisisp.net:superduperpasswd
> 
>   postmap sasl_passwd
>   postmap sender_canonical
> Which should create sasl_passwd.db and sender_canonical.db
> 
(Continue reading)

LM | 25 Jun 2012 13:57
Picon

rolling your own package management

Was just wondering if there were any good resources on package
management or if anyone had any tips.  Read through
http://www.linuxfromscratch.org/lfs/view/development/chapter06/pkgmgt.html
and some other articles.  Am interested in pros and cons of different
package management designs.

Have not been thrilled with most of the Linux package managers out
there that I've tried.  I think Slackware comes closest to what I'm
comfortable with.  Was considering using a Slackware style package
management system with spkg.  However, I've been doing some
modifications to the Slackware package format to suit my own needs and
am now considering creating my own system.  I already have scripts
I've created to install and uninstall tarballs and check for
collisions between files.  Would be very interested in finding out
more about design issues with regards to package management software
and to compare notes with others on how they do package management on
their own systems.  Anyone have any tips or tricks to share?

Thanks.
Sincerely,
Laura
http://www.distasis.com/cpp
--

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-chat
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Eric Herman | 25 Jun 2012 23:23
Favicon
Gravatar

Re: rolling your own package management

Hello Laura,

My first LFS system used *no* package management, next I tried using the 
"stow" approach, later I tried reading up on how debian does things, but 
ultimately I found something that fit me better. From this I project 
that some people will have to build a couple of systems before they have 
something they like and fits them.

If you're feeling like slackware style fits closest to you, I encourage 
you to try something which you might find as nice as I do: I have been 
using a slightly modified version of the "Package Users" system for a 
number of years now. Original link:

http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt

I find this fits nicely into a world of helping me understand my system 
as well as making me think about situations where one package wants to 
over-write the files of another package or set up special privileges 
(like run as root) for files.

To make life better for myself, I added an "ldconfig" user to Matthias 
Beckmann's original plan, and my friend (who goes by Random) did a nice 
job of pulling both of our mods into a gentle fork, which is mirrored here:

https://github.com/ericherman/package-users

I have come to really appreciate this approach, but I know that other 
approaches (like actually building .deb/.rpm or variations on the 
"forest of symlinks" approach) are more in-keeping with traditional 
distros, and that makes an LFS system a little less alien, but from your 
(Continue reading)

LM | 27 Jun 2012 13:59
Picon

rolling your own package management

Eric Herman wrote:
> To make life better for myself, I added an "ldconfig" user to Matthias
> Beckmann's original plan, and my friend (who goes by Random) did a nice
> job of pulling both of our mods into a gentle fork, which is mirrored here:
>
> https://github.com/ericherman/package-users

Thanks for the link.

Does this scale well when you have lots of packages?

I'm rereading http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt
and it sounds like you have to make sure the makefile doesn't perform
certain functions during install (like install to a non-install
directory or mess with permissions).  What are your experiences with
going through and changing the makefiles (configure, cmake scripts,
etc.) to handle this?  Do you have to redo the patches/fixes you make
for these situations each time you upgrade to a newer version of the
software?

As I'm building various programs (on different operating systems), I'm
hitting lots of situations where the makefiles fail and I'm ending up
with lots of patches just to get programs to build properly.  Been
trying to use the DESTDIR variable to install to directories I want.
However, some applications don't honor it.  Some applications have the
compiler name hard-coded.  Might be fine if you're always using gcc,
but what if you want to use lsbcc instead?  Also having issues with
programs installing files all over the place.  Some put files under
their own directories like openssl (I ended up with a \usr\local\ssl
directory) and some put files in etc. or /usr/local/etc.  Files also
(Continue reading)

Eric Herman | 27 Jun 2012 20:43
Favicon
Gravatar

Re: rolling your own package management

On 06/27/2012 01:59 PM, LM wrote:
> Eric Herman wrote:
>> To make life better for myself, I added an "ldconfig" user to Matthias
>> Beckmann's original plan, and my friend (who goes by Random) did a nice
>> job of pulling both of our mods into a gentle fork, which is mirrored here:
>>
>> https://github.com/ericherman/package-users
>
> Thanks for the link.
>
> Does this scale well when you have lots of packages?

I suppose that depends on what you mean by "lots", but I use it for my 
desktop systems, so yes, I would say yes. At the moment, as I have 
recently rebuilt my desktop, I have only 215-or-so packages installed.

(counting xorg as a single package)

if you grab:

wget logicgate.nl/eric/dload/eric-pkgusr-options-20120612.tar.xz

You'll get a tarball containing the "options" files for all of the 
packages I have installed. You'll see that most of them are not very 
interesting ... basicaly "configure --prefix=/usr" and "make" and "make 
check" and "make install" .... some have a lot more command line args, 
take a look.

also I did a "forall_direntries_from openssl" and included the output to 
a file included in the tarball.
(Continue reading)

LM | 28 Jun 2012 13:32
Picon

Re: rolling your own package management

Eric Herman wrote:
> if you grab:
>
> wget logicgate.nl/eric/dload/eric-pkgusr-options-20120612.tar.xz
>
> You'll get a tarball containing the "options" files for all of the
> packages I have installed.

Thank you very much for sharing this.  It definitely answers some of
the questions I had.

> With one or two exceptions, I don't do patches at all.
>
> When there's a snag in a package, usually someone else has found and
> solved it before me. I am able to use the instructions in "Beyond Linux
>  From Scratch" or the instructions in "Community Driven BLFS" as a
> starting point for almost everything.

I've been doing several patches.  I see a program and think it could
be better with a certain change, so I make it.  I do typically try to
send my patches upstream, but the majority of times the developers
aren't interested and sometimes they're downright nasty about it.  I
did a patch to hunspell to output in a format compatible with GNU
compiler errors, so I could it use it with a programming editor that
could jump to files and error lines.  That did make it back into
hunspell. I've done some changes to midi Karaoke support in abc2midi.
That also made it back into the program.  I've done a major overhaul
of dclock to convert from K&R to ANSI C.  I've patched some FLTK and
WxWidgets programs to get them to run with the latest versions of
their GUI libraries instead of older versions.  I've done several
(Continue reading)

Eric Herman | 28 Jun 2012 20:33
Favicon
Gravatar

Re: rolling your own package management

On 06/28/2012 01:32 PM, LM wrote:

> Thank you very much for sharing this.  It definitely answers some of
> the questions I had.

Certainly. The process for building "xorg" is more complicated, and is 
not reflected in the "options" file included.

>
>> With one or two exceptions, I don't do patches at all.
>>
>> When there's a snag in a package, usually someone else has found and
>> solved it before me. I am able to use the instructions in "Beyond Linux
>>   From Scratch" or the instructions in "Community Driven BLFS" as a
>> starting point for almost everything.
>
> I've been doing several patches.  I see a program and think it could
> be better with a certain change, so I make it.

Let me be more specific: with one or two exceptions, I don't usually 
have to write my own patches in order to a get a package to install in 
the way I want. Commandline options to configure and make and what-not 
usually do the trick, and when they do not, someone else contributing to 
(B)LFS or C(B)LFS has usually figured out this before me.

To your desire: running modified versions of programs, this I do. The 
package-users fork on github is very friendly to running my own patches. 
There is a "build" script which untars the source in the "src" directory 
and then looks for a "patches" directory with patches to apply
and applies any it finds.
(Continue reading)


Gmane