devil-linux-develop Mailing List for Devil-Linux (Page 11)

Completely forgot, there's a new lfssystem for DL 1.5.
I'll upload it to the FTP server.

Heiko

Quoting Heiko Zuerker <he...@zu...>:

> Hey,
>
> Below are some commands from the buildroot mailinglist, which I used
> initially to figure out how this git thing works.
> If you didn't use git before then I'm sure there will be questions, so
> feel free to ask.
>
> This is the URL you'll need to use:
> ssh://username@devil-linux.git.sourceforge.net/gitroot/devil-linux/devil-linux
> of course replace username with your SF username.
>
> Here's some additional documentation:
> http://sourceforge.net/scm/?type=git&group_id=34096
>
> You find the DL specific stuff under target/devil-linux.
> There's also a default DL config under config/ which will compile a
> working x86_64 version.
>
> There are quite a few buildroot specific things if you want to add new
> scripts. A lot of information can be found here:
> http://buildroot.uclibc.org/
> I usually send any non-DL specific changes to buildroot, so they can
> incorporate it. They're quite picky about what goes in and the quality
> of the script (the 2nd one being a good thing).
>
> Heiko
>
> ----- Forwarded message from Thomas Petazzoni
> <tho...@fr...> -----
>     Date: Sun, 5 Dec 2010 09:17:24 +0100
>     From: Thomas Petazzoni <tho...@fr...>
> Subject: [Buildroot] How to contribute to Buildroot with Git
>       To: bui...@bu...
>
> On Sat, 4 Dec 2010 16:09:00 -0800 (PST)
> Justin Mark <oi...@ya...> wrote:
>
>> I can build libgee with buildroot in my workspace, how should I
>> submit the patch for review? post the patch here or directly do it
>> from git? Can someone give me some details since I don't know much
>> about git?
>
> The best is to use Git. Here is a simplified version of the Git workflow
> that I use to work with Buildroot:
>
>   1) Clone (to be done only once)
>
>      git clone git://git.busybox.net/buildroot
>
>   2) Configure Git (to be done only once)
>
>      Then tell git who you are :
>
>      git config --global user.name "Firstname Lastname"
>      git config --global user.email fir...@so...
>
>      And tell git how to send emails :
>
>      git config --global sendemail.smtpserver mysmtpserver
>
>      And to avoid chained reply :
>
>      git config --global sendemail.chainreplyto false
>
>   3) Create a branch to work on your topic (to be done for every
>      separate topic you'd like to work with)
>
>      git checkout -b mytopic
>
>      Note that this also switches immediatly to the new 'mytopic'
>      branch. You can run 'git branch' at any time to know on which
>      branch you are.
>
>   4) Make some modifications, for one particuler subtopic (like adding
>      the vala compiler)
>
>   5) Commit those modifications
>
>      git commit -s -a
>
>      And enter an appropriate commit log.
>
>      If you created new files, add them with "git add".
>
>      Then go back to step 4 for the other changes you want to do, or
>      proceed to step 6 if you're done with your changes.
>
>   6) Review your changes
>
>      git log -p master..
>
>   7) Prepare patches for your changes
>
>      git format-patch HEAD
>
>      This will generate a set of 000X-*.patch files in the Buildroot
>      directory
>
>   8) Send your patches to the list
>
>      git send-email --to bui...@uc... --compose *.patch
>
> And you're done.
>
> If while reviewing your commits you find that you need to merge some of
> them (because you did some mistakes that you fixed later and you don't
> want the world to know about your mistakes), then you have to use the
> rebasing feature of git:
>
>      git rebase -i master
>
> Git will open up a text editor with the list of your commits. You can
> edit this file to change the order of the commits, or to change the
> action taken on a particular commit (see the file itself for
> documentation on those actions). A typical thing is :
>
>      pick SOMEGITHASH package: add foobar
>      pick SOMEGITHASH package: add barfoo
>      pick SOMEGITHASH I did something wrong in add foobar, merge me
>
> So obviously you want the last commit to be merged into the first one,
> so that nobody knows you did some mistakes during your development. So,
> turn those three lines into the following ones:
>
>      pick SOMEGITHASH package: add foobar
>      fixup SOMEGITHASH I did something wrong in add foobar, merge me
>      pick SOMEGITHASH package: add barfoo
>
> And exit the text editor. Git will reorganize your commits, and you'll
> end up with just two commits.
>
> Don't hesitate to ask questions if you have issues,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> bui...@bu...
> http://lists.busybox.net/mailman/listinfo/buildroot
>
> ----- End forwarded message -----
>
> --
>
> Regards
>    Heiko Zuerker
>    http://www.devil-linux.org
>
> Quoting Serge Leschinsky <ser...@gm...>:
>
>> Hi,
>>
>> It looks like I missed instruction/howto for DL git repo. I don't post the
>> changes very often of course, but anyway -  I wouldn?t like to
>> bother Heiko with
>> tracking and resubmitting those changes. If you know where I can find the
>> manual, please let me know.
>>
>>
>> Thanks,
>> Serge
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
>
> --
>
> Regards
>    Heiko Zuerker
>    http://www.devil-linux.org
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop


-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

Hey,

Below are some commands from the buildroot mailinglist, which I used  
initially to figure out how this git thing works.
If you didn't use git before then I'm sure there will be questions, so  
feel free to ask.

This is the URL you'll need to use:
ssh://username@devil-linux.git.sourceforge.net/gitroot/devil-linux/devil-linux
of course replace username with your SF username.

Here's some additional documentation:
http://sourceforge.net/scm/?type=git&group_id=34096

You find the DL specific stuff under target/devil-linux.
There's also a default DL config under config/ which will compile a  
working x86_64 version.

There are quite a few buildroot specific things if you want to add new  
scripts. A lot of information can be found here:  
http://buildroot.uclibc.org/
I usually send any non-DL specific changes to buildroot, so they can  
incorporate it. They're quite picky about what goes in and the quality  
of the script (the 2nd one being a good thing).

Heiko

----- Forwarded message from Thomas Petazzoni  
<tho...@fr...> -----
    Date: Sun, 5 Dec 2010 09:17:24 +0100
    From: Thomas Petazzoni <tho...@fr...>
Subject: [Buildroot] How to contribute to Buildroot with Git
      To: bui...@bu...

On Sat, 4 Dec 2010 16:09:00 -0800 (PST)
Justin Mark <oi...@ya...> wrote:

> I can build libgee with buildroot in my workspace, how should I
> submit the patch for review? post the patch here or directly do it
> from git? Can someone give me some details since I don't know much
> about git?

The best is to use Git. Here is a simplified version of the Git workflow
that I use to work with Buildroot:

  1) Clone (to be done only once)

     git clone git://git.busybox.net/buildroot

  2) Configure Git (to be done only once)

     Then tell git who you are :

     git config --global user.name "Firstname Lastname"
     git config --global user.email fir...@so...

     And tell git how to send emails :

     git config --global sendemail.smtpserver mysmtpserver

     And to avoid chained reply :

     git config --global sendemail.chainreplyto false

  3) Create a branch to work on your topic (to be done for every
     separate topic you'd like to work with)

     git checkout -b mytopic

     Note that this also switches immediatly to the new 'mytopic'
     branch. You can run 'git branch' at any time to know on which
     branch you are.

  4) Make some modifications, for one particuler subtopic (like adding
     the vala compiler)

  5) Commit those modifications

     git commit -s -a

     And enter an appropriate commit log.

     If you created new files, add them with "git add".

     Then go back to step 4 for the other changes you want to do, or
     proceed to step 6 if you're done with your changes.

  6) Review your changes

     git log -p master..

  7) Prepare patches for your changes

     git format-patch HEAD

     This will generate a set of 000X-*.patch files in the Buildroot
     directory

  8) Send your patches to the list

     git send-email --to bui...@uc... --compose *.patch

And you're done.

If while reviewing your commits you find that you need to merge some of
them (because you did some mistakes that you fixed later and you don't
want the world to know about your mistakes), then you have to use the
rebasing feature of git:

     git rebase -i master

Git will open up a text editor with the list of your commits. You can
edit this file to change the order of the commits, or to change the
action taken on a particular commit (see the file itself for
documentation on those actions). A typical thing is :

     pick SOMEGITHASH package: add foobar
     pick SOMEGITHASH package: add barfoo
     pick SOMEGITHASH I did something wrong in add foobar, merge me

So obviously you want the last commit to be merged into the first one,
so that nobody knows you did some mistakes during your development. So,
turn those three lines into the following ones:

     pick SOMEGITHASH package: add foobar
     fixup SOMEGITHASH I did something wrong in add foobar, merge me
     pick SOMEGITHASH package: add barfoo

And exit the text editor. Git will reorganize your commits, and you'll
end up with just two commits.

Don't hesitate to ask questions if you have issues,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
bui...@bu...
http://lists.busybox.net/mailman/listinfo/buildroot

----- End forwarded message -----

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

Quoting Serge Leschinsky <ser...@gm...>:

> Hi,
>
> It looks like I missed instruction/howto for DL git repo. I don't post the
> changes very often of course, but anyway -  I wouldn?t like to  
> bother Heiko with
> tracking and resubmitting those changes. If you know where I can find the
> manual, please let me know.
>
>
> Thanks,
> Serge
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop


-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

Hi,

It looks like I missed instruction/howto for DL git repo. I don't post the 
changes very often of course, but anyway -  I wouldn’t like to bother Heiko with 
tracking and resubmitting those changes. If you know where I can find the 
manual, please let me know.


Thanks,
Serge

Hi diablos,
I have started to work on compiling devil-Linux 1.4.x and was thinking 
that you might have some quick ones on where people get stucked or if 
there are any known fails to watch out for. I have done two quick tests 
just to begin the tripp ... the documentation i have followed is this 
one ( http://www.devil-linux.org/documentation/1.4.x/ch03s01.html ).

The first thing was this /sys and some other dirs that could not mount 
thing.
But this one I suppose is not a problem cause they are there. so i continued

 From here is there any things i should think of that you know about to 
save some time because it takes some of it (time) to compile.
For example if there are any scripts that are in wrong order ... or any 
things that is known that i should know before starting


Martin Lindkvist

Hi,

 

I uploaded the latest CVS build to the testing directory.

Please help test this version, so we can get ready for the official 1.4.3

 

-- 

 

Regards

   Heiko Zuerker

    <http://www.devil-linux.org> http://www.devil-linux.org

 

quick and dirty - hopefully it will be irrelevant for .39

--- aoe6-76/linux/drivers/block/aoe/aoecmd.c 2011-05-26 21:56:21.000000000 -0700
+++ aoe6-76/linux/drivers/block/aoe/aoecmd.c 2011-05-26 22:01:31.000000000 -0700
@@ -17,6 +17,8 @@
  #include <asm/unaligned.h>
  #include <linux/uio.h>
  #include "aoe.h"
+#include "../../../../../linux-2.6.38/block/blk.h"
+

  static struct buf *nextbuf(struct aoedev *);
  static void ktcomplete(struct frame *, struct sk_buff *);
----------------------------------------------------------------------------


On 05/26/2011 07:01 PM, Heiko Zuerker wrote:
> Hey,
>
> I got most of the issues resolved, except aoe6:
>
> ----------
> /data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.c: In function
> 'aoe_end_request':
> /data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.c:1171: error:
> implicit declaration of function '__generic_unplug_device'
> make[2]: *** [/data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.o]
> Error 1
> make[1]: *** [_module_/data/build/tmp/aoe6-76/linux/drivers/block/aoe] Error
> 2
> make[1]: Leaving directory `/data/build/tmp/linux-2.6.38'
> -----------
> Any ideas anyone?
>
> The kernel I'm using is 2.6.38.7
>

I hear that kernel 2.8 may be out soon.  :-)

 - BS


On Thu, May 26, 2011 at 22:01, Heiko Zuerker <he...@zu...> wrote:

> Hey,
>
> I got most of the issues resolved, except aoe6:
>
> ----------
> /data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.c: In function
> 'aoe_end_request':
> /data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.c:1171: error:
> implicit declaration of function '__generic_unplug_device'
> make[2]: *** [/data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.o]
> Error 1
> make[1]: *** [_module_/data/build/tmp/aoe6-76/linux/drivers/block/aoe]
> Error
> 2
> make[1]: Leaving directory `/data/build/tmp/linux-2.6.38'
> -----------
> Any ideas anyone?
>
> The kernel I'm using is 2.6.38.7
>
> --
>
> Regards
>   Heiko Zuerker
>   http://www.devil-linux.org
>
> > -----Original Message-----
> > From: Serge Leschinsky [mailto:ser...@gm...]
> > Sent: Sunday, May 22, 2011 8:40 PM
> > To: dev...@li...
> > Subject: Re: [Devil-linux-develop] kernel
> >
> > Heiko,
> >
> > I'm fine with it.
> >
> > I live on .38.6 now and it looks fine. The possible problems are:
> > - imq patch
> > - grsec & aufs incompatibility.
> >
> > Serge
> >
> > On 05/22/2011 02:56 PM, Heiko Zuerker wrote:
> > > Hey,
> > >
> > > I'm contemplating if we should switch back to the latest and greatest
> > > kernel again. This may have some impact on stability and of course
> > > we'll sometimes have to wait for a patch to come out.
> > >
> > > The benefit would be having the latest and greatest drivers available.
> > >
> > > Thoughts?
> > >
>
>

Heiko,

I'll send you a fix shortly. The problem is in the function definition, which is 
how in linux-2.6.38/block/blk.h. So the only thing we need is add "#include 
.../block/blk.h" statement into "aoe6-76/linux/drivers/block/aoe/aoecmd.c".

Serge

On 05/26/2011 07:01 PM, Heiko Zuerker wrote:
> Hey,
>
> I got most of the issues resolved, except aoe6:
>
> ----------
> /data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.c: In function
> 'aoe_end_request':
> /data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.c:1171: error:
> implicit declaration of function '__generic_unplug_device'
> make[2]: *** [/data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.o]
> Error 1
> make[1]: *** [_module_/data/build/tmp/aoe6-76/linux/drivers/block/aoe] Error
> 2
> make[1]: Leaving directory `/data/build/tmp/linux-2.6.38'
> -----------
> Any ideas anyone?
>
> The kernel I'm using is 2.6.38.7
>

Hey,

I got most of the issues resolved, except aoe6:

----------
/data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.c: In function
'aoe_end_request':
/data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.c:1171: error:
implicit declaration of function '__generic_unplug_device'
make[2]: *** [/data/build/tmp/aoe6-76/linux/drivers/block/aoe/aoecmd.o]
Error 1
make[1]: *** [_module_/data/build/tmp/aoe6-76/linux/drivers/block/aoe] Error
2
make[1]: Leaving directory `/data/build/tmp/linux-2.6.38'
-----------
Any ideas anyone?

The kernel I'm using is 2.6.38.7

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

> -----Original Message-----
> From: Serge Leschinsky [mailto:ser...@gm...]
> Sent: Sunday, May 22, 2011 8:40 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] kernel
> 
> Heiko,
> 
> I'm fine with it.
> 
> I live on .38.6 now and it looks fine. The possible problems are:
> - imq patch
> - grsec & aufs incompatibility.
> 
> Serge
> 
> On 05/22/2011 02:56 PM, Heiko Zuerker wrote:
> > Hey,
> >
> > I'm contemplating if we should switch back to the latest and greatest
> > kernel again. This may have some impact on stability and of course
> > we'll sometimes have to wait for a patch to come out.
> >
> > The benefit would be having the latest and greatest drivers available.
> >
> > Thoughts?
> >
> 
> 
>
----------------------------------------------------------------------------
--
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its next-
> generation tools to help Windows* and Linux* C/C++ and Fortran developers
> boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Heiko,

I'm fine with it.

I live on .38.6 now and it looks fine. The possible problems are:
- imq patch
- grsec & aufs incompatibility.

Serge

On 05/22/2011 02:56 PM, Heiko Zuerker wrote:
> Hey,
>
> I'm contemplating if we should switch back to the latest and greatest
> kernel again. This may have some impact on stability and of course
> we'll sometimes have to wait for a patch to come out.
>
> The benefit would be having the latest and greatest drivers available.
>
> Thoughts?
>

Hey,

the 2.6.32.x serious was declared the long term stable and only bug  
fixes are added. Newer kernel have newer code, which of course "could"  
introduce bugs.

Heiko

Quoting Bruce Smith <bw...@re...>:

> I like the latest and greatest.  At least close to the latest and greatest
> as possible.
>
> I'm not sure what you mean by impact on stability.  Is the latest kernel
> more or less stable?
>
>  - BS
>
>
> On Sun, May 22, 2011 at 17:56, Heiko Zuerker <he...@zu...> wrote:
>
>> Hey,
>>
>> I'm contemplating if we should switch back to the latest and greatest
>> kernel again. This may have some impact on stability and of course
>> we'll sometimes have to wait for a patch to come out.
>>
>> The benefit would be having the latest and greatest drivers available.
>>
>> Thoughts?
>>
>> --
>>
>> Regards
>>   Heiko Zuerker
>>   http://www.devil-linux.org
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What Every C/C++ and Fortran developer Should Know!
>> Read this article and learn how Intel has extended the reach of its
>> next-generation tools to help Windows* and Linux* C/C++ and Fortran
>> developers boost performance applications - including clusters.
>> http://p.sf.net/sfu/intel-dev2devmay
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>


-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

I like the latest and greatest.  At least close to the latest and greatest
as possible.

I'm not sure what you mean by impact on stability.  Is the latest kernel
more or less stable?

 - BS


On Sun, May 22, 2011 at 17:56, Heiko Zuerker <he...@zu...> wrote:

> Hey,
>
> I'm contemplating if we should switch back to the latest and greatest
> kernel again. This may have some impact on stability and of course
> we'll sometimes have to wait for a patch to come out.
>
> The benefit would be having the latest and greatest drivers available.
>
> Thoughts?
>
> --
>
> Regards
>   Heiko Zuerker
>   http://www.devil-linux.org
>
>
>
>
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>

Hey,

I'm contemplating if we should switch back to the latest and greatest  
kernel again. This may have some impact on stability and of course  
we'll sometimes have to wait for a patch to come out.

The benefit would be having the latest and greatest drivers available.

Thoughts?

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org

Stefan Engel wrote:
> If it is ok, that you generate passwords, which are not easy to
> remember, you could do something like
> 
>     < /dev/urandom tr -dc _A-Za-z0-9 | head -c15
> 
> which generates a password of 15 chars length.

Thanks, Stefan

I used passwdgen with option -p (pronounced). Now I did it in this manner:

> #!/usr/bin/awk -f
> BEGIN{
>         c="bcdfghjklmnpqrstvwxzBCDFGHJKLMNPQRSTVWXZ"
>         v="aeiouyAEIOUY"
>         s="0123456789!@$%-=/+"
>         srand()
>         for (i=1;i<=1;i++)
>         {
>                 code=""
>                 for (j=1;j<=8;j++)
>                 {
>                         if(j==2||j==4||j==6)code = code""substr(v,int(rand()*length(v))+1,1)
>                         if(j==1||j==3||j==5)code = code""substr(c,int(rand()*length(c))+1,1)
>                         if(j==7||j==8||j==9)code = code""substr(s,int(rand()*length(s))+1,1)
>                 }
>                 print code
>         }
> }

so I have three syllables and two specials. This should be simple to remember.

Regards

Andrzej Odyniec

On 02/22/11 09:08, Stefan Engel wrote:
> If it is ok, that you generate passwords, which are not easy to
> remember, you could do something like
>
>      <  /dev/urandom tr -dc _A-Za-z0-9 | head -c15
>
> which generates a password of 15 chars length.

apg is good for that - generates pronounceable rubbish.

e.g:
duibTadBad9 (du-ib-Tad-Bad-NINE)
NadUcIts4 (Nad-Uc-Its-FOUR)
VodvamArf0Of (Vod-vam-Arf-ZERO-Of)
duddUKnow1 (dudd-U-Know-ONE)
SyWipthylv9 (Sy-Wip-thylv-NINE)
KnagtyozFob9 (Knag-tyoz-Fob-NINE)

It's not on DL though :-(

Dick

If it is ok, that you generate passwords, which are not easy to
remember, you could do something like

    < /dev/urandom tr -dc _A-Za-z0-9 | head -c15

which generates a password of 15 chars length.

Additional info:
http://unix.stackexchange.com/questions/462/how-to-create-strong-passwords-in-linux
http://www.cyberciti.biz/faq/linux-unix-generating-passwords-command/

Regards,
Stefan

On 02/18/2011 05:39 PM, Andrzej Odyniec wrote:
> Heiko Zuerker wrote:
>> it was removed with 1.4RC5, since it isn't maintained anymore.
> 
> So we need generate random passwords with separate scripts.
> 
> Maybe this is best solution. Without knowledge about this private script atack 
> is harder.
> 
> Regards
> 

Heiko Zuerker wrote:
> it was removed with 1.4RC5, since it isn't maintained anymore.

So we need generate random passwords with separate scripts.

Maybe this is best solution. Without knowledge about this private script atack 
is harder.

Regards

-- 
Andrzej Odyniec

Hey,

it was removed with 1.4RC5, since it isn't maintained anymore.

Heiko

Quoting Andrzej Odyniec <an...@ma...>:

> Dears,
>
> As in subject: passwdgen vanished in last half year.
>
> Are there any reasons?
>
> My script uses passwdgen and now does not work?
>
> There is no script to build. But the menuconfig configuration exist yet.
>
> What I should do? Using other program instead (any suggenstions) or build
> passwdgen as my addon?
>
> On list there is no mention.
>
> Regards
>
> --
> Andrzej Odyniec
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Dears,

As in subject: passwdgen vanished in last half year.

Are there any reasons?

My script uses passwdgen and now does not work?

There is no script to build. But the menuconfig configuration exist yet.

What I should do? Using other program instead (any suggenstions) or build 
passwdgen as my addon?

On list there is no mention.

Regards

-- 
Andrzej Odyniec

Yes it worked. 

It seems the commit email functionality is broken after they restored the CVS service.

Heiko

Quoting Bruce Smith <bw...@re...>: 

> Can someone check to see if my changes were committed to cvs?  (CHANGES & md5sum.lst)
>
> I think they were committed, but a bunch of errors happened after, which I think were related to emailing the changes out to the list.  So I think the changes were committed but the email failed.
>
> No problem uploading minicom-2.5 to the ftp site anyway.  :-)
>
> Let me know if the CVS changes are committed.  Thanks!
>
>  - BS
>
> On Sat, Feb 12, 2011 at 16:50, Bruce Smith <bw...@re...> wrote:
>
>
> > The weird thing is the "build" portion has the libraries defined, but it aborted in the "install" part, which does not.  I'm not sure why it decided to recompile some of the stuff in the install phase (without the libraries, and abort).
> >
> > In any case, I tried the latest version of Minicom (2.5) as Heiko suggested.  That builds and installs fine without modifying the build/install script.  I'll upload my fixes later today.
> >
> >  - BS 
> >
> > On Sat, Feb 12, 2011 at 02:04, Serge Leschinsky <ser...@gm...> wrote:
> >
> >
> > > Bruce,
> > >
> > > please try this:
> > >
> > >  make "LIBS=-lncurses -liconv" $PMAKE all || exit 1
> > >
> > > Serge
> > >
> > > On 02/11/2011 07:51 PM, Bruce Smith wrote:
> > >
> > >
> > > > Hey, sourceforge seems to have cvs fixed now.  I updated and started a fresh
> > > > compile.  Unfortunately it aborted installing minicom:
> > > >
> > > > Any clues?
> > > >
> > > >  - BS
> > > >
> > > >
> > > > Making install in src
> > > > make[1]: Entering directory `/data/build/tmp/minicom-2.4/src'
> > > > gcc -DHAVE_CONFIG_H -I. -I..  -I../lib -DCONFDIR="/etc"
> > > > -DLOCALEDIR="/usr/share/locale"  -mtune=i686 -march=i686 -Wall -W
> > > >  -mtune=i686 -march=i686 -MT minicom.o -MD -MP -MF .deps/minicom.Tpo -c -o
> > > > minicom.o minicom.c
> > > > mv -f .deps/minicom.Tpo .deps/minicom.Po
> > > > gcc -mtune=i686 -march=i686 -Wall -W -mtune=i686 -march=i686   -o minicom
> > > > minicom.o vt100.o config.o help.o updown.o util.o d
> > > > ial.o window.o wkeys.o ipc.o windiv.o sysdep1.o sysdep1_s.o sysdep2.o rwconf.o
> > > > main.o file.o getsdir.o wildmat.o common.o ../
> > > > lib/libport.a -lncurses
> > > > minicom.o: In function `do_iconv':
> > > > minicom.c:(.text+0x69f): undefined reference to `libiconv'
> > > > minicom.c:(.text+0x6fc): undefined reference to `libiconv'
> > > > minicom.o: In function `.L182':
> > > > minicom.c:(.text+0x1947): undefined reference to `libiconv_open'
> > > > minicom.o: In function `.L327':
> > > > minicom.c:(.text+0x3971): undefined reference to `libiconv_close'
> > > > collect2: ld returned 1 exit status
> > > > make[1]: *** [minicom] Error 1
> > > > make[1]: Leaving directory `/data/build/tmp/minicom-2.4/src'
> > > > make: *** [install-recursive] Error 1
> > > >
> > > > ------------------------------------------------------------------------------
> > > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > > > Pinpoint memory and threading errors before they happen.
> > > > Find and fix more than 250 security defects in the development cycle.
> > > > Locate bottlenecks in serial and parallel code that limit performance.
> > > > http://p.sf.net/sfu/intel-dev2devfeb
> > > >
> > > > _______________________________________________
> > > > Devil-linux-develop mailing list
> > > > Dev...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

-- 

Regards
  Heiko Zuerker
http://www.devil-linux.org

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Can someone check to see if my changes were committed to cvs?  (CHANGES &
md5sum.lst)

I think they were committed, but a bunch of errors happened after, which I
think were related to emailing the changes out to the list.  So I think the
changes were committed but the email failed.

No problem uploading minicom-2.5 to the ftp site anyway.  :-)

Let me know if the CVS changes are committed.  Thanks!

 - BS


On Sat, Feb 12, 2011 at 16:50, Bruce Smith <bw...@re...> wrote:

> The weird thing is the "build" portion has the libraries defined, but it
> aborted in the "install" part, which does not.  I'm not sure why it decided
> to recompile some of the stuff in the install phase (without the libraries,
> and abort).
>
> In any case, I tried the latest version of Minicom (2.5) as Heiko
> suggested.  That builds and installs fine without modifying the
> build/install script.  I'll upload my fixes later today.
>
>  - BS
>
>
>
> On Sat, Feb 12, 2011 at 02:04, Serge Leschinsky <
> ser...@gm...> wrote:
>
>> Bruce,
>>
>> please try this:
>>
>>  make "LIBS=-lncurses -liconv" $PMAKE all || exit 1
>>
>> Serge
>>
>> On 02/11/2011 07:51 PM, Bruce Smith wrote:
>>
>>> Hey, sourceforge seems to have cvs fixed now.  I updated and started a
>>> fresh
>>> compile.  Unfortunately it aborted installing minicom:
>>>
>>> Any clues?
>>>
>>>  - BS
>>>
>>>
>>> Making install in src
>>> make[1]: Entering directory `/data/build/tmp/minicom-2.4/src'
>>> gcc -DHAVE_CONFIG_H -I. -I..  -I../lib -DCONFDIR=\"/etc\"
>>> -DLOCALEDIR=\"/usr/share/locale\"  -mtune=i686 -march=i686 -Wall -W
>>>  -mtune=i686 -march=i686 -MT minicom.o -MD -MP -MF .deps/minicom.Tpo -c
>>> -o
>>> minicom.o minicom.c
>>> mv -f .deps/minicom.Tpo .deps/minicom.Po
>>> gcc -mtune=i686 -march=i686 -Wall -W -mtune=i686 -march=i686   -o minicom
>>> minicom.o vt100.o config.o help.o updown.o util.o d
>>> ial.o window.o wkeys.o ipc.o windiv.o sysdep1.o sysdep1_s.o sysdep2.o
>>> rwconf.o
>>> main.o file.o getsdir.o wildmat.o common.o ../
>>> lib/libport.a -lncurses
>>> minicom.o: In function `do_iconv':
>>> minicom.c:(.text+0x69f): undefined reference to `libiconv'
>>> minicom.c:(.text+0x6fc): undefined reference to `libiconv'
>>> minicom.o: In function `.L182':
>>> minicom.c:(.text+0x1947): undefined reference to `libiconv_open'
>>> minicom.o: In function `.L327':
>>> minicom.c:(.text+0x3971): undefined reference to `libiconv_close'
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [minicom] Error 1
>>> make[1]: Leaving directory `/data/build/tmp/minicom-2.4/src'
>>> make: *** [install-recursive] Error 1
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>>> Pinpoint memory and threading errors before they happen.
>>> Find and fix more than 250 security defects in the development cycle.
>>> Locate bottlenecks in serial and parallel code that limit performance.
>>> http://p.sf.net/sfu/intel-dev2devfeb
>>>
>>>
>>>
>>> _______________________________________________
>>> Devil-linux-develop mailing list
>>> Dev...@li...
>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>
>>
>>
>

The weird thing is the "build" portion has the libraries defined, but it
aborted in the "install" part, which does not.  I'm not sure why it decided
to recompile some of the stuff in the install phase (without the libraries,
and abort).

In any case, I tried the latest version of Minicom (2.5) as Heiko
suggested.  That builds and installs fine without modifying the
build/install script.  I'll upload my fixes later today.

 - BS


On Sat, Feb 12, 2011 at 02:04, Serge Leschinsky <
ser...@gm...> wrote:

> Bruce,
>
> please try this:
>
>  make "LIBS=-lncurses -liconv" $PMAKE all || exit 1
>
> Serge
>
> On 02/11/2011 07:51 PM, Bruce Smith wrote:
>
>> Hey, sourceforge seems to have cvs fixed now.  I updated and started a
>> fresh
>> compile.  Unfortunately it aborted installing minicom:
>>
>> Any clues?
>>
>>  - BS
>>
>>
>> Making install in src
>> make[1]: Entering directory `/data/build/tmp/minicom-2.4/src'
>> gcc -DHAVE_CONFIG_H -I. -I..  -I../lib -DCONFDIR=\"/etc\"
>> -DLOCALEDIR=\"/usr/share/locale\"  -mtune=i686 -march=i686 -Wall -W
>>  -mtune=i686 -march=i686 -MT minicom.o -MD -MP -MF .deps/minicom.Tpo -c -o
>> minicom.o minicom.c
>> mv -f .deps/minicom.Tpo .deps/minicom.Po
>> gcc -mtune=i686 -march=i686 -Wall -W -mtune=i686 -march=i686   -o minicom
>> minicom.o vt100.o config.o help.o updown.o util.o d
>> ial.o window.o wkeys.o ipc.o windiv.o sysdep1.o sysdep1_s.o sysdep2.o
>> rwconf.o
>> main.o file.o getsdir.o wildmat.o common.o ../
>> lib/libport.a -lncurses
>> minicom.o: In function `do_iconv':
>> minicom.c:(.text+0x69f): undefined reference to `libiconv'
>> minicom.c:(.text+0x6fc): undefined reference to `libiconv'
>> minicom.o: In function `.L182':
>> minicom.c:(.text+0x1947): undefined reference to `libiconv_open'
>> minicom.o: In function `.L327':
>> minicom.c:(.text+0x3971): undefined reference to `libiconv_close'
>> collect2: ld returned 1 exit status
>> make[1]: *** [minicom] Error 1
>> make[1]: Leaving directory `/data/build/tmp/minicom-2.4/src'
>> make: *** [install-recursive] Error 1
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>>
>>
>>
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>
>

Hey,

minicom 2.5 is out too, which may be worth a try.

Heiko

Quoting Serge Leschinsky <ser...@gm...>:
> Bruce,
>
> please try this:
>
>    make "LIBS=-lncurses -liconv" $PMAKE all || exit 1
>
> Serge
>
> On 02/11/2011 07:51 PM, Bruce Smith wrote:
>> Hey, sourceforge seems to have cvs fixed now.  I updated and started a fresh
>> compile.  Unfortunately it aborted installing minicom:
>>
>> Any clues?
>>
>>   - BS
>>
>>
>> Making install in src
>> make[1]: Entering directory `/data/build/tmp/minicom-2.4/src'
>> gcc -DHAVE_CONFIG_H -I. -I..  -I../lib -DCONFDIR=\"/etc\"
>> -DLOCALEDIR=\"/usr/share/locale\"  -mtune=i686 -march=i686 -Wall -W
>>   -mtune=i686 -march=i686 -MT minicom.o -MD -MP -MF .deps/minicom.Tpo -c -o
>> minicom.o minicom.c
>> mv -f .deps/minicom.Tpo .deps/minicom.Po
>> gcc -mtune=i686 -march=i686 -Wall -W -mtune=i686 -march=i686   -o minicom
>> minicom.o vt100.o config.o help.o updown.o util.o d
>> ial.o window.o wkeys.o ipc.o windiv.o sysdep1.o sysdep1_s.o  
>> sysdep2.o rwconf.o
>> main.o file.o getsdir.o wildmat.o common.o ../
>> lib/libport.a -lncurses
>> minicom.o: In function `do_iconv':
>> minicom.c:(.text+0x69f): undefined reference to `libiconv'
>> minicom.c:(.text+0x6fc): undefined reference to `libiconv'
>> minicom.o: In function `.L182':
>> minicom.c:(.text+0x1947): undefined reference to `libiconv_open'
>> minicom.o: In function `.L327':
>> minicom.c:(.text+0x3971): undefined reference to `libiconv_close'
>> collect2: ld returned 1 exit status
>> make[1]: *** [minicom] Error 1
>> make[1]: Leaving directory `/data/build/tmp/minicom-2.4/src'
>> make: *** [install-recursive] Error 1
>>
>>
>>
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>>
>>
>>
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Bruce,

please try this:

   make "LIBS=-lncurses -liconv" $PMAKE all || exit 1

Serge

On 02/11/2011 07:51 PM, Bruce Smith wrote:
> Hey, sourceforge seems to have cvs fixed now.  I updated and started a fresh
> compile.  Unfortunately it aborted installing minicom:
>
> Any clues?
>
>   - BS
>
>
> Making install in src
> make[1]: Entering directory `/data/build/tmp/minicom-2.4/src'
> gcc -DHAVE_CONFIG_H -I. -I..  -I../lib -DCONFDIR=\"/etc\"
> -DLOCALEDIR=\"/usr/share/locale\"  -mtune=i686 -march=i686 -Wall -W
>   -mtune=i686 -march=i686 -MT minicom.o -MD -MP -MF .deps/minicom.Tpo -c -o
> minicom.o minicom.c
> mv -f .deps/minicom.Tpo .deps/minicom.Po
> gcc -mtune=i686 -march=i686 -Wall -W -mtune=i686 -march=i686   -o minicom
> minicom.o vt100.o config.o help.o updown.o util.o d
> ial.o window.o wkeys.o ipc.o windiv.o sysdep1.o sysdep1_s.o sysdep2.o rwconf.o
> main.o file.o getsdir.o wildmat.o common.o ../
> lib/libport.a -lncurses
> minicom.o: In function `do_iconv':
> minicom.c:(.text+0x69f): undefined reference to `libiconv'
> minicom.c:(.text+0x6fc): undefined reference to `libiconv'
> minicom.o: In function `.L182':
> minicom.c:(.text+0x1947): undefined reference to `libiconv_open'
> minicom.o: In function `.L327':
> minicom.c:(.text+0x3971): undefined reference to `libiconv_close'
> collect2: ld returned 1 exit status
> make[1]: *** [minicom] Error 1
> make[1]: Leaving directory `/data/build/tmp/minicom-2.4/src'
> make: *** [install-recursive] Error 1
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
>
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Hey, sourceforge seems to have cvs fixed now.  I updated and started a fresh
compile.  Unfortunately it aborted installing minicom:

Any clues?

 - BS


Making install in src
make[1]: Entering directory `/data/build/tmp/minicom-2.4/src'
gcc -DHAVE_CONFIG_H -I. -I..  -I../lib -DCONFDIR=\"/etc\"
-DLOCALEDIR=\"/usr/share/locale\"  -mtune=i686 -march=i686 -Wall -W
 -mtune=i686 -march=i686 -MT minicom.o -MD -MP -MF .deps/minicom.Tpo -c -o
minicom.o minicom.c
mv -f .deps/minicom.Tpo .deps/minicom.Po
gcc -mtune=i686 -march=i686 -Wall -W -mtune=i686 -march=i686   -o minicom
minicom.o vt100.o config.o help.o updown.o util.o d
ial.o window.o wkeys.o ipc.o windiv.o sysdep1.o sysdep1_s.o sysdep2.o
rwconf.o main.o file.o getsdir.o wildmat.o common.o ../
lib/libport.a -lncurses
minicom.o: In function `do_iconv':
minicom.c:(.text+0x69f): undefined reference to `libiconv'
minicom.c:(.text+0x6fc): undefined reference to `libiconv'
minicom.o: In function `.L182':
minicom.c:(.text+0x1947): undefined reference to `libiconv_open'
minicom.o: In function `.L327':
minicom.c:(.text+0x3971): undefined reference to `libiconv_close'
collect2: ld returned 1 exit status
make[1]: *** [minicom] Error 1
make[1]: Leaving directory `/data/build/tmp/minicom-2.4/src'
make: *** [install-recursive] Error 1