Re: eagle-lin64-7.5.0.run, won't

2016-01-19 Thread Chris Bannister
On Sun, Jan 17, 2016 at 05:19:34PM -0500, Gene Heskett wrote:
> 
> I hadn't thought of that.  My bad. OTOH, although no one has come thru 
> the router except to view my web page, do I really want to do that in 
> the event they do get thru?  That could make their raising a little hell 
> just that much easier.

Only root can add a user to the admin group.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X



Re: eagle-lin64-7.5.0.run, won't

2016-01-19 Thread Lisi Reisz
On Tuesday 19 January 2016 09:59:23 Chris Bannister wrote:
> On Sun, Jan 17, 2016 at 05:19:34PM -0500, Gene Heskett wrote:
> > I hadn't thought of that.  My bad. OTOH, although no one has come thru
> > the router except to view my web page, do I really want to do that in
> > the event they do get thru?  That could make their raising a little hell
> > just that much easier.
>
> Only root can add a user to the admin group.

Can sudo not?  Gene has sudo.

Lisi



Re: eagle-lin64-7.5.0.run, won't

2016-01-19 Thread Darac Marjal

On Tue, Jan 19, 2016 at 11:38:11AM +, Lisi Reisz wrote:

On Tuesday 19 January 2016 09:59:23 Chris Bannister wrote:

On Sun, Jan 17, 2016 at 05:19:34PM -0500, Gene Heskett wrote:
> I hadn't thought of that.  My bad. OTOH, although no one has come thru
> the router except to view my web page, do I really want to do that in
> the event they do get thru?  That could make their raising a little hell
> just that much easier.

Only root can add a user to the admin group.


Can sudo not?  Gene has sudo.


sudo asks root to perform a task. There should be no difference between 
"sudo make me a sandwich" and "su ; make me a sandwich ; logoff" (except 
for certain things like sudo's environment sanitsation). Both should 
result in root making a sandwich for the user.




Lisi



--
For more information, please reread.


signature.asc
Description: PGP signature


Re: eagle-lin64-7.5.0.run, won't

2016-01-19 Thread Cindy-Sue Causey
On 1/19/16, Chris Bannister  wrote:
> On Sun, Jan 17, 2016 at 05:19:34PM -0500, Gene Heskett wrote:
>>
>> I hadn't thought of that.  My bad. OTOH, although no one has come thru
>> the router except to view my web page, do I really want to do that in
>> the event they do get thru?  That could make their raising a little hell
>> just that much easier.
>
> Only root can add a user to the admin group.


I couldn't find the words to bring together to answer him yesterday,
but I know what he's saying. In self-teaching myself how to
debootstrap where you set up EVERYTHING yourself, I had to read up a
little on adding groups. One warning floating around out there is that
we should add ourselves to the absolute barest minimum of groups
possible.

The reason? Every group that we add ourselves to, yes, conveniently
expands our privileges, but then, yes, woefully expands the access
privileges of anyone who might hack into our systems.

The alternative is battling what isn't working that is the reason
we're considering upping the number of groups for which our user(s)
is/are a member. The payoff is easier Debian'ing for the the folks who
come behind us

Is it sound or audio I've just seen bantered around a little? I'm not
member of that group, but I still get sound. My user is member of a
very limited number of groups. I just ran the command "groups" and
received back dialout, sudo, netdev, and its own ("elf").

Debian Wiki has a SystemGroups page with a few group descriptions:

https://wiki.debian.org/SystemGroups

Audio's description is: " This group can be used locally to give a set
of users access to an audio device (the soundcard or a microphone)."

Oh, man, you all may have just solved one of MY long term issues...
not being able to record via microphone. *smacking head and laughing
(out loud) *

PS The netdev one, had completely forgot about it. This thread gets a
second k/t for incidentally possibly solving something elsewhere
there, too.  If any of you all are part of the most recent threads
going on about networking failures, would you please consider asking
the original posters on those if their affected user is member of
netdev? Users like us being a member of netdev became almost a
necessity in recent times. Thank you! :)

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* words #fail me. *



Re: eagle-lin64-7.5.0.run, won't

2016-01-19 Thread Gene Heskett
On Tuesday 19 January 2016 07:54:30 Cindy-Sue Causey wrote:

> On 1/19/16, Chris Bannister  wrote:
> > On Sun, Jan 17, 2016 at 05:19:34PM -0500, Gene Heskett wrote:
> >> I hadn't thought of that.  My bad. OTOH, although no one has come
> >> thru the router except to view my web page, do I really want to do
> >> that in the event they do get thru?  That could make their raising
> >> a little hell just that much easier.
> >
> > Only root can add a user to the admin group.
>
> I couldn't find the words to bring together to answer him yesterday,
> but I know what he's saying. In self-teaching myself how to
> debootstrap where you set up EVERYTHING yourself, I had to read up a
> little on adding groups. One warning floating around out there is that
> we should add ourselves to the absolute barest minimum of groups
> possible.
>
> The reason? Every group that we add ourselves to, yes, conveniently
> expands our privileges, but then, yes, woefully expands the access
> privileges of anyone who might hack into our systems.
>
> The alternative is battling what isn't working that is the reason
> we're considering upping the number of groups for which our user(s)
> is/are a member. The payoff is easier Debian'ing for the the folks who
> come behind us
>
> Is it sound or audio I've just seen bantered around a little? I'm not
> member of that group, but I still get sound. My user is member of a
> very limited number of groups. I just ran the command "groups" and
> received back dialout, sudo, netdev, and its own ("elf").
>
> Debian Wiki has a SystemGroups page with a few group descriptions:
>
> https://wiki.debian.org/SystemGroups
>
> Audio's description is: " This group can be used locally to give a set
> of users access to an audio device (the soundcard or a microphone)."
>
> Oh, man, you all may have just solved one of MY long term issues...
> not being able to record via microphone. *smacking head and laughing
> (out loud) *
>
> PS The netdev one, had completely forgot about it. This thread gets a
> second k/t for incidentally possibly solving something elsewhere
> there, too.  If any of you all are part of the most recent threads
> going on about networking failures, would you please consider asking
> the original posters on those if their affected user is member of
> netdev? Users like us being a member of netdev became almost a
> necessity in recent times. Thank you! :)
>
> Cindy :)

Cindy is correct, I was amazed at how many I have made myself a member 
of, just so I could use the hardware and interfaces this machine 
posesses.  My attitude of course since I am the first and only human 
user of this machine, is that I bought and built it for ME to use.

When the udev people decides I can't be trusted to use  my floppy or 
cdrom, which is in fact a dvd writer, or reconfigure my network so it 
works because network-mangler can't, what other choice do I have but to 
make myself a member of that group?  Sure i can sudo and go fix it, but 
even fixed I can't use it.

It is after all, MY machine, and I built it to USE it, not fight with 
Greg and his ideas about security.  The last fix I had to do? Undo 
something that was changed in the last year, was to put, in rc.local a 
perms change to allow access to /dev/ttyUSB0, that was discovered at 
midnight 1/1/16 when heyu's crontab tried to upload the next years 
timeing settings to my CM11a that runs all my X10 stuffs here. The odd 
part of that was that I could still "heyu turn a14 off" without any 
access errors a couple days earlier.  Strangely, nut has had no similar 
problems accessing "myups" over /dev/ttyUSB1.

What is even more maddening is that the latest version of lsof is now no 
longer able to display that open and active path to /dev/ttyUSB0 until 
several minutes after the daemon heyu_relay had been started.  Now it 
shows up, but 10 seconds after I issued a command to heyu, it wasn't 
there. Now it is. Me, goes off shaking head, it doesn't grok. Even 
running lsof as root didn't show it.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-19 Thread Gene Heskett
On Tuesday 19 January 2016 08:00:12 Darac Marjal wrote:

> On Tue, Jan 19, 2016 at 11:38:11AM +, Lisi Reisz wrote:
> >On Tuesday 19 January 2016 09:59:23 Chris Bannister wrote:
> >> On Sun, Jan 17, 2016 at 05:19:34PM -0500, Gene Heskett wrote:
> >> > I hadn't thought of that.  My bad. OTOH, although no one has come
> >> > thru the router except to view my web page, do I really want to
> >> > do that in the event they do get thru?  That could make their
> >> > raising a little hell just that much easier.
> >>
> >> Only root can add a user to the admin group.
> >
> >Can sudo not?  Gene has sudo.
>
> sudo asks root to perform a task. There should be no difference
> between "sudo make me a sandwich" and "su ; make me a sandwich ;
> logoff" (except for certain things like sudo's environment
> sanitsation). Both should result in root making a sandwich for the
> user.
>
Where can I get one of those accessories?, it would come in handy lots of 
times. ;-)

> >Lisi


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-19 Thread Chris Bannister
On Tue, Jan 19, 2016 at 11:38:11AM +, Lisi Reisz wrote:
> On Tuesday 19 January 2016 09:59:23 Chris Bannister wrote:
> > On Sun, Jan 17, 2016 at 05:19:34PM -0500, Gene Heskett wrote:
> > > I hadn't thought of that.  My bad. OTOH, although no one has come thru
> > > the router except to view my web page, do I really want to do that in
> > > the event they do get thru?  That could make their raising a little hell
> > > just that much easier.
> >
> > Only root can add a user to the admin group.
> 
> Can sudo not?  Gene has sudo.

sure, that's effectively being root. My point is that anyone 'coming in'
via the router would have to get root privileges to change any settings,
and if they can do that then reading the logs is the least of your
worries. :)

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread Lisi Reisz
On Sunday 17 January 2016 22:19:34 Gene Heskett wrote:
> On Sunday 17 January 2016 09:14:33 Chris Bannister wrote:
> > I think you'll find the 'tail' command is in your path, in this
> > instance.
>
> tail is the program, not the argument.  The argument of course is the
> list of options between tail and the filename its supposed to look at.

If tail weren't the program it surely wouldn't be in your path??  It is 
executables that have to be in your path in order for them to be executed.

So in order for tail to be executed, you must either give the whole path to 
reach it, or it must be in your $PATH.

Lisi



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread Gene Heskett
On Sunday 17 January 2016 09:46:36 Joe wrote:

> On Sat, 16 Jan 2016 20:28:50 -0500
>
> Gene Heskett  wrote:
> > Bugs in the gcode exporter are my main beefs. In the gcode output
> > for bottom.ngc, with spot drilling enabled, it outputs a line for
> > each of the holes, but fills the first 6 of those lines with X0 Y0,
> > so it pecks at the lower right corner 6 times, and then spots the
> > rest of the holes just fine.
>
> I see, you're probably in a small minority, so more likelihood of
> finding bugs. I've only ever produced Gerber files to send away to PCB
> production houses, which I think is what nearly all users do.
>
> > But this is stuff I should take to the geda-user list, which I just
> > sent a sub message to join. I do not for a millisecond, think this
> > is a debian problem.
>
> Yes, they are very active and will usually have a quick turnround.
> I've had some minor issues which were sorted out by direct email with
> developers.

I method I don't 100% care for, Joe, because such messages never get into 
the list archives.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread Lisi Reisz
On Sunday 17 January 2016 22:21:38 Gene Heskett wrote:
> On Sunday 17 January 2016 09:46:36 Joe wrote:
> > On Sat, 16 Jan 2016 20:28:50 -0500
> >
> > Gene Heskett  wrote:
> > > Bugs in the gcode exporter are my main beefs. In the gcode output
> > > for bottom.ngc, with spot drilling enabled, it outputs a line for
> > > each of the holes, but fills the first 6 of those lines with X0 Y0,
> > > so it pecks at the lower right corner 6 times, and then spots the
> > > rest of the holes just fine.
> >
> > I see, you're probably in a small minority, so more likelihood of
> > finding bugs. I've only ever produced Gerber files to send away to PCB
> > production houses, which I think is what nearly all users do.
> >
> > > But this is stuff I should take to the geda-user list, which I just
> > > sent a sub message to join. I do not for a millisecond, think this
> > > is a debian problem.
> >
> > Yes, they are very active and will usually have a quick turnround.
> > I've had some minor issues which were sorted out by direct email with
> > developers.
>
> I method I don't 100% care for, Joe, because such messages never get into
> the list archives.

Why do they need to be in the list archives?  Getting them in the list 
archives doesn't solve the problem if there is a bug.  And once the bug is 
patched, they don't need to be in the archives.

Lisi



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread Gene Heskett
On Sunday 17 January 2016 09:14:33 Chris Bannister wrote:

> On Sat, Jan 16, 2016 at 12:28:32PM -0500, Gene Heskett wrote:
> > On Saturday 16 January 2016 10:57:55 Curt wrote:
> > > On 2016-01-16, Gene Heskett  wrote:
> > > >> So its full path is /home/gene/eagle-7.5.0/bin/eagle, not
> > > >> /bin/eagle?
> > > >>
> > > >> Lisi
> > > >
> > > > I was cd'd to /home/gene/eagle-7.5.0 and the command issued was
> > > > bin/eagle, which is perfectly legal syntax.
> > >
> > > Not if bin is not in your path it isn't.
> >
> > Oh?  Since when?  Neither is /home/gene/log, but I use that
> > regularly in several scrips and from the command line since I have a
> > user=me "tail -fn100 log/fetchmail.log" running in a console tab
> > right
>
> I think you'll find the 'tail' command is in your path, in this
> instance.

tail is the program, not the argument.  The argument of course is the 
list of options between tail and the filename its supposed to look at.
>
> > now.  I long ago got sick and tired of fighting with permissions on
> > stuff in  /var/log that I ought to be able to read.
>
> That's debatable, e.g. if I was sys admin of a multiuser system I
> wouldn't any Tom Dick or Harry perusing the logs.
>
> If you want to to query the logs get root to add you to the 'admin'
> group.

I hadn't thought of that.  My bad. OTOH, although no one has come thru 
the router except to view my web page, do I really want to do that in 
the event they do get thru?  That could make their raising a little hell 
just that much easier.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 16, 2016 at 09:45:58AM -0700, Brandon Vincent wrote:
> On Sat, Jan 16, 2016 at 9:42 AM, Curt  wrote:
> > Thank you for your time. Just another misapprehension I've been laboring
> > under these many years.
> 
> I actually linked to the wrong article. I've never been able to find
> actual Bash documentation that states this.
> 
> It just has always worked.

It's just there in the manual (referring to info bash):

  3.7.2 Command Search and Execution
  --
  
  After a command has been split into words, if it results in a simple
  command and an optional list of arguments, the following actions are
  taken.
  
1. If the command name contains no slashes, the shell attempts to
   locate it.  If there exists a shell function by that name, that
   function is invoked as described in *note Shell Functions::.
  
2. If the name does not match a function, the shell searches for it in
   the list of shell builtins.  If a match is found, that builtin is
   invoked.
  
3. If the name is neither a shell function nor a builtin, and contains
   no slashes, Bash searches each element of '$PATH' for a directory
   containing an executable file by that name.  Bash uses a hash table
   to remember the full pathnames of executable files to avoid
   multiple 'PATH' searches (see the description of 'hash' in *note
   Bourne Shell Builtins::).  A full search of the directories in
   '$PATH' is performed only if the command is not found in the hash
   table.  If the search is unsuccessful, the shell searches for a
   defined shell function named 'command_not_found_handle'.  If that
   function exists, it is invoked with the original command and the
   original command's arguments as its arguments, and the function's
   exit status becomes the exit status of the shell.  If that function
   is not defined, the shell prints an error message and returns an
   exit status of 127.
   [...]

That means that all the "special handling" (i.e. looking up a shell
function, going through $PATH, etc.) only happens when the command
contains no slashes. It's only for those cases where you'd need a
"." in $PATH if you want commands in the current directory executed
right away, a custom which is discouraged, because it's too easily
a vector for exploits[1] (it used to be standard behaviour under DOS,
which was one of the surprises for DOS migrants).

If you call the "local" command ./foo, then it contains slashes, so
special behaviour doesn't apply.

- - - - - - - - - - - - - - - - -
[1] Eve puts an executable shell script under /tmp named `ls',
containing the line "rm -Rf $HOME/". Alice does:

  cd /tmp
  ls

and is henceforth homeless.

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlabiJgACgkQBcgs9XrR2kYe1gCdHPlM549sUht/gGW6R87YYE6S
+TMAnAshVl3y6mGei4RHesn1UrQeX1e5
=72Wo
-END PGP SIGNATURE-



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread tomas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 16, 2016 at 10:42:25PM +, Lisi Reisz wrote:
> On Saturday 16 January 2016 17:28:32 Gene Heskett wrote:
> > somebody forgot to tell my mostly wheezy system.
> [snip]
> > this system with many years of cruft accumulated.
> 
> And it doesn't run like an entirely Wheezy system with no cruft.  Now there's 
> a surprise!

If by "cruft" you mean "user customizations"... then I *love* my cruft.
That's why I use free systems, after all. I don't want just a theoretical
Right to Tinker, I actually do -- the horrors ;-)

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlabiiQACgkQBcgs9XrR2kbqSACdFyMR1vXX5H7mNG7O09OiI9Xv
8ksAn35QXCAkDi649BdIuxQkMuvaWp/i
=AdTt
-END PGP SIGNATURE-



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread Lisi Reisz
On Sunday 17 January 2016 12:33:40 to...@tuxteam.de wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Jan 16, 2016 at 10:42:25PM +, Lisi Reisz wrote:
> > On Saturday 16 January 2016 17:28:32 Gene Heskett wrote:
> > > somebody forgot to tell my mostly wheezy system.
> >
> > [snip]
> >
> > > this system with many years of cruft accumulated.
> >
> > And it doesn't run like an entirely Wheezy system with no cruft.  Now
> > there's a surprise!
>
> If by "cruft" you mean "user customizations"... then I *love* my cruft.
> That's why I use free systems, after all. I don't want just a theoretical
> Right to Tinker, I actually do -- the horrors ;-)

Of course!!!  But do you then complain that it does not behave how the vanilla 
installation is supposed to, and the vanilla installation has a bug.  Surely 
its behaving differently is the whole point!! :-)

Lisi



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread Chris Bannister
On Sat, Jan 16, 2016 at 12:28:32PM -0500, Gene Heskett wrote:
> On Saturday 16 January 2016 10:57:55 Curt wrote:
> 
> > On 2016-01-16, Gene Heskett  wrote:
> > >> So its full path is /home/gene/eagle-7.5.0/bin/eagle, not
> > >> /bin/eagle?
> > >>
> > >> Lisi
> > >
> > > I was cd'd to /home/gene/eagle-7.5.0 and the command issued was
> > > bin/eagle, which is perfectly legal syntax.
> >
> > Not if bin is not in your path it isn't.
> 
> Oh?  Since when?  Neither is /home/gene/log, but I use that regularly in 
> several scrips and from the command line since I have a 
> user=me "tail -fn100 log/fetchmail.log" running in a console tab right 

I think you'll find the 'tail' command is in your path, in this
instance. 

> now.  I long ago got sick and tired of fighting with permissions on 
> stuff in  /var/log that I ought to be able to read.

That's debatable, e.g. if I was sys admin of a multiuser system I
wouldn't any Tom Dick or Harry perusing the logs.

If you want to to query the logs get root to add you to the 'admin'
group. 

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X



Re: eagle-lin64-7.5.0.run, won't

2016-01-17 Thread Joe
On Sat, 16 Jan 2016 20:28:50 -0500
Gene Heskett  wrote:


> >  
> Bugs in the gcode exporter are my main beefs. In the gcode output for 
> bottom.ngc, with spot drilling enabled, it outputs a line for each of 
> the holes, but fills the first 6 of those lines with X0 Y0, so it
> pecks at the lower right corner 6 times, and then spots the rest of
> the holes just fine.
> 
I see, you're probably in a small minority, so more likelihood of
finding bugs. I've only ever produced Gerber files to send away to PCB
production houses, which I think is what nearly all users do.

> 
> But this is stuff I should take to the geda-user list, which I just
> sent a sub message to join. I do not for a millisecond, think this is
> a debian problem.
> 
Yes, they are very active and will usually have a quick turnround. I've
had some minor issues which were sorted out by direct email with
developers.

-- 
Joe



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Lisi Reisz
On Saturday 16 January 2016 06:06:48 Gene Heskett wrote:
> > > shows in that shells env report, but it can't find its executable
> > > with both hands, prefering to give me a
> > > gene@coyote:~/eagle-7.5.0$ bin/eagle
> > > bash: bin/eagle: No such file or directory
> > >
> > > Clues? I'm confused enough without this.
> >
> > You could try and use the find command to see where it actually is.
> > I use a locate variant e.g.
>
> Whats the matter with "ls -laR", its right there where I said it was.  
> Even has exec perms.

So its full path is /home/gene/eagle-7.5.0/bin/eagle, not /bin/eagle?

Lisi



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Brandon Vincent
On Sat, Jan 16, 2016 at 3:49 AM, Gene Heskett  wrote:
> I was cd'd to /home/gene/eagle-7.5.0 and the command issued was
> bin/eagle, which is perfectly legal syntax.

Gene,

Could you post the output of ldd /home/gene/eagle-7.5.0 for us to see?

Brandon Vincent



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Gene Heskett
On Saturday 16 January 2016 05:05:22 Lisi Reisz wrote:

> On Saturday 16 January 2016 06:06:48 Gene Heskett wrote:
> > > > shows in that shells env report, but it can't find its
> > > > executable with both hands, prefering to give me a
> > > > gene@coyote:~/eagle-7.5.0$ bin/eagle
> > > > bash: bin/eagle: No such file or directory
> > > >
> > > > Clues? I'm confused enough without this.
> > >
> > > You could try and use the find command to see where it actually
> > > is. I use a locate variant e.g.
> >
> > Whats the matter with "ls -laR", its right there where I said it
> > was.   Even has exec perms.
>
> So its full path is /home/gene/eagle-7.5.0/bin/eagle, not /bin/eagle?
>
> Lisi

I was cd'd to /home/gene/eagle-7.5.0 and the command issued was 
bin/eagle, which is perfectly legal syntax.

FWIW, I even tried the full path, same error.  And I could cd into bin 
and eagle was visible in an ls listing, but wasn't found by an ./eagle

But eagle has always been selective about how it runs on linux.
I poked around on the cadsoft site but could not find a link to their 
forum, so I couldn't ask them.  Which is crazy because I am getting an 
email from the forum sw for every post.  But you can't post via email.

Just one of the many reasons I don't like forums.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Gene Heskett
On Saturday 16 January 2016 19:41:45 Joe wrote:

> On Sat, 16 Jan 2016 12:13:14 -0500
>
> Gene Heskett  wrote:
> > But as I said in a PM, its moot, gEDA has come to the rescue.
> >
> > Now, if ALL the gEDA suite was brought up to date, the repo versions
> > are positively ancient, I think it would have been easier. I was
> > able to build the latest pcb, V-1.99z, but dependency hell ate any
> > attempts to build the newer schematic capture front ends.  So I had
> > to resort to a hand edit occasionally with a text editor.
>
> What features of the latest and greatest do you need? I haven't used
> anything in 20140316 that wasn't in 20110918, and I don't recall any
> significant bugs then. This:
>
> http://www.jre-systems.co.uk/pcbs/images/RCP-1.png
> http://minibroadcastcameras.co.uk/oem/images/slideshow/Panel52-top.png
>
> was created in late 2007, with whatever version was current at the
> time. To be fair, I didn't use schematic capture then, I didn't have a
> schematic for this board until after I made it, and to this day the
> schematic is hand-drawn in pencil...
>
> I have used schematic capture (gschem and gsch2pcb) for everything
> since 2007, with no significant problems. I've used whatever version
> was current in sid.
>
Bugs in the gcode exporter are my main beefs. In the gcode output for 
bottom.ngc, with spot drilling enabled, it outputs a line for each of 
the holes, but fills the first 6 of those lines with X0 Y0, so it pecks 
at the lower right corner 6 times, and then spots the rest of the holes 
just fine.

Then, in the mill/drill file, it ignored the request for inches, outputs 
mm's, including the command that puts the LCNC interpretor into the mm's 
mode. But then when I check the file times, it was not even regenerated 
that last time I exported the gcode.  So theres 4 bugs, the 4th one 
being that the gcode exporter fills everything in the boxes for its data 
translations, in with what I have to assume is mm data for everything 
that ought to be inches.

But this is stuff I should take to the geda-user list, which I just sent 
a sub message to join. I do not for a millisecond, think this is a 
debian problem.

> The autorouter has probably improved, but if you're doing anything
> with power, you won't want to autoroute anyway. I pretty well only use
> two-layer boards, and the last time I tried the autorouter, I could
> barely see the tracks for vias. The earlier versions couldn't do a
> photo-realistic rendering of the board, but that's only a bit of icing
> on the cake, not a show-stopper.

I clicked on it, several times after I had arranged things by hand, and 
it never did a thing except waste 1.5 seconds spinning its wheels.

Now, to put this almost back on topic, the first $80 bytes of the 
bin/eagle file are:  Humm, so much for that, khexedit will not do a 
mouse copy/paste.  Luverly.  Anyway it does say ELF in the first 5 or 6 
bytes. Looks like a linux ext-something file to me.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Gene Heskett
On Saturday 16 January 2016 17:42:25 Lisi Reisz wrote:

> On Saturday 16 January 2016 17:28:32 Gene Heskett wrote:
> > somebody forgot to tell my mostly wheezy system.
>
> [snip]
>
> > this system with many years of cruft accumulated.
>
> And it doesn't run like an entirely Wheezy system with no cruft.  Now
> there's a surprise!
>
> Lisi

1. No, it doesn't, thanks to some of that bash script cruft I've written 
because I'm lazy, so its about 10x as automatic for all the stuff I do 
as a default install would be.  For me, thats a huge labor saver.

2. The prime directive is that it IS capable of running LinuxCNC, and 
that limits my kernel choices, particularly if running real machinery, 
which must have 1 millisecond response times with the I/O card I am 
using.  Without it, I'd be driving the steppers in software, at about 
1/3rd their maximum speed, which requires less than 10 microseconds of 
jitter in the timing.

So lets put that horse back in the barn with a nose bag of quality oats 
for desert.  When the LCNC crew releases a new iso, probably sometime 
after April, the other 3 machines will probably be re-installed from the 
new iso, and once amanda is installed, I can recover all the data they 
need in 15 minutes per machine  In the meantime, I am running what I 
brung to this party on this machine.

FWIW I just reinstalled apt and all its kinfolks, no change, so I 
installed adept, which didn't work, stuck in refresh forever, except it 
wasn't, the file menu was still active, but several attempts to manage 
the repos were ignored, and when I gave it up and click on quit, I got a 
crash report so I filed it.

And apt-check, except for adept, throws that spam in the messages log 
when any of the other package managers runs it. I doesn't appear to be 
effecting things, and I haven't a clue where to look after coming up dry 
except for the apt file in /etc/cron.daily.

Cheers Lisi, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread David Wright
On Sat 16 Jan 2016 at 12:28:32 (-0500), Gene Heskett wrote:
> On Saturday 16 January 2016 10:57:55 Curt wrote:
> 
> > On 2016-01-16, Gene Heskett  wrote:
> > >> So its full path is /home/gene/eagle-7.5.0/bin/eagle, not
> > >> /bin/eagle?
> > >>
> > >> Lisi
> > >
> > > I was cd'd to /home/gene/eagle-7.5.0 and the command issued was
> > > bin/eagle, which is perfectly legal syntax.
> >
> > Not if bin is not in your path it isn't.
> 
> Oh?  Since when?  Neither is /home/gene/log, but I use that regularly in 
> several scrips and from the command line since I have a 
> user=me "tail -fn100 log/fetchmail.log" running in a console tab right 
> now.

No syntax problems here. And I wouldn't quarrel with
tail -fn100 log/fetchmail.log
in a script either. However, I don't think it wise to write anything like
bin/eagle
into a script. That could accidentally run bin/eagle from whichever
directory you (or the script) happen to find yourself in.

Cheers,
David.



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Curt
On 2016-01-16, Brandon Vincent  wrote:
> On Sat, Jan 16, 2016 at 9:14 AM, Curt  wrote:
>> I don't see what you're referring to in there.
>
> Eagle installs itself into your home directory under a folder called
> "eagle-7.5.0". Inside this folder is the "bin" folder in which the
> Eagle executable is stored. If you are in the ~/eagle-7.5.0 directory,
> typing "bin/eagle" should launch Eagle. Bash will launch an executable
> with only a relative path. It's only when you specify no path, that ./
> becomes necessary (assuming a normal $PATH).

Thank you for your time. Just another misapprehension I've been laboring
under these many years. 

> Brandon Vincent
>
>


-- 




Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Curt
On 2016-01-16, Brandon Vincent  wrote:
> On Sat, Jan 16, 2016 at 8:57 AM, Curt  wrote:
>> Not if bin is not in your path it isn't.
>
> You should probably read [1].
>
> It is legal syntax.

> [1] http://mywiki.wooledge.org/BashFAQ/028

I don't see what you're referring to in there.

> Brandon Vincent
>
>


-- 




Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Brandon Vincent
On Sat, Jan 16, 2016 at 8:57 AM, Curt  wrote:
> Not if bin is not in your path it isn't.

You should probably read [1].

It is legal syntax.

[1] http://mywiki.wooledge.org/BashFAQ/028

Brandon Vincent



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Brandon Vincent
On Sat, Jan 16, 2016 at 9:14 AM, Curt  wrote:
> I don't see what you're referring to in there.

Eagle installs itself into your home directory under a folder called
"eagle-7.5.0". Inside this folder is the "bin" folder in which the
Eagle executable is stored. If you are in the ~/eagle-7.5.0 directory,
typing "bin/eagle" should launch Eagle. Bash will launch an executable
with only a relative path. It's only when you specify no path, that ./
becomes necessary (assuming a normal $PATH).

Brandon Vincent



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Lisi Reisz
On Saturday 16 January 2016 17:28:32 Gene Heskett wrote:
> somebody forgot to tell my mostly wheezy system.
[snip]
> this system with many years of cruft accumulated.

And it doesn't run like an entirely Wheezy system with no cruft.  Now there's 
a surprise!

Lisi



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Joe
On Sat, 16 Jan 2016 12:13:14 -0500
Gene Heskett  wrote:


> 
> But as I said in a PM, its moot, gEDA has come to the rescue.
> 
> Now, if ALL the gEDA suite was brought up to date, the repo versions
> are positively ancient, I think it would have been easier. I was able
> to build the latest pcb, V-1.99z, but dependency hell ate any
> attempts to build the newer schematic capture front ends.  So I had
> to resort to a hand edit occasionally with a text editor.
> 

What features of the latest and greatest do you need? I haven't used
anything in 20140316 that wasn't in 20110918, and I don't recall any
significant bugs then. This:

http://www.jre-systems.co.uk/pcbs/images/RCP-1.png
http://minibroadcastcameras.co.uk/oem/images/slideshow/Panel52-top.png

was created in late 2007, with whatever version was current at the time.
To be fair, I didn't use schematic capture then, I didn't have a
schematic for this board until after I made it, and to this day the
schematic is hand-drawn in pencil...

I have used schematic capture (gschem and gsch2pcb) for everything
since 2007, with no significant problems. I've used whatever version
was current in sid.

The autorouter has probably improved, but if you're doing anything with
power, you won't want to autoroute anyway. I pretty well only use
two-layer boards, and the last time I tried the autorouter, I could
barely see the tracks for vias. The earlier versions couldn't do a
photo-realistic rendering of the board, but that's only a bit of icing
on the cake, not a show-stopper.

-- 
Joe



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Lisi Reisz
On Sunday 17 January 2016 01:11:04 Gene Heskett wrote:
> FWIW I just reinstalled apt and all its kinfolks, no change, so I
> installed adept, which didn't work, stuck in refresh forever, except it
> wasn't, the file menu was still active, but several attempts to manage
> the repos were ignored, and when I gave it up and click on quit, I got a
> crash report so I filed it.
>
> And apt-check, except for adept, throws that spam in the messages log
> when any of the other package managers runs it. I doesn't appear to be
> effecting things, and I haven't a clue where to look after coming up dry
> except for the apt file in /etc/cron.daily.

I tried really hard to understand what you were trying to do and how you were 
trying to do it, with a view to trying to help.  I failed miserably.  Why are 
you re-installing "apt and all its kinfolks", and what are "all its 
kinfolks"?

I understand that you are running what you are running for a reason.  But you 
keep pretending that it ought to run smoothly like a nice new vanilla system.  
Of course it won't.  And it is the fault of neither Debian nor TDE that you 
have special needs.  Oh, there is no reason why you shouldn't ask for those 
needs to be met, but you cannot call things broken, if either you don't like 
them, or they don't like your very idiosyncratic system.

Lisi



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Gene Heskett
On Saturday 16 January 2016 22:22:34 David Wright wrote:

> On Sat 16 Jan 2016 at 12:28:32 (-0500), Gene Heskett wrote:
> > On Saturday 16 January 2016 10:57:55 Curt wrote:
> > > On 2016-01-16, Gene Heskett  wrote:
> > > >> So its full path is /home/gene/eagle-7.5.0/bin/eagle, not
> > > >> /bin/eagle?
> > > >>
> > > >> Lisi
> > > >
> > > > I was cd'd to /home/gene/eagle-7.5.0 and the command issued was
> > > > bin/eagle, which is perfectly legal syntax.
> > >
> > > Not if bin is not in your path it isn't.
> >
> > Oh?  Since when?  Neither is /home/gene/log, but I use that
> > regularly in several scrips and from the command line since I have a
> > user=me "tail -fn100 log/fetchmail.log" running in a console tab
> > right now.
>
> No syntax problems here. And I wouldn't quarrel with
> tail -fn100 log/fetchmail.log
> in a script either. However, I don't think it wise to write anything
> like bin/eagle
> into a script. That could accidentally run bin/eagle from whichever
> directory you (or the script) happen to find yourself in.
>
> Cheers,
> David.

Can we put this to rest?  If eagle wants to play persnickity, there ARE 
other fish in the pond that can do the job, I just have to learn how to 
use them.

And I am making progress, I finally convinced gEDA/pcb to spot drill the 
15 holes for the 6 parts and 3 outside world connections.  Now its up to 
me to get rid of about 8.5" between the machines home Z position, rotate 
the generated pattern 90 degrees to "stand it on end" and then step & 
repeat to make 6 of them per pass on my mill. I already invented that 
wheel tonight, but didn't discover the code was defective until I had 
wasted 2.5" off the end of a sheet of 2oz copper clad, double-sided 
fiberglass material. NBD, I have more, as long as each iteration is 
better than the last. A nice sharp carbide blade on my table saw gets 
rid of the mistakes. ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Curt
On 2016-01-16, Gene Heskett  wrote:
>>
>> So its full path is /home/gene/eagle-7.5.0/bin/eagle, not /bin/eagle?
>>
>> Lisi
>
> I was cd'd to /home/gene/eagle-7.5.0 and the command issued was 
> bin/eagle, which is perfectly legal syntax.

Not if bin is not in your path it isn't.

Otherwise, the message from bash is:

bash: eagle: command not found

not

bash: /bin/eagle: No such file or directory

> FWIW, I even tried the full path, same error.  And I could cd into bin 
> and eagle was visible in an ls listing, but wasn't found by an ./eagle



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Brandon Vincent
On Sat, Jan 16, 2016 at 9:42 AM, Curt  wrote:
> Thank you for your time. Just another misapprehension I've been laboring
> under these many years.

I actually linked to the wrong article. I've never been able to find
actual Bash documentation that states this.

It just has always worked.

Brandon Vincent



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Gene Heskett
On Saturday 16 January 2016 08:06:25 Brandon Vincent wrote:

> On Sat, Jan 16, 2016 at 3:49 AM, Gene Heskett  
wrote:
> > I was cd'd to /home/gene/eagle-7.5.0 and the command issued was
> > bin/eagle, which is perfectly legal syntax.
>
> Gene,
>
> Could you post the output of ldd /home/gene/eagle-7.5.0 for us to see?
>
> Brandon Vincent

gene@coyote:~/eagle-7.5.0$ ldd /home/gene/eagle-7.5.0/
ldd: /home/gene/eagle-7.5.0/: not regular file
gene@coyote:~/eagle-7.5.0$ ldd /home/gene/eagle-7.5.0/bin
ldd: /home/gene/eagle-7.5.0/bin: not regular file
gene@coyote:~/eagle-7.5.0$ ldd /home/gene/eagle-7.5.0/bin/eagle
not a dynamic executable

But as I said in a PM, its moot, gEDA has come to the rescue.

Now, if ALL the gEDA suite was brought up to date, the repo versions are 
positively ancient, I think it would have been easier. I was able to 
build the latest pcb, V-1.99z, but dependency hell ate any attempts to 
build the newer schematic capture front ends.  So I had to resort to a 
hand edit occasionally with a text editor.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Gene Heskett
On Saturday 16 January 2016 10:57:55 Curt wrote:

> On 2016-01-16, Gene Heskett  wrote:
> >> So its full path is /home/gene/eagle-7.5.0/bin/eagle, not
> >> /bin/eagle?
> >>
> >> Lisi
> >
> > I was cd'd to /home/gene/eagle-7.5.0 and the command issued was
> > bin/eagle, which is perfectly legal syntax.
>
> Not if bin is not in your path it isn't.

Oh?  Since when?  Neither is /home/gene/log, but I use that regularly in 
several scrips and from the command line since I have a 
user=me "tail -fn100 log/fetchmail.log" running in a console tab right 
now.  I long ago got sick and tired of fighting with permissions on 
stuff in  /var/log that I ought to be able to read, and moved stuff that 
belongs to me to /home/gene/log, including in the logrotate scripts.

If that syntax is now broken, somebody forgot to tell my mostly wheezy 
system.

> Otherwise, the message from bash is:
>
> bash: eagle: command not found
>
> not
>
> bash: /bin/eagle: No such file or directory
>
> > FWIW, I even tried the full path, same error.  And I could cd into
> > bin and eagle was visible in an ls listing, but wasn't found by an
> > ./eagle

FWIW, I do have /home/gene/bin in my $PATH, and there is no difference in 
how the stuff in gene/bin runs. I put it early in the path so I could 
override what may be in more conventional paths on this system with many 
years of cruft accumulated. But now I can type "mailwatcher 2>&1 
>/dev/null &" or "bin/mailwatcher 2>&1 >/dev/null &" and either works.

I had a heck of a time getting it unpacked, similar problems. If eagle 
wants to be a cast iron bitch about who can run their stuff, it IS 
eagles problem now, I  have enough of gEDA running to get the job done.

Thanks Curt.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-16 Thread Gene Heskett
On Saturday 16 January 2016 11:45:58 Brandon Vincent wrote:

> On Sat, Jan 16, 2016 at 9:42 AM, Curt  wrote:
> > Thank you for your time. Just another misapprehension I've been
> > laboring under these many years.
>
> I actually linked to the wrong article. I've never been able to find
> actual Bash documentation that states this.
>
> It just has always worked.
>
> Brandon Vincent

Legal since at least RH5.0 in late 1997.  Thats when I built my first 
linux box.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-15 Thread Gene Heskett
On Friday 15 January 2016 23:35:53 Chris Bannister wrote:

> On Thu, Jan 14, 2016 at 06:37:49PM -0500, Gene Heskett wrote:
> > Greetings all;
> >
> > Since the gEDA kit in the repo's seems to be rather broken, I
> > thought I'd give eagle another chance, so I downloaded, from the
> > cadsoft site, the latest 64 bit linux installer, but can't find a
> > help file, and obviously I am not training my monkeys correctly.
> >
> > Has anyone else had any luck, running it after convincing the
> > installer where you wanted it installed?
> >
> > I have cd'd to its base directory, and exported EAGLEDIR=`pwd' so it
>
>   ^^
> Is that verbatim? I'd put an actual absolute path there. The second
> 'tic' is not a backtick.
>
Probably a typu Chris.  Ancient fingers & all that. It does show 
correctly in an env query.

> Do backsticks actually work in this case?

Sure!

> > shows in that shells env report, but it can't find its executable
> > with both hands, prefering to give me a
> > gene@coyote:~/eagle-7.5.0$ bin/eagle
> > bash: bin/eagle: No such file or directory
> >
> > Clues? I'm confused enough without this.
>
> You could try and use the find command to see where it actually is.
> I use a locate variant e.g.

Whats the matter with "ls -laR", its right there where I said it was.  
Even has exec perms.

> # apt-cache show mlocate

Point being, I gave up on eagle.  gEDA to the rescue, and I already have 
some very nearly working gcode from gEDA/pcb. Some fine tuning to do 
like 10x bigger solder pads for the outside world connections, and 
potentially about a 50% shrink as I want to make several of these by 
step & repeat. I need 3 instantly, and there may be a potential market 
for a few.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-15 Thread Chris Bannister
On Thu, Jan 14, 2016 at 06:37:49PM -0500, Gene Heskett wrote:
> Greetings all;
> 
> Since the gEDA kit in the repo's seems to be rather broken, I thought I'd 
> give eagle another chance, so I downloaded, from the cadsoft site, the 
> latest 64 bit linux installer, but can't find a help file, and obviously 
> I am not training my monkeys correctly.
> 
> Has anyone else had any luck, running it after convincing the installer 
> where you wanted it installed?
> 
> I have cd'd to its base directory, and exported EAGLEDIR=`pwd' so it 
  ^^
Is that verbatim? I'd put an actual absolute path there. The second
'tic' is not a backtick.

Do backsticks actually work in this case?

> shows in that shells env report, but it can't find its executable with 
> both hands, prefering to give me a 
> gene@coyote:~/eagle-7.5.0$ bin/eagle
> bash: bin/eagle: No such file or directory
> 
> Clues? I'm confused enough without this.

You could try and use the find command to see where it actually is.
I use a locate variant e.g.

# apt-cache show mlocate

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X



Re: eagle-lin64-7.5.0.run, won't

2016-01-14 Thread Gene Heskett
On Thursday 14 January 2016 19:38:34 Brandon Vincent wrote:

> On Thu, Jan 14, 2016 at 4:37 PM, Gene Heskett  
wrote:
> > Has anyone else had any luck, running it after convincing the
> > installer where you wanted it installed?
>
> I just tried installing Eagle manually and had no problems on a clean
> install of Debian 8.
>
> Is your Debian install 64-bit? What is the output of uname(1)?
>
> Brandon Vincent
ATM,
gene@coyote:~/gaf/charge-pump-bucket$ uname -a
Linux coyote 3.16.0-0.bpo.4-amd64 #1 SMP Debian 
3.16.7-ckt20-1+deb8u2~bpo70+1 (2016-01-03) x86_64 GNU/Linux

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-14 Thread Brandon Vincent
On Thu, Jan 14, 2016 at 4:37 PM, Gene Heskett  wrote:
> Has anyone else had any luck, running it after convincing the installer
> where you wanted it installed?

I just tried installing Eagle manually and had no problems on a clean
install of Debian 8.

Is your Debian install 64-bit? What is the output of uname(1)?

Brandon Vincent



eagle-lin64-7.5.0.run, won't

2016-01-14 Thread Gene Heskett
Greetings all;

Since the gEDA kit in the repo's seems to be rather broken, I thought I'd 
give eagle another chance, so I downloaded, from the cadsoft site, the 
latest 64 bit linux installer, but can't find a help file, and obviously 
I am not training my monkeys correctly.

Has anyone else had any luck, running it after convincing the installer 
where you wanted it installed?

I have cd'd to its base directory, and exported EAGLEDIR=`pwd' so it 
shows in that shells env report, but it can't find its executable with 
both hands, prefering to give me a 
gene@coyote:~/eagle-7.5.0$ bin/eagle
bash: bin/eagle: No such file or directory

Clues? I'm confused enough without this.

Thanks folks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-14 Thread Gene Heskett
On Friday 15 January 2016 00:06:51 Anders Andersson wrote:

> On Fri, Jan 15, 2016 at 12:37 AM, Gene Heskett  
wrote:
> > Since the gEDA kit in the repo's seems to be rather broken, I
> > thought I'd give eagle another chance
>
> While I had no problems using Eagle on 64-bit Debian, I did not like
> running closed software. A couple of months ago I switched to KiCad,
> and I do not regret it. Some things are not as polished, but some
> things are much better. There are things that are pretty bad, but a
> huge benefit is that all developers acknowledge this, and are actively
> working on improving whatever is bad, instead of the common "no, we
> like it the way it is" mindset. Not to mention that CERN is devoting
> resources to it.
>
> The package available in Debian 8 is somewhat old because they just
> recently released a new stable version after many years of
> development. Personally I build it from the "bleeding edge" sources.
> The website is http://kicad-pcb.org/ and instructions for downloading
> and building should be available on the website.

Thats great news. I may see about doing that after I get back from a 
sawbones appointment tomorrow.

The issued version for wheezy just doesn't have it, too small a parts 
library but I do think the promise is there with sufficient TLC.

I threw this 6 part schematic together in repo version of gschem tonight, 
but when I went to process it for pcb processing, it turned out that 4 
of the 6 parts from the part library I used, had no footprint data, and 
I've not grokked how to add those attributes to the .sch file yet.  Info 
seems hard to come by, so I've subbed to their list in hopes I can make 
sense of the problem and state it clearly enough to elicit some 
help/advice on how to do that.

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: eagle-lin64-7.5.0.run, won't

2016-01-14 Thread Anders Andersson
On Fri, Jan 15, 2016 at 12:37 AM, Gene Heskett  wrote:
> Since the gEDA kit in the repo's seems to be rather broken, I thought I'd
> give eagle another chance

While I had no problems using Eagle on 64-bit Debian, I did not like
running closed software. A couple of months ago I switched to KiCad,
and I do not regret it. Some things are not as polished, but some
things are much better. There are things that are pretty bad, but a
huge benefit is that all developers acknowledge this, and are actively
working on improving whatever is bad, instead of the common "no, we
like it the way it is" mindset. Not to mention that CERN is devoting
resources to it.

The package available in Debian 8 is somewhat old because they just
recently released a new stable version after many years of
development. Personally I build it from the "bleeding edge" sources.
The website is http://kicad-pcb.org/ and instructions for downloading
and building should be available on the website.