Re: [Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Adam Wolf 
A good one!  But alas, we have them drag and drop a kicad/ directory onto a
symlink to /Library/Application\ Support/, and it does a popup asking for
admin privileges.  (We also have this in the README right there when you
install).

It's certainly got me puzzled!

On Thu, Dec 3, 2015 at 2:16 PM, Bob Gustafson  wrote:

> Maybe it is a 'first time use problem' - maybe no kicad directory in the
> /Library/Application Support/. It may require a privilege password to add
> this directory the first time.
>
> A thought anyway.
>
> Bob G
>
>
> On 12/03/2015 02:08 PM, Adam Wolf wrote:
>
> Hi folks!
>
> A user is having a problem with the latest OS X RC2 release, and I haven't
> been able to figure it out.
>
> Quick background:
>
> There is a KiCad package, and a KiCad Extras package.  The KiCad Extras
> package has a modules/ directory in it, and it has all the footprints.
> It's for offline use.  It also has an fp-table-lib, which uses KISYSMOD to
> point at the modules, like this:
>
>   (lib (name Capacitors_SMD)(type KiCad)(uri
> ${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like
> them."))
>
> My builds have DEFAULT_INSTALL_PATH set to /Library/Application
> Support/kicad, like I want them to.  I checked the build output, and it
> shows:
>
> -- Kicad install dir: 
>
> Great, awesome, exactly like I want it.
>
> On the other hand--we have a user, who newly installed KiCad on his Mac,
> and it looks like his KISYSMOD is being set to a path on the build system,
> probably CMAKE_INSTALL_PREFIX. (
> https://bugs.launchpad.net/kicad/+bug/1426754)  (This was happening
> previously, and I started to set DEFAULT_INSTALL_PATH, and things got
> better for people after they cleared their preferences.)
>
> As far as I can tell, those defaults are set in common/pgm_base.cpp, and
> the only Mac specific ifdef is to not include /share/kicad/ in KISYSMOD's
> path. (Which is correct.)
>
> I cleared all my KiCad preferences and reinstalled the same package he did
> (as part of testing the RC2, like I do with most significant builds) and
> did not have this issue.
>
> The only possible issue I see when looking for DEFAULT_INSTALL_PATH stuff
> for OS X is in common/systemdirsappend.cpp, in void SystemDirsAppend(
> SEARCH_STACK* aSearchStack ). Instead of adding DEFAULT_INSTALL_PATH, it
> uses some OS X specific functions, but those seem to be working fine.
>
> So.  This is happening to a user, and I cannot reproduce it, but I'm
> worried about releasing 4.0.0 on OS X without more information.  I know of
> 30+ installs of 4.0.0 RC2 that *didn't* have this issue for Jimmy, but I
> suspect they all had existing preference files.
>
> 1) Does anyone have any insight?
>
> 2) Should this hold up the 4.0.0 package for OS X?  I have no real qualms
> about doing this and then releasing a 4.0.0-2 as soon as this gets figured
> out.
>
> 3) A possible hack that would fix this could be to change the fp-table-lib
> included with the extras package to point to the exact same place as the
> symlink--i.e. expand out KISYSMOD.  I actually don't necessarily see a huge
> problem with this--if a user wants to install the files somewhere else than
> the default package does it, they are probably capable of a search/replace
> in a text editor.
>
> I'd rather fix the real issue, but being that I cannot reproduce it after
> ~3 hours, I'm not sure I want to say "I'm not going to cut a 4.0.0 release
> until this is fixed."
>
> Thoughts?
>
> Adam Wolf
> Cofounder and Engineer
> W
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Adam Wolf 
Hi folks!

A user is having a problem with the latest OS X RC2 release, and I haven't
been able to figure it out.

Quick background:

There is a KiCad package, and a KiCad Extras package.  The KiCad Extras
package has a modules/ directory in it, and it has all the footprints.
It's for offline use.  It also has an fp-table-lib, which uses KISYSMOD to
point at the modules, like this:

  (lib (name Capacitors_SMD)(type KiCad)(uri
${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like
them."))

My builds have DEFAULT_INSTALL_PATH set to /Library/Application
Support/kicad, like I want them to.  I checked the build output, and it
shows:

-- Kicad install dir: 


Great, awesome, exactly like I want it.

On the other hand--we have a user, who newly installed KiCad on his Mac,
and it looks like his KISYSMOD is being set to a path on the build system,
probably CMAKE_INSTALL_PREFIX. (
https://bugs.launchpad.net/kicad/+bug/1426754)  (This was happening
previously, and I started to set DEFAULT_INSTALL_PATH, and things got
better for people after they cleared their preferences.)

As far as I can tell, those defaults are set in common/pgm_base.cpp, and
the only Mac specific ifdef is to not include /share/kicad/ in KISYSMOD's
path. (Which is correct.)

I cleared all my KiCad preferences and reinstalled the same package he did
(as part of testing the RC2, like I do with most significant builds) and
did not have this issue.

The only possible issue I see when looking for DEFAULT_INSTALL_PATH stuff
for OS X is in common/systemdirsappend.cpp, in void SystemDirsAppend(
SEARCH_STACK* aSearchStack ). Instead of adding DEFAULT_INSTALL_PATH, it
uses some OS X specific functions, but those seem to be working fine.

So.  This is happening to a user, and I cannot reproduce it, but I'm
worried about releasing 4.0.0 on OS X without more information.  I know of
30+ installs of 4.0.0 RC2 that *didn't* have this issue for Jimmy, but I
suspect they all had existing preference files.

1) Does anyone have any insight?

2) Should this hold up the 4.0.0 package for OS X?  I have no real qualms
about doing this and then releasing a 4.0.0-2 as soon as this gets figured
out.

3) A possible hack that would fix this could be to change the fp-table-lib
included with the extras package to point to the exact same place as the
symlink--i.e. expand out KISYSMOD.  I actually don't necessarily see a huge
problem with this--if a user wants to install the files somewhere else than
the default package does it, they are probably capable of a search/replace
in a text editor.

I'd rather fix the real issue, but being that I cannot reproduce it after
~3 hours, I'm not sure I want to say "I'm not going to cut a 4.0.0 release
until this is fixed."

Thoughts?

Adam Wolf
Cofounder and Engineer
W
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Bob Gustafson 
Maybe it is a 'first time use problem' - maybe no kicad directory in the 
/Library/Application Support/. It may require a privilege password to 
add this directory the first time.


A thought anyway.

Bob G

On 12/03/2015 02:08 PM, Adam Wolf wrote:

Hi folks!

A user is having a problem with the latest OS X RC2 release, and I 
haven't been able to figure it out.


Quick background:

There is a KiCad package, and a KiCad Extras package.  The KiCad 
Extras package has a modules/ directory in it, and it has all the 
footprints.  It's for offline use.  It also has an fp-table-lib, which 
uses KISYSMOD to point at the modules, like this:


  (lib (name Capacitors_SMD)(type KiCad)(uri 
${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like 
them."))


My builds have DEFAULT_INSTALL_PATH set to /Library/Application 
Support/kicad, like I want them to.  I checked the build output, and 
it shows:

-- Kicad install dir: 
Great, awesome, exactly like I want it.

On the other hand--we have a user, who newly installed KiCad on his 
Mac, and it looks like his KISYSMOD is being set to a path on the 
build system, probably CMAKE_INSTALL_PREFIX. 
(https://bugs.launchpad.net/kicad/+bug/1426754)  (This was happening 
previously, and I started to set DEFAULT_INSTALL_PATH, and things got 
better for people after they cleared their preferences.)


As far as I can tell, those defaults are set in common/pgm_base.cpp, 
and the only Mac specific ifdef is to not include /share/kicad/ in 
KISYSMOD's path. (Which is correct.)


I cleared all my KiCad preferences and reinstalled the same package he 
did (as part of testing the RC2, like I do with most significant 
builds) and did not have this issue.


The only possible issue I see when looking for DEFAULT_INSTALL_PATH 
stuff for OS X is in common/systemdirsappend.cpp, in void 
SystemDirsAppend( SEARCH_STACK* aSearchStack ). Instead of adding 
DEFAULT_INSTALL_PATH, it uses some OS X specific functions, but those 
seem to be working fine.


So.  This is happening to a user, and I cannot reproduce it, but I'm 
worried about releasing 4.0.0 on OS X without more information.  I 
know of 30+ installs of 4.0.0 RC2 that *didn't* have this issue for 
Jimmy, but I suspect they all had existing preference files.


1) Does anyone have any insight?

2) Should this hold up the 4.0.0 package for OS X?  I have no real 
qualms about doing this and then releasing a 4.0.0-2 as soon as this 
gets figured out.


3) A possible hack that would fix this could be to change the 
fp-table-lib included with the extras package to point to the exact 
same place as the symlink--i.e. expand out KISYSMOD.  I actually don't 
necessarily see a huge problem with this--if a user wants to install 
the files somewhere else than the default package does it, they are 
probably capable of a search/replace in a text editor.


I'd rather fix the real issue, but being that I cannot reproduce it 
after ~3 hours, I'm not sure I want to say "I'm not going to cut a 
4.0.0 release until this is fixed."


Thoughts?

Adam Wolf
Cofounder and Engineer
W


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Bernhard Stegmaier 
It’s not in a plist, but in ~/Library/Preferences/kicad/kicad_common.
As far as I can remember, if you had something wrong in there before the 
environment-variable changes Wayne did, it didn’t vanish with the changes… you 
had to manually change via Preferences => Path Configuration (or, clear/edit it 
manually in the configs).

What is shown for him in Preferences => Path Configuration? Does he have 
footprints available or not?
Maybe he really did see something else…


Regards,
Bernhard

> On 03 Dec 2015, at 21:43, Adam Wolf  wrote:
> 
> I am glad I am not the only one puzzled by this.
> 
> I also searched the plists, because at one point we were putting environment 
> variables in there, but that stopped over a year ago I thought.
> 
> Oh the other hand--
> 
> Is it possible he had some other error, and saw the debug messages that say 
> line numbers (which do have the build paths from my server), and searched, 
> and thought this bug is the same issue he's having?
> 
> Adam Wolf
> 
> On Thu, Dec 3, 2015 at 2:38 PM, Bernhard Stegmaier  > wrote:
> I also don’t see any reason for what you described.
> The SEARCH_STACK stuff should not be used in pcbnew any more, the other one 
> in pgm_base.cpp looks good IMHO. I can’t remember any other place where this 
> could be a problem except there is already some path slipping in from outside 
> of KiCad.
> 
> Is he *really* sure that this OSX has *never* seen any KiCad before and there 
> are no config files or attempts left from any previous try?
> Maybe he just copied his home folder including ~/Library/Preferences/kicad 
> after a fresh install that was generated on a different machine or previous 
> OS X installation?
> 
> 
> Regards,
> Bernhard
> 
>> On 03 Dec 2015, at 21:18, Adam Wolf > > wrote:
>> 
>> A good one!  But alas, we have them drag and drop a kicad/ directory onto a 
>> symlink to /Library/Application\ Support/, and it does a popup asking for 
>> admin privileges.  (We also have this in the README right there when you 
>> install).
>> 
>> It's certainly got me puzzled!
>> 
>> On Thu, Dec 3, 2015 at 2:16 PM, Bob Gustafson > > wrote:
>> Maybe it is a 'first time use problem' - maybe no kicad directory in the 
>> /Library/Application Support/. It may require a privilege password to add 
>> this directory the first time.
>> 
>> A thought anyway.
>> 
>> Bob G
>> 
>> 
>> On 12/03/2015 02:08 PM, Adam Wolf wrote:
>>> Hi folks!
>>> 
>>> A user is having a problem with the latest OS X RC2 release, and I haven't 
>>> been able to figure it out.
>>> 
>>> Quick background:
>>> 
>>> There is a KiCad package, and a KiCad Extras package.  The KiCad Extras 
>>> package has a modules/ directory in it, and it has all the footprints.  
>>> It's for offline use.  It also has an fp-table-lib, which uses KISYSMOD to 
>>> point at the modules, like this:
>>> 
>>>   (lib (name Capacitors_SMD)(type KiCad)(uri 
>>> ${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like 
>>> them."))
>>> 
>>> My builds have DEFAULT_INSTALL_PATH set to /Library/Application 
>>> Support/kicad, like I want them to.  I checked the build output, and it 
>>> shows:
>>> -- Kicad install dir: 
>>> Great, awesome, exactly like I want it.
>>> 
>>> On the other hand--we have a user, who newly installed KiCad on his Mac, 
>>> and it looks like his KISYSMOD is being set to a path on the build system, 
>>> probably CMAKE_INSTALL_PREFIX. 
>>> (https://bugs.launchpad.net/kicad/+bug/1426754 
>>> )  (This was happening 
>>> previously, and I started to set DEFAULT_INSTALL_PATH, and things got 
>>> better for people after they cleared their preferences.)
>>> 
>>> As far as I can tell, those defaults are set in common/pgm_base.cpp, and 
>>> the only Mac specific ifdef is to not include /share/kicad/ in KISYSMOD's 
>>> path. (Which is correct.)
>>> 
>>> I cleared all my KiCad preferences and reinstalled the same package he did 
>>> (as part of testing the RC2, like I do with most significant builds) and 
>>> did not have this issue.
>>> 
>>> The only possible issue I see when looking for DEFAULT_INSTALL_PATH stuff 
>>> for OS X is in common/systemdirsappend.cpp, in void SystemDirsAppend( 
>>> SEARCH_STACK* aSearchStack ). Instead of adding DEFAULT_INSTALL_PATH, it 
>>> uses some OS X specific functions, but those seem to be working fine.
>>> 
>>> So.  This is happening to a user, and I cannot reproduce it, but I'm 
>>> worried about releasing 4.0.0 on OS X without more information.  I know of 
>>> 30+ installs of 4.0.0 RC2 that *didn't* have this issue for Jimmy, but I 
>>> suspect they all had existing preference files.
>>> 
>>> 1) Does anyone have any insight?
>>> 
>>> 2) Should this hold up the 4.0.0 package for OS X?  I have no real qualms 
>>>

Re: [Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Adam Wolf 
I asked him for Preferences => Path Configuration in the last email.  He
hasn't responded yet.

 He doesn't have footprints available, but it looks like that's due to a
networking issue and Github footprints? Not sure.

I am almost willing to chalk this up to it being a fluke, especially if we
don't see other people complaining about it.

Adam Wolf

On Thu, Dec 3, 2015 at 2:57 PM, Bernhard Stegmaier 
wrote:

> It’s not in a plist, but in ~/Library/Preferences/kicad/kicad_common.
> As far as I can remember, if you had something wrong in there before the
> environment-variable changes Wayne did, it didn’t vanish with the changes…
> you had to manually change via Preferences => Path Configuration (or,
> clear/edit it manually in the configs).
>
> What is shown for him in Preferences => Path Configuration? Does he have
> footprints available or not?
> Maybe he really did see something else…
>
>
> Regards,
> Bernhard
>
> On 03 Dec 2015, at 21:43, Adam Wolf  wrote:
>
> I am glad I am not the only one puzzled by this.
>
> I also searched the plists, because at one point we were putting
> environment variables in there, but that stopped over a year ago I thought.
>
> Oh the other hand--
>
> Is it possible he had some other error, and saw the debug messages that
> say line numbers (which do have the build paths from my server), and
> searched, and thought this bug is the same issue he's having?
>
> Adam Wolf
>
> On Thu, Dec 3, 2015 at 2:38 PM, Bernhard Stegmaier <
> stegma...@sw-systems.de> wrote:
>
>> I also don’t see any reason for what you described.
>> The SEARCH_STACK stuff should not be used in pcbnew any more, the other
>> one in pgm_base.cpp looks good IMHO. I can’t remember any other place where
>> this could be a problem except there is already some path slipping in from
>> outside of KiCad.
>>
>> Is he *really* sure that this OSX has *never* seen any KiCad before and
>> there are no config files or attempts left from any previous try?
>> Maybe he just copied his home folder including
>> ~/Library/Preferences/kicad after a fresh install that was generated on a
>> different machine or previous OS X installation?
>>
>>
>> Regards,
>> Bernhard
>>
>> On 03 Dec 2015, at 21:18, Adam Wolf 
>> wrote:
>>
>> A good one!  But alas, we have them drag and drop a kicad/ directory onto
>> a symlink to /Library/Application\ Support/, and it does a popup asking for
>> admin privileges.  (We also have this in the README right there when you
>> install).
>>
>> It's certainly got me puzzled!
>>
>> On Thu, Dec 3, 2015 at 2:16 PM, Bob Gustafson  wrote:
>>
>>> Maybe it is a 'first time use problem' - maybe no kicad directory in the
>>> /Library/Application Support/. It may require a privilege password to add
>>> this directory the first time.
>>>
>>> A thought anyway.
>>>
>>> Bob G
>>>
>>>
>>> On 12/03/2015 02:08 PM, Adam Wolf wrote:
>>>
>>> Hi folks!
>>>
>>> A user is having a problem with the latest OS X RC2 release, and I
>>> haven't been able to figure it out.
>>>
>>> Quick background:
>>>
>>> There is a KiCad package, and a KiCad Extras package.  The KiCad Extras
>>> package has a modules/ directory in it, and it has all the footprints.
>>> It's for offline use.  It also has an fp-table-lib, which uses KISYSMOD to
>>> point at the modules, like this:
>>>
>>>   (lib (name Capacitors_SMD)(type KiCad)(uri
>>> ${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like
>>> them."))
>>>
>>> My builds have DEFAULT_INSTALL_PATH set to /Library/Application
>>> Support/kicad, like I want them to.  I checked the build output, and it
>>> shows:
>>>
>>> -- Kicad install dir: 
>>>
>>> Great, awesome, exactly like I want it.
>>>
>>> On the other hand--we have a user, who newly installed KiCad on his Mac,
>>> and it looks like his KISYSMOD is being set to a path on the build system,
>>> probably CMAKE_INSTALL_PREFIX. (
>>> https://bugs.launchpad.net/kicad/+bug/1426754)  (This was happening
>>> previously, and I started to set DEFAULT_INSTALL_PATH, and things got
>>> better for people after they cleared their preferences.)
>>>
>>> As far as I can tell, those defaults are set in common/pgm_base.cpp, and
>>> the only Mac specific ifdef is to not include /share/kicad/ in KISYSMOD's
>>> path. (Which is correct.)
>>>
>>> I cleared all my KiCad preferences and reinstalled the same package he
>>> did (as part of testing the RC2, like I do with most significant builds)
>>> and did not have this issue.
>>>
>>> The only possible issue I see when looking for DEFAULT_INSTALL_PATH
>>> stuff for OS X is in common/systemdirsappend.cpp, in void SystemDirsAppend(
>>> SEARCH_STACK* aSearchStack ). Instead of adding DEFAULT_INSTALL_PATH, it
>>> uses some OS X specific functions, but those seem to be working fine.
>>>
>>> So.  This is happening to a user, and I cannot reproduce it, but I'm
>>> worried about releasing 4.0.0 on OS X without more

Re: [Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Adam Wolf 
I am glad I am not the only one puzzled by this.

I also searched the plists, because at one point we were putting
environment variables in there, but that stopped over a year ago I thought.

Oh the other hand--

Is it possible he had some other error, and saw the debug messages that say
line numbers (which do have the build paths from my server), and searched,
and thought this bug is the same issue he's having?

Adam Wolf

On Thu, Dec 3, 2015 at 2:38 PM, Bernhard Stegmaier 
wrote:

> I also don’t see any reason for what you described.
> The SEARCH_STACK stuff should not be used in pcbnew any more, the other
> one in pgm_base.cpp looks good IMHO. I can’t remember any other place where
> this could be a problem except there is already some path slipping in from
> outside of KiCad.
>
> Is he *really* sure that this OSX has *never* seen any KiCad before and
> there are no config files or attempts left from any previous try?
> Maybe he just copied his home folder including ~/Library/Preferences/kicad
> after a fresh install that was generated on a different machine or previous
> OS X installation?
>
>
> Regards,
> Bernhard
>
> On 03 Dec 2015, at 21:18, Adam Wolf  wrote:
>
> A good one!  But alas, we have them drag and drop a kicad/ directory onto
> a symlink to /Library/Application\ Support/, and it does a popup asking for
> admin privileges.  (We also have this in the README right there when you
> install).
>
> It's certainly got me puzzled!
>
> On Thu, Dec 3, 2015 at 2:16 PM, Bob Gustafson  wrote:
>
>> Maybe it is a 'first time use problem' - maybe no kicad directory in the
>> /Library/Application Support/. It may require a privilege password to add
>> this directory the first time.
>>
>> A thought anyway.
>>
>> Bob G
>>
>>
>> On 12/03/2015 02:08 PM, Adam Wolf wrote:
>>
>> Hi folks!
>>
>> A user is having a problem with the latest OS X RC2 release, and I
>> haven't been able to figure it out.
>>
>> Quick background:
>>
>> There is a KiCad package, and a KiCad Extras package.  The KiCad Extras
>> package has a modules/ directory in it, and it has all the footprints.
>> It's for offline use.  It also has an fp-table-lib, which uses KISYSMOD to
>> point at the modules, like this:
>>
>>   (lib (name Capacitors_SMD)(type KiCad)(uri
>> ${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like
>> them."))
>>
>> My builds have DEFAULT_INSTALL_PATH set to /Library/Application
>> Support/kicad, like I want them to.  I checked the build output, and it
>> shows:
>>
>> -- Kicad install dir: 
>>
>> Great, awesome, exactly like I want it.
>>
>> On the other hand--we have a user, who newly installed KiCad on his Mac,
>> and it looks like his KISYSMOD is being set to a path on the build system,
>> probably CMAKE_INSTALL_PREFIX. (
>> https://bugs.launchpad.net/kicad/+bug/1426754)  (This was happening
>> previously, and I started to set DEFAULT_INSTALL_PATH, and things got
>> better for people after they cleared their preferences.)
>>
>> As far as I can tell, those defaults are set in common/pgm_base.cpp, and
>> the only Mac specific ifdef is to not include /share/kicad/ in KISYSMOD's
>> path. (Which is correct.)
>>
>> I cleared all my KiCad preferences and reinstalled the same package he
>> did (as part of testing the RC2, like I do with most significant builds)
>> and did not have this issue.
>>
>> The only possible issue I see when looking for DEFAULT_INSTALL_PATH stuff
>> for OS X is in common/systemdirsappend.cpp, in void SystemDirsAppend(
>> SEARCH_STACK* aSearchStack ). Instead of adding DEFAULT_INSTALL_PATH, it
>> uses some OS X specific functions, but those seem to be working fine.
>>
>> So.  This is happening to a user, and I cannot reproduce it, but I'm
>> worried about releasing 4.0.0 on OS X without more information.  I know of
>> 30+ installs of 4.0.0 RC2 that *didn't* have this issue for Jimmy, but I
>> suspect they all had existing preference files.
>>
>> 1) Does anyone have any insight?
>>
>> 2) Should this hold up the 4.0.0 package for OS X?  I have no real qualms
>> about doing this and then releasing a 4.0.0-2 as soon as this gets figured
>> out.
>>
>> 3) A possible hack that would fix this could be to change the
>> fp-table-lib included with the extras package to point to the exact same
>> place as the symlink--i.e. expand out KISYSMOD.  I actually don't
>> necessarily see a huge problem with this--if a user wants to install the
>> files somewhere else than the default package does it, they are probably
>> capable of a search/replace in a text editor.
>>
>> I'd rather fix the real issue, but being that I cannot reproduce it after
>> ~3 hours, I'm not sure I want to say "I'm not going to cut a 4.0.0 release
>> until this is fixed."
>>
>> Thoughts?
>>
>> Adam Wolf
>> Cofounder and Engineer
>> W
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to :

Re: [Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Bernhard Stegmaier 
I also don’t see any reason for what you described.
The SEARCH_STACK stuff should not be used in pcbnew any more, the other one in 
pgm_base.cpp looks good IMHO. I can’t remember any other place where this could 
be a problem except there is already some path slipping in from outside of 
KiCad.

Is he *really* sure that this OSX has *never* seen any KiCad before and there 
are no config files or attempts left from any previous try?
Maybe he just copied his home folder including ~/Library/Preferences/kicad 
after a fresh install that was generated on a different machine or previous OS 
X installation?


Regards,
Bernhard

> On 03 Dec 2015, at 21:18, Adam Wolf  wrote:
> 
> A good one!  But alas, we have them drag and drop a kicad/ directory onto a 
> symlink to /Library/Application\ Support/, and it does a popup asking for 
> admin privileges.  (We also have this in the README right there when you 
> install).
> 
> It's certainly got me puzzled!
> 
> On Thu, Dec 3, 2015 at 2:16 PM, Bob Gustafson  > wrote:
> Maybe it is a 'first time use problem' - maybe no kicad directory in the 
> /Library/Application Support/. It may require a privilege password to add 
> this directory the first time.
> 
> A thought anyway.
> 
> Bob G
> 
> 
> On 12/03/2015 02:08 PM, Adam Wolf wrote:
>> Hi folks!
>> 
>> A user is having a problem with the latest OS X RC2 release, and I haven't 
>> been able to figure it out.
>> 
>> Quick background:
>> 
>> There is a KiCad package, and a KiCad Extras package.  The KiCad Extras 
>> package has a modules/ directory in it, and it has all the footprints.  It's 
>> for offline use.  It also has an fp-table-lib, which uses KISYSMOD to point 
>> at the modules, like this:
>> 
>>   (lib (name Capacitors_SMD)(type KiCad)(uri 
>> ${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like 
>> them."))
>> 
>> My builds have DEFAULT_INSTALL_PATH set to /Library/Application 
>> Support/kicad, like I want them to.  I checked the build output, and it 
>> shows:
>> -- Kicad install dir: 
>> Great, awesome, exactly like I want it.
>> 
>> On the other hand--we have a user, who newly installed KiCad on his Mac, and 
>> it looks like his KISYSMOD is being set to a path on the build system, 
>> probably CMAKE_INSTALL_PREFIX. 
>> (https://bugs.launchpad.net/kicad/+bug/1426754 
>> )  (This was happening 
>> previously, and I started to set DEFAULT_INSTALL_PATH, and things got better 
>> for people after they cleared their preferences.)
>> 
>> As far as I can tell, those defaults are set in common/pgm_base.cpp, and the 
>> only Mac specific ifdef is to not include /share/kicad/ in KISYSMOD's path. 
>> (Which is correct.)
>> 
>> I cleared all my KiCad preferences and reinstalled the same package he did 
>> (as part of testing the RC2, like I do with most significant builds) and did 
>> not have this issue.
>> 
>> The only possible issue I see when looking for DEFAULT_INSTALL_PATH stuff 
>> for OS X is in common/systemdirsappend.cpp, in void SystemDirsAppend( 
>> SEARCH_STACK* aSearchStack ). Instead of adding DEFAULT_INSTALL_PATH, it 
>> uses some OS X specific functions, but those seem to be working fine.
>> 
>> So.  This is happening to a user, and I cannot reproduce it, but I'm worried 
>> about releasing 4.0.0 on OS X without more information.  I know of 30+ 
>> installs of 4.0.0 RC2 that *didn't* have this issue for Jimmy, but I suspect 
>> they all had existing preference files.
>> 
>> 1) Does anyone have any insight?
>> 
>> 2) Should this hold up the 4.0.0 package for OS X?  I have no real qualms 
>> about doing this and then releasing a 4.0.0-2 as soon as this gets figured 
>> out.
>> 
>> 3) A possible hack that would fix this could be to change the fp-table-lib 
>> included with the extras package to point to the exact same place as the 
>> symlink--i.e. expand out KISYSMOD.  I actually don't necessarily see a huge 
>> problem with this--if a user wants to install the files somewhere else than 
>> the default package does it, they are probably capable of a search/replace 
>> in a text editor.
>> 
>> I'd rather fix the real issue, but being that I cannot reproduce it after ~3 
>> hours, I'm not sure I want to say "I'm not going to cut a 4.0.0 release 
>> until this is fixed."
>> 
>> Thoughts?
>> 
>> Adam Wolf
>> Cofounder and Engineer
>> W
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 
> 
> ___
> Mailing list:

Re: [Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Wayne Stambaugh 
I didn't see it in his comments but the environment variable config
dialog highlights environment variables that are already defined when
kicad starts so they take precedence over the user configuration by
design.  Is it possible that he has KISYSMOD already set?

On 12/3/2015 3:43 PM, Adam Wolf wrote:
> I am glad I am not the only one puzzled by this.
> 
> I also searched the plists, because at one point we were putting
> environment variables in there, but that stopped over a year ago I thought.
> 
> Oh the other hand--
> 
> Is it possible he had some other error, and saw the debug messages that
> say line numbers (which do have the build paths from my server), and
> searched, and thought this bug is the same issue he's having?
> 
> Adam Wolf
> 
> On Thu, Dec 3, 2015 at 2:38 PM, Bernhard Stegmaier
> > wrote:
> 
> I also don’t see any reason for what you described.
> The SEARCH_STACK stuff should not be used in pcbnew any more, the
> other one in pgm_base.cpp looks good IMHO. I can’t remember any
> other place where this could be a problem except there is already
> some path slipping in from outside of KiCad.
> 
> Is he *really* sure that this OSX has *never* seen any KiCad before
> and there are no config files or attempts left from any previous try?
> Maybe he just copied his home folder including
> ~/Library/Preferences/kicad after a fresh install that was generated
> on a different machine or previous OS X installation?
> 
> 
> Regards,
> Bernhard
> 
>> On 03 Dec 2015, at 21:18, Adam Wolf > > wrote:
>>
>> A good one!  But alas, we have them drag and drop a kicad/
>> directory onto a symlink to /Library/Application\ Support/, and it
>> does a popup asking for admin privileges.  (We also have this in
>> the README right there when you install).
>>
>> It's certainly got me puzzled!
>>
>> On Thu, Dec 3, 2015 at 2:16 PM, Bob Gustafson > > wrote:
>>
>> Maybe it is a 'first time use problem' - maybe no kicad
>> directory in the /Library/Application Support/. It may require
>> a privilege password to add this directory the first time.
>>
>> A thought anyway.
>>
>> Bob G
>>
>>
>> On 12/03/2015 02:08 PM, Adam Wolf wrote:
>>> Hi folks!
>>>
>>> A user is having a problem with the latest OS X RC2 release,
>>> and I haven't been able to figure it out.
>>>
>>> Quick background:
>>>
>>> There is a KiCad package, and a KiCad Extras package.  The
>>> KiCad Extras package has a modules/ directory in it, and it
>>> has all the footprints.  It's for offline use.  It also has
>>> an fp-table-lib, which uses KISYSMOD to point at the modules,
>>> like this:
>>>
>>>   (lib (name Capacitors_SMD)(type KiCad)(uri
>>> ${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way
>>> you like them."))
>>>
>>> My builds have DEFAULT_INSTALL_PATH set to
>>> /Library/Application Support/kicad, like I want them to.  I
>>> checked the build output, and it shows:
>>> -- Kicad install dir: 
>>> Great, awesome, exactly like I want it.
>>>
>>> On the other hand--we have a user, who newly installed KiCad
>>> on his Mac, and it looks like his KISYSMOD is being set to a
>>> path on the build system, probably CMAKE_INSTALL_PREFIX.
>>> (https://bugs.launchpad.net/kicad/+bug/1426754)  (This was
>>> happening previously, and I started to set
>>> DEFAULT_INSTALL_PATH, and things got better for people after
>>> they cleared their preferences.)
>>>
>>> As far as I can tell, those defaults are set in
>>> common/pgm_base.cpp, and the only Mac specific ifdef is to
>>> not include /share/kicad/ in KISYSMOD's path. (Which is correct.)
>>>
>>> I cleared all my KiCad preferences and reinstalled the same
>>> package he did (as part of testing the RC2, like I do with
>>> most significant builds) and did not have this issue.
>>>
>>> The only possible issue I see when looking for
>>> DEFAULT_INSTALL_PATH stuff for OS X is in
>>> common/systemdirsappend.cpp, in void SystemDirsAppend(
>>> SEARCH_STACK* aSearchStack ). Instead of adding
>>> DEFAULT_INSTALL_PATH, it uses some OS X specific functions,
>>> but those seem to be working fine.
>>>
>>> So.  This is happening to a user, and I cannot reproduce it,
>>> but I'm worried about releasing 4.0.0 on OS X without more
>>> information.  I know of 30+ installs of 4.0.0 RC2 that
>>> *didn't* have this issue for Jimmy, but I suspect they all
>>> had existing preference files.
>>>
>>> 1) Does

Re: [Kicad-developers] Uninitialized KISYSMOD issue on OS X?

2015-12-03 Thread Wayne Stambaugh 
On 12/3/2015 3:08 PM, Adam Wolf wrote:
> Hi folks!
> 
> A user is having a problem with the latest OS X RC2 release, and I
> haven't been able to figure it out.
> 
> Quick background:
> 
> There is a KiCad package, and a KiCad Extras package.  The KiCad Extras
> package has a modules/ directory in it, and it has all the footprints. 
> It's for offline use.  It also has an fp-table-lib, which uses KISYSMOD
> to point at the modules, like this:
> 
>   (lib (name Capacitors_SMD)(type KiCad)(uri
> ${KISYSMOD}/Capacitors_SMD.pretty)(options "")(descr "The way you like
> them."))
> 
> My builds have DEFAULT_INSTALL_PATH set to /Library/Application
> Support/kicad, like I want them to.  I checked the build output, and it
> shows:
> 
> -- Kicad install dir: 
> 
> 
> Great, awesome, exactly like I want it.
> 
> On the other hand--we have a user, who newly installed KiCad on his Mac,
> and it looks like his KISYSMOD is being set to a path on the build
> system, probably CMAKE_INSTALL_PREFIX.
> (https://bugs.launchpad.net/kicad/+bug/1426754)  (This was happening
> previously, and I started to set DEFAULT_INSTALL_PATH, and things got
> better for people after they cleared their preferences.)
> 
> As far as I can tell, those defaults are set in common/pgm_base.cpp, and
> the only Mac specific ifdef is to not include /share/kicad/ in
> KISYSMOD's path. (Which is correct.)
> 
> I cleared all my KiCad preferences and reinstalled the same package he
> did (as part of testing the RC2, like I do with most significant builds)
> and did not have this issue.
> 
> The only possible issue I see when looking for DEFAULT_INSTALL_PATH
> stuff for OS X is in common/systemdirsappend.cpp, in void
> SystemDirsAppend( SEARCH_STACK* aSearchStack ). Instead of adding
> DEFAULT_INSTALL_PATH, it uses some OS X specific functions, but those
> seem to be working fine.
> 
> So.  This is happening to a user, and I cannot reproduce it, but I'm
> worried about releasing 4.0.0 on OS X without more information.  I know
> of 30+ installs of 4.0.0 RC2 that *didn't* have this issue for Jimmy,
> but I suspect they all had existing preference files.
> 
> 1) Does anyone have any insight?
> 
> 2) Should this hold up the 4.0.0 package for OS X?  I have no real
> qualms about doing this and then releasing a 4.0.0-2 as soon as this
> gets figured out.

If others are having this issue as well, I would say wait.  If he is the
only one having this issue, I say go ahead and roll out the 4.0.0 stable
release.  I'm guessing a 4.0.1 stable release will happen this weekend
since there is a patch to fix the gal canvas segment drag issue which I
don't want to leave unresolved for users.

> 
> 3) A possible hack that would fix this could be to change the
> fp-table-lib included with the extras package to point to the exact same
> place as the symlink--i.e. expand out KISYSMOD.  I actually don't
> necessarily see a huge problem with this--if a user wants to install the
> files somewhere else than the default package does it, they are probably
> capable of a search/replace in a text editor.
> 
> I'd rather fix the real issue, but being that I cannot reproduce it
> after ~3 hours, I'm not sure I want to say "I'm not going to cut a 4.0.0
> release until this is fixed."
> 
> Thoughts?
> 
> Adam Wolf
> Cofounder and Engineer
> W
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp