On 04/19/2011 05:17 AM, Felix Ruoff wrote:
> I just want to mention, that Cesar Strauss has written a new
> build-script last year, which he has posted to the launchpad bug 699494
Sorry, it isn't exactly an entirely new build script. Actually, it's
just the regular minipack script, embedded in pcb
On 04/19/2011 04:39 AM, Duncan Drennan wrote:
> A question in this regard - if I rebuild a library (e.g. gtk+) do I
> then need to rebuild all the packages which come after it in the
> build-all.sh script?
It depends. Rebuilding only the library should work when upgrading it to
a newer version, bu
Sorry for jumping into this topic without having read all posts.
I just want to mention, that Cesar Strauss has written a new
build-script last year, which he has posted to the launchpad bug 699494
(https://bugs.launchpad.net/pcb/+bug/699494). Perhaps (I did not have a
test) this patch can hel
>> It might be worth trying to revert the GTK it builds against to 2.16.x
>
> Thanks, I'll try that. I thought it might be GTK related.
>
Hmm, I reverted back to 2.16.6 (which is the same as the previous
build), but still having the same problem. Looks like I am going to
have to roll back each pac
> It might be worth trying to revert the GTK it builds against to 2.16.x
Thanks, I'll try that. I thought it might be GTK related.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On Mon, 2011-04-18 at 10:08 +0200, Duncan Drennan wrote:
> In gschem the menus look correct (icons displayed as expected), but
> the open file dialogue has the same problems.
>
> The last time I compiled everything with minipack it worked without
> any issues (before the pcb-20100929 update).
It
> Please pull from the minipack git repository and try again.
Thanks Cesar. I pulled and compiled again and everything built as
expected (just ran ./build-all.sh and no manual intervention was
required).
I copied the "result" directory across to Windows and then ran
pcb.exe. Windows came up with
On 04/15/2011 06:32 PM, Duncan Drennan wrote:
For a development release, you would need to run "./autogen.sh" or
autoreconf in the pixman source dir to generate ./configure
Did that and now pixman compiles correctly.
I reverted minipack to cross-build a stable release of pixman (0.20.2).
Ne
> For a development release, you would need to run "./autogen.sh" or
> autoreconf in the pixman source dir to generate ./configure
Did that and now pixman compiles correctly. Next challenge is the glib
is failing with this error,
configure: error: Could not find a glib-compile-schemas in your PAT
On Fri, 2011-04-15 at 15:41 +0200, Duncan Drennan wrote:
> I tried to compile, but came up with the following errors:
>
> 1) It could not find the remote files for pixman, so I change the
> recipe source to http://cgit.freedesktop.org/pixman/snapshot (which
> worked for the 0.21.6 sources)
For a
I tried to compile, but came up with the following errors:
1) It could not find the remote files for pixman, so I change the
recipe source to http://cgit.freedesktop.org/pixman/snapshot (which
worked for the 0.21.6 sources)
2) It fails to build pixman with this message,
Configuring pixman...
xar
On 03/27/2011 05:20 PM, Duncan Drennan wrote:
Sure. I'll take the opportunity to update the latest libraries.
I included the mingw pcb patch (already in git) for building the latest
released pcb snapshot with minipack. Enjoy!
If, by any chance, you also want to cross-compile the developer ve
> Sure. I'll take the opportunity to update the latest libraries.
Thanks, I appreciate that. Thanks also for all the effort you have put
into the minipack build system and keeping the gEDA recipes, libraries
etc. up to date - I really appreciate it.
__
On 03/25/2011 05:33 AM, Duncan Drennan wrote:
Would you be able to push the code which builds successfully to the
minipack repo?
Sure. I'll take the opportunity to update the latest libraries.
Regards,
Cesar
___
geda-user mailing list
geda-user@m
> After porting pcb_spawnvp (in src/action.c) to Windows, it built fine on
> Ubuntu using my cross-compiler build script (minipack). I'll work on a
> patch. Fortunately, the Windows API already provides an implementation of
> spawnvp.
I pulled the latest minipack code from the git repo, but I have
On Mon, 2010-10-18 at 18:11 +0100, Richard Barlow wrote:
> On Mon, 2010-10-18 at 19:04 +0200, Stefan Salewski wrote:
> > Looks fine to me.
> >
> > geda.seul.org is now (redirected to) http://www.gpleda.org/index.html
> >
> > There we have PCB under member projects, which gives
> > http://pcb.gple
On Mon, 2010-10-18 at 19:04 +0200, Stefan Salewski wrote:
> Looks fine to me.
>
> geda.seul.org is now (redirected to) http://www.gpleda.org/index.html
>
> There we have PCB under member projects, which gives
> http://pcb.gpleda.org/ where download is from sourceforge.
The first place I would lo
On Mon, 2010-10-18 at 16:50 +0100, Chris Malton wrote:
> DJ Delorie wrote:
> > It's in the usual place :-
> For me, I wouldn't have classed Sourceforge as "the usual place". I'd
> have considered geda.seul.org the usual place
> Is there any chance of somebody updating the website to point to
DJ Delorie wrote:
It's in the usual place :-
For me, I wouldn't have classed Sourceforge as "the usual place". I'd
have considered geda.seul.org the usual place
Is there any chance of somebody updating the website to point to this?
Chris
___
g
On Wed, 2010-09-29 at 22:58 -0400, DJ Delorie wrote:
> It's in the usual place :-)
>
Fine work, many bugs from 2009 snapshot seems to be removed.
While preparing the gentoo ebuild there is still one strange thing: When
I test the toporouter I get files like
surface0.gts
surface1.gts
surface2.gt
On 10/04/2010 01:11 AM, DJ Delorie wrote:
>
>> After porting pcb_spawnvp (in src/action.c) to Windows, it built fine on
>> Ubuntu using my cross-compiler build script (minipack). I'll work on a
>> patch. Fortunately, the Windows API already provides an implementation
>> of spawnvp.
>
> Excelle
DJ Delorie wrote:
> I prefer replacing the scripts already in pcb, to avoid confusion.
+1.
The less places to download. the better.
---<)kaimartin(>---
--
Kai-Martin Knaak tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik fax: +49-511-762
I prefer replacing the scripts already in pcb, to avoid confusion.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On 4/10/2010 01:11, DJ Delorie wrote:
Excellent! If you could put "update the readme and built script for
windows" high on the priority list, it will save us much headache in
the future.
One way would be to directly add my script to the pcb sources. I would
trim it down for building only pcb
> After porting pcb_spawnvp (in src/action.c) to Windows, it built fine on
> Ubuntu using my cross-compiler build script (minipack). I'll work on a
> patch. Fortunately, the Windows API already provides an implementation
> of spawnvp.
Excellent! If you could put "update the readme and built s
On 09/29/2010 11:58 PM, DJ Delorie wrote:
If someone can get the mingw builds working again, I'd appreciate that
- neither the win32/build_pcb script nor a fedora mingw cross compiler
work for me.
After porting pcb_spawnvp (in src/action.c) to Windows, it built fine on
Ubuntu using my cross-co
Stefan Salewski wrote:
>> Frequent releases are good for the project.
>
> I think more important is, that the releases/snapshots are free from
> serious bugs.
The imperative "Release early, release often" is a key to successful open
source projects. More details here:
http://en.wikipedia.org/w
> How are you developers going to deal with this?
By bringing in more developers, I hope :-)
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On Fri, 2010-10-01 at 23:06 +0200, Kai-Martin Knaak wrote:
> DJ Delorie wrote:
>
> > Perhaps frequent "patch" releases on this source base would make
> > sense.
>
> Sure.
> Frequent releases are good for the project.
I think more important is, that the releases/snapshots are free from
serious b
DJ Delorie wrote:
> Perhaps frequent "patch" releases on this source base would make
> sense.
Sure.
Frequent releases are good for the project.
But the bottleneck seems to be screening and either reject or apply patches
in the first place. See the patches that hit the list this week. How are yo
I suggest we give this release a few weeks stress-test, then do
another late October, focusing on bug fixes. I'd like to make it
build for windows much easier too. After Oct 17th I'll have more time
for it anyway.
Perhaps frequent "patch" releases on this source base would make
sense. Every 2-
Great!
Now let me suggest some kind of "Patchlevel 0".
Most of these patches deal with well-known issues
discussed on the list or on the tracker; some of them
are years old.
Of course, there are lots of more patches e.g. on the tracker;
I just randomly picked some obvious ones that were not lik
32 matches
Mail list logo
