Mageia forum

The various gEDA packages and a gEDA meta-package are available in the repositories, but the associated PCB package appears to be absent.

Could somebody please confirm that PCB is indeed missing? and does this post constitute a request to get it added?

Thanks
Norm

Generally package requests are filled in bugzilla: https://bugs.mageia.org/enter_bug.cgi?p ... mat=guided
(select "New RPM package request" as Component).

Otherwise, it would have been nice if you would at least have posted what gEDA and PCB are about,
so someone not using these packages could take a look ...

I promised to pick up maintainership for the geda packages already available in mageia. Looking at what needs to be done, I realised that
- upstream there exist no new releases of the packages already available in Mageia and that there are no open bugs,
- but that PCB and gerbv are missing (short summary below).

Before suggesting to include PCB and gerbv into Mageia 2, I wanted to see whether I am the only one seeing this need: apparently I am not, and there was also some discussion in the ml-discuss mailing list some time ago which made positive noises. My opinion is that a distro like Mageia should offer these packages - most other comparable distros do already (also Mdv).

PCB (Printed Circuit Board)
An application that supports the design of printed circuit layouts
- manually (input via mouse and keyboard),
- computer assisted by exploring a data-structure which describes the electronic circuit to be realised as a printed circuit (the data structure can be produced with the "gschem" software, already available in Mageia for drawing electronic circuit schemas)
- the output of PCB are files (several standard formats) that can be directly shipped to a printed circuit manufacturer.

There exist several other software packages that do a similar job, most of them non-free - PCB is in my eyes by far the best choice if you use open software.

Gerbv
An application for viewing and verifying the layout produced by PCB produced in the "Gerber" format (Gerber is the manufacturer of the of the machines that copy the layout to the photo-sensitive pcb source material). A verification step is highly recommendable - if you ship a faulty pcb design to manufacturing, you have lost a couple of hundred Euros


I have - some time back and for my own use - built crudely made gerbv and pcb packages that work. They could be easily picked up and properly built in conformance to Mageia policies (although, not for the latest version of pcb - which has non-resolved important bugs). I have had a look in bugzilla - there appears to be no packaging request so far.

Juergen

Thanks for your detailed reply.

Looking around other fora and distributions repositories I came to the conclusion that Mageia is not the only distro not to include PCB, though why that should be I cannot tell.

Without PCB, I felt that using gEDA was likely to be problematic. Looking for alternatives, I have used Kicad. I feel that this is easier to use for schematics than gEDA. The Kicad layout editor is also easy enough, but I cannot tell how it compares to PCB. If you should decide to include Kicad you should also include the initial component libraries to give new users a reasonable start.

Norm

I had a quick look - looks very attractive. At a first look, the user interface looks superiour - more homogeneity between the different components (and the basic concept of their GUIs might be more "fortunate" than that of geda). I will give it a try. Thanks for the hint !

Plus one for kicad, I've had big problems compiling it on my desktop!

In the meantime I see did some more exploring and see clearer.

Kicad
I took the kicad package from cauldron and backported them locally (on my desktop machine) to Mageia 1 - that allowed to do some serious test usage. For me, kicad did not live up to the expectations I had after reading the specs. 2 main issues:

- The user interface is totally counter-intuitive - but I realise: for me, this is mostly a question of taste. To avoid loosing time, I had checked out several tutorials I had found with google. But even with this guidance, I could not get rid of a taste of clumsiness - probably I am biased since I have used geda PCB for many years.
- Kicad does not run sufficiently stable: several times, while following the steps of the tutorials, kicad simply went away - no error message, no dump, just pffft. What is worse, I did not find a recovery file with the user data I had created so far. After that had happened several times, my goodwill for kicad was used up.

Geda pcb
Even if there is no homgeneity of the user interfaces between gschem and pcb, the interfaces are not really that different - and I certainly prefer the general concept of these interfaces to that of kicad.

I had mentioned problems with the latest release. The people upstream are very responsive. It appears that the plans for a new release of Ubuntu have a timing very similar to those for Mageia 2, and geda pcb is producing a new stable version with all problems fixed that will be available sufficiently soon for trying the new version out in one of the pre-releases of Mageia 2 to come. My experience using geda is rock solid - no shakyness comparable to what I have seen with kicad, and user data are constantly being backed up.

The gerbv package is now in cauldron - with geda pcb I am waiting for the new stable version: as soon as it exists and is tested, it will come to cauldron. I have also locally built and tested the last but one version of pcb (pcb-20100929), but having seen no interest, I did not submit it to become available in the mirrors of Mageia 1 (the packages I built would still need some polishing: getting rid of warning messages appearing during the build). But that could easily be done if somebody wants to try using pcb - say so, I would guess it is a question of something like a week to get it to the mirrors (same thing for having a gerbv package in Mageia 1).

juergen_harms wrote:In the meantime I see did some more exploring and see clearer.

Kicad
I took the kicad package from cauldron and backported them locally (on my desktop machine) to Mageia 1 - that allowed to do some serious test usage. For me, kicad did not live up to the expectations I had after reading the specs. 2 main issues:

Just out of curiosity, is it correct that the whole source tarball for kicad including the documentation is nearly 200MB?
And if it's not sufficiently stable, i suggest dropping it from cauldron, then ...

> Is it correct that the whole source tarball for kicad including the documentation is nearly 200MB?
The source tarball is 53MB (and IMHO that includes the doc)

> And if it's not sufficiently stable, i suggest dropping it from cauldron, then ...
In this thread, there has been interest (or was it only curiosity?) expressed on kicad; offering a choice between equivalent tools is one of the big strengths of Unix. Is kicad equivalent, of sufficient quality? I would not dare to base a thumbs down on my single opinion.

Suggestion: (1) keep kicad in cauldron, (2) ask during Beta (this thread?) if there is still concrete interest in using kicad (and to distinguish between wanting to use and being curious) - if no: drop it before stable is finalised; if yes: keep it and - if this question is still not evidently answered - repeat it when pre-releases for Mageia 3 start. Although kicad started in the 90ties, my impression is that it picked up speed lately and might improve its quality. The availability of kicad and of geda packages in the major distros is at about the same level.

I had a PM exchange with the person who imported kicad: he is ready to maintain kicad (he said he was ready to maintain all the cad packages - we had left that open for the geda-series of packages). Since I had an excellent dialog with the pcb team - submitted a bug, optimised deadlines with them, I think it is better if I keep maintainership for pcb for the time being.

juergen_harms wrote:> And if it's not sufficiently stable, i suggest dropping it from cauldron, then ...
In this thread, there has been interest (or was it only curiosity?) expressed on kicad; offering a choice between equivalent tools is one of the big strengths of Unix. Is kicad equivalent, of sufficient quality? I would not dare to base a thumbs down on my single opinion.

Suggestion: (1) keep kicad in cauldron, (2) ask during Beta (this thread?) if there is still concrete interest in using kicad (and to distinguish between wanting to use and being curious) - if no: drop it before stable is finalised; if yes: keep it and - if this question is still not evidently answered - repeat it when pre-releases for Mageia 3 start.

That was merely a suggestion. And if there's a maintainer willing to care, why not?
Offer the choice, that's a true fact about the philosophy and one of the strengths of *nix.

> ... merely a suggestion...
Your question - and this discussion - has a more than legitimate background: is it an excess of liberalism if anybody with submit permission can quietly add new packages to cauldron (possibly without thinking twice)? shouldnt there at least be some place (mail, etherpad, ...) for documenting that a new package now exists, why it has been put in existance, and who is going to maintain the package? But this is off-topic here, should have its own thread.

Well, as we're a community distro, yes, everybody with commit/submit rights can add new packages. (And i don't think that's an excess of liberalism)
However, everyone able to do so, should be aware of the resposibility which comes with this. I just want to prevent situations from happening
when someone asks later (if there are some issues with that package, or security bugs, or if it only duplicates functionality from other programs,
but does worse than the other programs we already have)
"Why has this been imported in the first place and not thoroughly investigated and pondered."

Whatever, kicad is already imported, and you got a good plan there how to get the relevant data if it's useful to Mageia users or not.
So you care for it and that's whats important in the end

gEDA and KiCAD booth look useable and if you are a hard core Libre user they are the only (and good) choices i think.
I use Eagle which is proprietary but have different version including gratis for hobbyists small designs.
There are also other low cost or free (often in combination with other services) programs, but of them i think only Eagle natively runs on Linux.

BUT Eagle and many other CAD suites lack a viewer to verify the output files for manufacturing.

So a very interesting standalone part of gEDA is the gerber viewer gerbv
Gerbers is the industry standard output format of copper layers etc sent to manufacturers, and this program can also let me see drilling and component placement.

In the past i have installed gerbv on Mandriva, and used it perfectly without problems.
(I use Eagle CAD for the designing, and will continue as although it is a akward program it is good, and it would take time to relearn... )

Now i fetched gerbv-2.6.0 from http://gerbv.gpleda.org/index.html,
pack it up and run ./configure which tells me

Code: Select all

Cairo > 1.2.0 required but not found.
Please review the following errors:
No package 'cairo' found

I already have packages libcairo2 1.10.2 i586 and lib64cairo installed
EDIT: above fixed by installing lib64cairo-devel.
Now i get

Code: Select all

*** GTK >= 2.4.0 is required but was not found.  Please review
the following errors:
No package 'gtk+-2.0' found

I have GTK+2.0 2.24.4-1.mga1 installed.

Any idea?

I got KiCAD installed by simple instructions at http://kicad.sourceforge.net/wiki/Linux
used the http://iut-tice.ujf-grenoble.fr/cao/kic ... ts_doc.tgz
And yes it is a 210 MB huge download for this complete package. (but the sources is only 14 MB)
Needed from mga1 repo: (32 bit) libjpeg62, libcanberra-gtk0

KiCAD have the gerber viewer gerbview

* But it i find the old gEDA gerbv better * (Hope i can get it to run on mga1)

Sidenote: it seems KiCAD have currently more development going on.

morgano wrote:Now i get

Code: Select all

*** GTK >= 2.4.0 is required but was not found.  Please review
the following errors:
No package 'gtk+-2.0' found

I have GTK+2.0 2.24.4-1.mga1 installed.

Any idea?

Try

Code: Select all

urpmi gtk2-devel

Then it installed OK - Thank you doctor.
Now, can anybody tell my why command line urpmi found it, but when i enter gtk2-devel in MCC add/remove programs, only packages with longer names shows up?
(Yes i have both dropdowns set to "all")
Bug?

And i also got lots of warning output:

Code: Select all

[root@svarten morgan]# urpmi gtk2-devel
Argument "2\n2" isn't numeric in numeric lt (<) at /usr/lib/perl5/vendor_perl/5.12.3/MDV/Distribconf.pm line 265.
Argument "2\n2" isn't numeric in numeric ge (>=) at /usr/lib/perl5/vendor_perl/5.12.3/MDV/Distribconf.pm line 532, <$URLS> line 1.
Argument "2\n2" isn't numeric in numeric ge (>=) at /usr/lib/perl5/vendor_perl/5.12.3/MDV/Distribconf.pm line 532, <$URLS> line 1.
Argument "2\n2" isn't numeric in numeric ge (>=) at /usr/lib/perl5/vendor_perl/5.12.3/MDV/Distribconf.pm line 532, <$URLS> line 1.


etc maybe 30 lines total...

morgano wrote:Now, can anybody tell my why command line urpmi found it, but when i enter gtk2-devel in MCC add/remove programs, only packages with longer names shows up?
(Yes i have both dropdowns set to "all")
Bug?

Nope. gtk+2-devel is a virtual Provide, which is taken into account by urpmi. It is no package name, so you won't find it if you search for package names.
This is often a problem when novices try to compile software, and the configure script throws out errors that it needs f.ex. libfoo_bar.
Usually it boils down to searching for the basename of the package and grepping for the corresponding -devel packages (-devel packages contain source code and the libraries which you need to link against with the program you want to compile, after this is done it only needs the library packages to run) like with (for the libfoo_bar example)

Code: Select all

urpmf -f --name foobar | grep devel

or in your particular case

Code: Select all

urpmf -f --name gtk+2 | grep devel

Unfortunately there is no easy way to automatize this, you can only manually apply some heuristics.
Another option would be to log in configure.log files or similar, where you can sometimes see similar messages to "libfoo_bar.1.2.3.so missing."
You can search for particular file names in all currently enabled package repositories via urpmf, so urpmf libfoo_bar.1.2.3.so
would show you in which Mageia package this file is contained, which you need can install then.
If you become familiar with compiling, then you mostly know the relevant, commonly used -devel packages that you need.


For the verbose output, this may be related to recent perl updates or something the like, and should probably be reported
so that this can either be suppressed if it's no problem or fixed in the code if this poses a problem. Anyways,
the relevant maintainer/developer should take a look at this, so please report it.

Gerbv
Can you do with gerbv 2.5.0? As a perparation for making gerbv-2.5.0 avaible in cauldron (it now is), I had packaged and tested it for Mageia 1 - I am using it all the time without problems: the packages are OK for Mageia-1. There are 3 packages: gerbv (240 kB), gerbv-debug (365 kB) and gerbv-examples (470 kB). If you want, I can mail the packages to you, or put them on the server of my lab - do you have bandwith problems?, is i586 ok for you?

I just verified on cauldron: although gerbv 2.5.0 worked when I built in in November, there is now a missing dependency (consequence of the switch to gtk3 ?) - workaround: install libcanberra-gtk0 prior to installing gerbv (no problem with the Mageia-1 version). But I will not fix this, I will immediately go for 2.6.0 on cauldron.

Other geda utilities
A new release of gschem is available upstream, I plan to build it for cauldron in the next few weeks. Also pcb has made a nice new release, but with show-stopper bugs. The upstream people intend to create a stable new release in time for the new releases of Mageia and Ubuntu (both forseen for mid-may) - in case that does not happen, I will try to do some patching.

PS

Anyways, the relevant maintainer/developer should take a look at this, so please report it.

I am the maintainer, but there is no gerbv package in Mageia 1 - not possible to file a bug against it (and, working with 2.5.0, I did not see the problems you had, resp. came upon the solutions suggested in this thread). That is why I propose directly transmitting the packages (a backport would be an overkill, given the low usage)

juergen_harms wrote:Gerbv
Can you do with gerbv 2.5.0? As a perparation for making gerbv-2.5.0 avaible in cauldron (it now is), I had packaged and tested it for Mageia 1 - I am using it all the time without problems: the packages are OK for Mageia-1. There are 3 packages: gerbv (240 kB), gerbv-debug (365 kB) and gerbv-examples (470 kB). If you want, I can mail the packages to you, or put them on the server of my lab - do you have bandwith problems?, is i586 ok for you?

You can just attach them here, just rename them to .txt files.

@ Juergen: Thank you, but i have 2.6.0 working now. Keep up the good work anyways
BTW, I too needed to install libcanberra-gtk0 for it to pass configure.

@ doktor: thank you for the explanation

Us who are not in for compiling other when really needed, just search for what the configure script asks for.
-Would it be wrong to ask for enhancement so also drakrpm handles virtual provides, like it does task-* ?

drakrpm when started in terminal also shows similar verbal drivel as urpmi. I will report later, must go...

morgano wrote:Thank you, but i have 2.6.0 working now.

Than, I think, attaching 1 MB of packages is not justified. In case anybody needs gerbv just say so in this thread (chances are, that I will have gerbv-2.6.0 for Mageia-1 too, that makes testing easier - alpha3 is not yet very "user-friendly").

morgano wrote:Us who are not in for compiling other when really needed, just search for what the configure script asks for.
-Would it be wrong to ask for enhancement so also drakrpm handles virtual provides, like it does task-* ?

drakrpm when started in terminal also shows similar verbal drivel as urpmi. I will report later, must go...

There's no special handling for task-* packages, just a filter to only see those. And i'm not sure rpmdrake should be expanded there.
Because you do compiling in a terminal, why would you fire up rpmdrake to install a package, then switch back to terminal,
try again, fire up rpmdrake - rinse and repeat?
You should learn how to use urpmi properly, it's much faster than rpmdrake and more efficient,
and can even be used in text-only environments. Only advantages, if you ask me.

The verbose output seem to be this https://bugs.mageia.org/show_bug.cgi?id=201 so i added input

I usually fire up another window to get parts needed for the main process, wether it is a CAD part, schematic sub chart, subroutine, or package, and same applies to physical machine building where i prefer working using modules. Or in this case compiling.
I no not want to clutter up main history/drawing/benc etc with subpart work.

Without knowing the delicacies I thought drakrpm could find anything urpmi could. Wrong, obviously - we live and learn

I have now finalised the cad packages (pcb, geda, gerbv) for Mageia 2. There is one issue where I need help:
The pcb and gerbv packages have a dependency on the libcanberra library which, at present. needs to be explicitely required (that should not be necessary, but is in this case). There might be i586 / x86_64 issues. I have done all my tests on i586 - could somebody do a quick check on an x86_64 system to verify that the packages no on the (cauldron) mirror run well on that hardware also? thanks.!

Thank you Jurgen. Quick test on up to date cauldron 64:
I just installed the three packages and suggested dependencies.
I have canberra installed, and if i attempt to remove it i see gerbv and pcb are dependant on it.

gerbv: displays gerber files just fine
geda: yes i can open shematics and symbols examples
pcb: yes i can open example
Are entries for the programs supposed to appear in the KDE menu? I did not find any.