Re: gEDA-user: guile under minipack?

[DJ Delorie]

Status...

guile won't build with pthreads.

guile won't build with --with-threads=none either

apparently, it wants a fake "null-threads" package.  The way to get
that is to UNINSTALL the mingw pthreads package.

Pixman tried to link -lpthreads anyway!

Turns out, minipack uses the installed libraries (/usr) to calculate
dependencies (er, rpm dependencies didn't match the library
dependencies), not the minipack built libraries!

So, I uninstalled as many distro mingw libraries as I could (gtk,
cairo, etc).

It all builds!

PCB and gerbv work just fine in wine (I fixed my font issues - had to
install yet another mingw font; the system font was not a dependency
of anything, but optional fonts were!)

Anyone have an nsis script with which to package it all up?

As others have noted, gschem fails at startup - This isn't much of a
clue, but...

Backtrace:
=>0 0x75478526 __strlen_sse2_bsf+0x16() in libc.so.6 (0x0066fb58)
  1 0x7bc7620e NTDLL_strlen+0x1d() in ntdll (0x0066fb98)
  2 0x6bfd4ea9 in libguile-17 (+0x54ea8) (0x0066fbb8)
  3 0x66308c5a in libgeda-38 (+0x8c59) (0x0066fbd8)
  4 0x00408ba2 in gschem (+0x8ba1) (0x0066fc28)
  5 0x6bfb0e5a in libguile-17 (+0x30e59) (0x0066fc48)
  6 0x6bf85242 in libguile-17 (+0x5241) (0x0066fc68)
  7 0x6bff108c in libguile-17 (+0x7108b) (0x0066fcf8)
  8 0x6bf854f1 in libguile-17 (+0x54f0) (0x0066fd58)
  9 0x6bf85927 in libguile-17 (+0x5926) (0x0066fd88)
  10 0x6bff011b in libguile-17 (+0x7011a) (0x0066fdb8)
  11 0x6bff0161 in libguile-17 (+0x70160) (0x0066fdd8)
  12 0x6bfb0f11 in libguile-17 (+0x30f10) (0x0066fe08)
  13 0x0040914c in gschem (+0x914b) (0x0066fe28)
  14 0x004010b6 in gschem (+0x10b5) (0x0066fe70)
  15 0x00401128 in gschem (+0x1127) (0x0066fe90)


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: import schematics with local footprints

[DJ Delorie]

> What square bracket?

In the library window, at the end of each M4 footprint's description,
is the string to use for footprint= in brackets, like [0603].  For
file-based footprints, you of course use the file name.

> But for generic footprint names like 0805 the import action chooses
> the version from the default lib.

I think this is the "m4 before newlib" bug, so you need the magic
~/.pcb/settings incantation to disable the m4 library completely:

lib-contents-command = /bin/true


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: geda master attributes list: spaces in ‘device’ value?

[Kai-Martin Knaak]

Colin D Bennett wrote:

> There seems to be a contradiction in the description of the ‘device’
> attribute on the wiki master_attributes_list [1].
> 
>> Do not put spaces into the device name; there are some programs which
>> dislike spaces in the device specifier. Generally the device name is
>> in all caps. Examples: device=7400 device=CONNECTOR 10 device=NPN
>> TRANSISTOR
> 
> The two of the three examples given have spaces in the value, but the
> text says not to use spaces.  Which is correct?

And: 
* What is the intended purpose of the device attribute?
* What components use the device attribute?
* What value should be chosen for the device attribute?  
* What symbols can get away with no device attribute?
* What is the difference between "device=none" and no device attribute at all?
* Why do graphical symbols need  "device=none"? Do they really need it?
* Why does the device name have to be in caps? Does it have to?

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB launchpad bugs to mailinglist

[Kai-Martin Knaak]

DJ Delorie wrote:

> 
>> How would I do that (with my news server)? 
> 
> You probably can't.  Most mailing lists are not mirrored to news
> servers.

Someone has to ask kindly at gmane.org to include the mailinglist to 
their usenet service. I just filed the application form. Let's see 
if they approve.

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB launchpad bugs to mailinglist

[Kai-Martin Knaak]

DJ Delorie wrote:

>  Subscribe to
> pcb-b...@lists.sourceforge.net.

How would this exactly be done? I sent an email to the above address
with subject "subscribe". An automatically sent reply asked for a 
confirmation that my email address is valid, which I did. I'll wait
for pcb bug reports to arrive.

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB head fails with ***MEMORY-ERROR***

[Kai-Martin Knaak]

Andrew Poelstra wrote:

> The problem happens in the loop in rats.c, lines 766-784.

That was quick!
I hope, this issue is resolved soon.

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: import schematics with local footprints

[Kai-Martin Knaak]

DJ Delorie wrote:

> 
> No, you're doing it right.  Run PCB and open the library window.  Do
> you see your footprints there?

yes.


> Do the names in square brackets match the footprint attributes?

What square bracket?
Yes, I have the footprint attributes set correctly. The traditional 
gsch2pcb has no trouble locating the footprints. The import action
works fine for components that have a unique name in my lib. But for  
generic footprint names like 0805 the import action chooses the version
from the default lib. This is very certainly not what I want. If it were
me, there should be no defaulting to the default lib at all.


> The most likely "newbie mistake" is pointing your local libraries one
> level too far up/down...

Been there, done that -- about five years ago.

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: ‘symversion’ documentation update

[John Doty]

On Jun 3, 2011, at 1:49 PM, Colin D Bennett wrote:

> Is ‘device’ used for simulation purposes?

In at least some flows, yes. The spice-sdb back end to gnetlist attempts to 
determine if it needs to prepend a key letter to the device to select the 
correct SPICE primitive. You can turn this behavior off with --nomunge: that's 
what I usually do, since I find the heuristics here often guess wrong.

>  It sort of seems like it is
> to specify the general type of a device, i.e., NPN TRANSISTOR, etc.
> At least what I have been doing is to add device= as a hidden attribute
> specifying the general type of the symbol (e.g., “RS-485 TRANSCEIVER”),
> and add value= as a visible attribute (for most types of symbols, such
> as connectors and ICs) giving the specific device (e.g., “SP3075E”).

There is no universal convention in gEDA practice for what the "device" 
attribute indicates.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gEDA with Guile 2.0

[Peter TB Brett]

> Currently, the only known problem is that the `drc2' gnetlist backend
> is broken.

This is now fixed, and there are no known issues with using the gEDA
main development branch with Guile 2.0.

   Peter

-- 
Peter Brett 
Remote Sensing Research Group
Surrey Space Centre


pgpyiC80GyuMP.pgp
Description: PGP signature


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: gEDA with Guile 2.0

[Peter TB Brett]

Hi folks,

I've just checked in some changes that enable gEDA to compile and run
with Guile 2.0.  Please report any issues.  Currently, the only known
problem is that the `drc2' gnetlist backend is broken.

Regards,

  Peter

-- 
Peter Brett 
Remote Sensing Research Group
Surrey Space Centre


pgp76wt5NlQSc.pgp
Description: PGP signature


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: ‘symversion’ documentation update

[Colin D Bennett]

On Fri, 03 Jun 2011 19:32:46 +0200
Kai-Martin Knaak  wrote:

> Colin D Bennett wrote:
> > I always add symversion=1.0 to my custom symbols because (1) 
> 
> Unfortunately, I did not since a few months ago. Now, that I started
> using the symversion gschem throws unnecessary warnings at me. It
> seems to interprete the appearance of a symversion symbol where there
> has none been before as a "major version change". Sorry, but it's
> not. Starting a version series does not constitute a change of
> versions.
>...
> The harm of this statement in the documenation is clear: It made me 
> omit  symversion attributes in my symbol library. Now, I have to deal 
> with the above update pains.

So it sounds like the recommendation should be in fact *to* add the
symversion= attribute to all symbols, to prevent this type of confusion.

> Some more attributes with missing/doubtful/oudated description are
>device --> what component uses this attribute for what purpose?

Is ‘device’ used for simulation purposes?  It sort of seems like it is
to specify the general type of a device, i.e., NPN TRANSISTOR, etc.
At least what I have been doing is to add device= as a hidden attribute
specifying the general type of the symbol (e.g., “RS-485 TRANSCEIVER”),
and add value= as a visible attribute (for most types of symbols, such
as connectors and ICs) giving the specific device (e.g., “SP3075E”).

>pinseq --> restricted to integers? 
>numslots --> if there is no slotting gnetlist is fine without this

I still add numslots=0 to all symbols (I have never used slots yet...
I'm confused about how to do so), because I read at one time that it
was required... now it is sort of a superstition because I don't know
why I'm doing it!

> > How about replacing the symversion section with the following,
> > updated text:
> (...snip...)
> 
> +1 
> The section on promotion and consequences of a change are
> particularily important.

I can update the wiki with this change after a while if there are no
objections or suggestions for improvements.

Regards,
Colin


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: ‘symversion’ documentation update

[Kai-Martin Knaak]

Colin D Bennett wrote:

> The ‘symversion’ attribute's documentation says that this attribute
> should not be placed on new symbols, but only (1) on symbols “accepted
> into the main gEDA symbol library”, and even then (2) only when a
> change is made to the symbol.

I have asked about this before on the list. IIRC, nobody came up with 
a conclusive reason for (1) and (2). 


> I always add symversion=1.0 to my custom symbols because (1) 

Unfortunately, I did not since a few months ago. Now, that I started
using the symversion gschem throws unnecessary warnings at me. It seems
to interprete the appearance of a symversion symbol where there has none 
been before as a "major version change". Sorry, but it's not. Starting
a version series does not constitute a change of versions.


> it makes updating the version easier when the first change is made

ack.


> (2) version control system diffs show the version number change more
> readily and consistent with subsequent version updates when it's
> only a text change (e.g., “1.0” -> “1.1”) rather than an entirely new
> attribute after the first change.

ack.
 

> Anyway, what is the harm in adding symversion to brand new symbols?
> The wiki page says “New symbols should not receive this attribute at
> all. Only when the symbol is change should this attribute be placed
> into the symbol file and maintained.”

The harm of this statement in the documenation is clear: It made me 
omit  symversion attributes in my symbol library. Now, I have to deal 
with the above update pains.


> It seems like the wiki has many unnecessary and unexplained mandates
> like this.

True.
In addition, the description should be less vague as to where the 
attribute is used and what it means to not have it set in a symbol.
Restrictions on attribute syntax are also badly missing. 
Some more attributes with missing/doubtful/oudated description are
   device --> what component uses this attribute for what purpose?
   pinseq --> restricted to integers? 
   numslots --> if there is no slotting gnetlist is fine without this
   

> How about replacing the symversion section with the following, updated
> text:
(...snip...)

+1 
The section on promotion and consequences of a change are particularily 
important.

---<)kaimartin(>---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB head fails with ***MEMORY-ERROR***

[Andrew Poelstra]

On Fri, Jun 03, 2011 at 03:41:41PM +0200, Kai-Martin Knaak wrote:
>
> This seems to be a memory leak problem. I noted, that memory usage goes way up
> on rats optimization until it hits the ceiling (memory and swap used 100%).
> See the system log I attached to the lauchpad bug report.
>  https://bugs.launchpad.net/pcb/+bug/792139
> 
> These crashes happen with my current, a bit larger project. The same PCB 
> binary behaves inconspicuously when used with small scale projects. I attached
> a gzip of the offending layout to this mail.  
>

The problem happens in the loop in rats.c, lines 766-784.
There are two functions called, GetNetMemory and GetConnectionMemory.
The first builds up an array of Nets, allocating them in blocks
of 100 (4800 bytes) as needed.

Then, inside each Net, GetConnectionMemory builds up an array
of connections, again in blocks of 100 (4800 bytes) as needed.

I have to go to school now, but if someone else wants to take
a look at this, that's as far as I've gotten.


Also, it gets into this look pretty quickly, so if you put a
few traces statements into that loop, it's safe to run killall
pcb as soon as output appears. Otherwise you'll likely crash
your system.


-- 
Andrew Poelstra
Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net
Web:   http://www.wpsoftware.net/andrew/



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: ‘symversion’ documentation update

[Colin D Bennett]

The ‘symversion’ attribute's documentation says that this attribute
should not be placed on new symbols, but only (1) on symbols “accepted
into the main gEDA symbol library”, and even then (2) only when a
change is made to the symbol.

I always add symversion=1.0 to my custom symbols because (1) it makes
updating the version easier when the first change is made (so it is more
likely to be done), and
(2) version control system diffs show the version number change more
readily and consistent with subsequent version updates when it's
only a text change (e.g., “1.0” -> “1.1”) rather than an entirely new
attribute after the first change.

Anyway, what is the harm in adding symversion to brand new symbols?
The wiki page says “New symbols should not receive this attribute at
all. Only when the symbol is change should this attribute be placed
into the symbol file and maintained.”

It seems like the wiki has many unnecessary and unexplained mandates
like this. (In the future, let's remember to explain _why_ any such
restriction is necessary or desirable...)

From the geda master attributes list wiki page:

> symversion
> 
> The symversion= attribute is used to version the contents of symbols.
> Normally this attribute is not present, but once a symbol has been
> accepted into the main gEDA symbol library and there are changes to
> it, this attribute must be placed into the symbol file and properly
> incremented. The value of this attribute takes the following form:
> major.minor
> 
> where major and minor are just plain integers (separated by a
> period). The major number is incremented when a symbol has some sort
> of a change which will break or might break an existing schematic.
> The minor number is only incremented when a cosmetic or very minor
> change is made to the symbol. The major and minor numbers are not
> coupled in any way, however, when making major version changes, the
> minor version number can be reset to zero. If this attribute is
> inside of a symbol and that symbol is placed onto a schematic, then
> the symversion= attribute will be automatically promoted and attached
> to the outside of the symbol. During the load of the symbol from
> disk, the value of the symversion= inside the symbol file (if any)
> and the symversion= attached to the symbol (if any) are compared. If
> the values are the same then the placed symbol matches the disk
> symbol file, however if the values do not match, then libgeda will
> output a warning/error message (based on whether it is a major or
> minor version change). New symbols should not receive this attribute
> at all. Only when the symbol is change should this attribute be
> placed into the symbol file and maintained. Users should not attach
> this attribute manually to instantiated symbols. This attribute
> should normally be made invisible when placed inside of a symbol
> file. This attribute is always promoted when it is found inside of a
> symbol (during component placement). Examples: symversion=1.1


How about replacing the symversion section with the following, updated
text:

--- 
The symversion= attribute is used to version the contents of symbols.
Because symbols are, by default, referenced from the schematic and not
embedded within it, problems can occur in a schematic using a
particular symbol if that symbol file is modified.  For instance, if
pins are moved in the symbol, the schematic net lines will no longer
connect to the correct pins.  The symversion= attribute allows
tracking such breaking changes to symbols and notifying the user of
potential problems when a schematic is loaded.

This attribute is optional, but if present it must take the following
form:

major.minor

where major and minor are integers.  The major number is incremented
when a change is made to a symbol that might break an existing
schematic using the prior version of symbol when the new version is
introduced.  The minor number is only incremented when a minor change
is made (a change that cannot break an existing schematic, such as
cosmetic changes while retaining structure such as location of the
pins).

If this attribute is inside a symbol and that symbol is placed onto a
schematic, the symversion= attribute will be automatically “promoted”,
causing a copy of the symversion=M.N attribute to be stored on the
symbol instance in the schematic itself.  When a symbol is loaded from
disk, the value of the symversion= inside the symbol file (if any) and
the symversion value attached to the symbol instance on the schematic
are compared.  If the values differ, then libgeda will output a warning
message (for minor version changes) or an error message (for major
version changes).

This attribute should normally be made invisible when placed inside a
symbol file.  This attribute is always promoted when it is found inside
a symbol during component placement.  Users should not attach this
attribute manually to instantiated symbols in a schematic.

Example

Re: gEDA-user: import schematics with local footprints

[Felipe De la Puente Christen]

   On Fri, 2011-06-03 at 11:27 -0400, DJ Delorie wrote:

No, you're doing it right.  Run PCB and open the library window.  Do
you see your footprints there?  Do the names in square brackets match
the footprint attributes?  Those are the key things to using the
importer.


   I remember myself having to delete the pcb library to let my footprints
   be used instead of default library's equivalent (when there is a
   footprint with the same name as mine in the default library).
   Is this "fixed" ?

The most likely "newbie mistake" is pointing your local libraries one
level too far up/down...


___
geda-user mailing list
[1]geda-user@moria.seul.org
[2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

   --
   Felipe De la Puente Christen

References

   1. mailto:geda-user@moria.seul.org
   2. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: import schematics with local footprints

[DJ Delorie]

No, you're doing it right.  Run PCB and open the library window.  Do
you see your footprints there?  Do the names in square brackets match
the footprint attributes?  Those are the key things to using the
importer.

The most likely "newbie mistake" is pointing your local libraries one
level too far up/down...


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: import schematics with local footprints

[Kai-Martin Knaak]

With the traditional gsch2pcb work-flow I use project files to tell the 
system which footprints to use (and which not to use). For example:

/-timer_proto.g2p--
schematics timer_proto.sch
output-name timer_proto
skip-m4
verbose
elements-dir /home/kmk/geda/footprints
use-files
\--

How would I tell the same to the import schematics mechanism of PCB? 
Currently, the mechanism returns the footprints of the default library.
This is almost certainly not, what I want.  
The library list in PCB preferences already points exclusively to my footprint
lib. Did I miss something obvious? 

---<)kaimartin(>---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: geda master attributes list: spaces in ‘device’ value?

[Colin D Bennett]

There seems to be a contradiction in the description of the ‘device’
attribute on the wiki master_attributes_list [1].

> Do not put spaces into the device name; there are some programs which
> dislike spaces in the device specifier. Generally the device name is
> in all caps. Examples: device=7400 device=CONNECTOR 10 device=NPN
> TRANSISTOR

The two of the three examples given have spaces in the value, but the
text says not to use spaces.  Which is correct?

Regards,
Colin

[1] .


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB launchpad bugs to mailinglist

[DJ Delorie]

> How would I do that (with my news server)? 

You probably can't.  Most mailing lists are not mirrored to news
servers.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB head fails with ***MEMORY-ERROR***

[Thomas Oldbury]

   This might explain my problem with PCB+GL maybe it's just a general
   problem with PCB? I have noticed that PCB can eat up about 3 GB after a
   few hours of routing.

   On 3 June 2011 14:41, Kai-Martin Knaak <[1]kn...@iqo.uni-hannover.de>
   wrote:

   Andrew Poelstra wrote:
   > Use gdb to get a backtrace (gdb ./pcb, then r to run, bt to
   backtrace).

 On my other, more muscular box, the repeated application of
 "optimize rats"
 takes down the whole desktop environment. After about two minutes
 the screen
 freezes and blacks out. A few seconds later this single line is
 shown:
  acpid: client 5490 [0:0] has disconnected
 I could still change to a different tty with [ctrl-alt-F1]. The gdm
 service
 failed to restart. So I rebooted the whole box.
 This seems to be a memory leak problem. I noted, that memory usage
 goes way up
 on rats optimization until it hits the ceiling (memory and swap used
 100%).
 See the system log I attached to the lauchpad bug report.
 [2]https://bugs.launchpad.net/pcb/+bug/792139
 These crashes happen with my current, a bit larger project. The same
 PCB
 binary behaves inconspicuously when used with small scale projects.
 I attached
 a gzip of the offending layout to this mail.
 ---<)kaimartin(>---
 --
 Kai-Martin Knaak  tel:
 +49-511-762-2895
 Universität Hannover, Inst. für Quantenoptik  fax:
 +49-511-762-2211
 Welfengarten 1, 30167 Hannover
 [3]http://www.iqo.uni-hannover.de
 GPG key:
 [4]http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get
 ___
 geda-user mailing list
 [5]geda-user@moria.seul.org
 [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

References

   1. mailto:kn...@iqo.uni-hannover.de
   2. https://bugs.launchpad.net/pcb/+bug/792139
   3. http://www.iqo.uni-hannover.de/
   4. http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get
   5. mailto:geda-user@moria.seul.org
   6. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: PCB launchpad bugs to mailinglist

[Kai-Martin Knaak]

DJ Delorie wrote:

> 
>> It is nice to have the geda bugs reported on launchpad mirrored in 
>> the mailing list. Can we this also be done for PCB bugs, please? 
> 
> We already do this, but PCB bugs have their own list.  Subscribe to
> pcb-b...@lists.sourceforge.net.

How would I do that (with my news server)? 
gmane does not offer this in their list of usenet groups. 

The geda bug list by contrast can be found on the list:
 http://gmane.org/find.php?list=geda
 http://gmane.org/find.php?list=pcb

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user