Package Details: eagle 7.7.0-1

Git Clone URL: https://aur.archlinux.org/eagle.git (read-only)
Package Base: eagle
Description: A powerful suite for schematic capture and printed circuit board design (aka eaglecad)
Upstream URL: http://www.cadsoft.de/
Licenses: custom
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 236
Popularity: 2.816778
First Submitted: 2008-03-24 12:05
Last Updated: 2016-10-11 18:23

Latest Comments

R00KIE commented on 2015-10-20 17:11

That patch is already in harfbuzz 1.0.6-1 and eagle still crashes so I suppose it is safe to say that it doesn't fix the problem unfortunately.

Hopefully some later release of eagle will not have this problem.

Bevan commented on 2015-10-13 10:13

Hm.. Since it affects at least three people this really seems to be an issue. But I cannot reproduce it. stevenhoneyman posted a patch[1] for harfbuzz on the forums. So maybe that's worth a try.

[1]: http://cgit.freedesktop.org/harfbuzz/commit/?id=26ba4d1e1fb8949632fe08e6a7600badfba4f142

R00KIE commented on 2015-10-12 16:49

For me it crashes when I try to maximize the schematic window, the output on dmesg point to libc-2.22.so somehow being the culprit.

I get:

eagle[20148]: segfault at 9000000088 ip 00007f35b65e0aa4 sp 00007ffe67f49348 error 4 in libc-2.22.so[7f35b6565000+19b000]
eagle[20161]: segfault at 9000000088 ip 00007f2770aa9aa4 sp 00007fffdac16e58 error 4 in libc-2.22.so[7f2770a2e000+19b000]
traps: eagle[20839] general protection ip:7fba61da3b48 sp:7ffcad551470 error:0 in libc-2.22.so[7fba61d2c000+19b000]

71GA commented on 2015-10-11 06:59

It keeps crashing whenever I open schematic or layout...

stevenhoneyman commented on 2015-10-05 20:53

Is anyone having trouble since today with this? It's been fine all weekend, but today if I select a specific part in the library (with the "preview pane"), it crashes. Library works fine on the Windows version, and is my own, not just some random one I found online. freetype2 got an update, but a downgrade back didn't change anything.

EDIT: had to downgrade harfbuzz as well. Will ask on the forums

Bevan commented on 2015-08-14 10:04

Thanks for pointing this out. The issue is that the file has dos linebreaks and since AUR is git-based these are transformed into unix linebreaks which of course alters the checksum.
I will rework this package soon.

kaysimon commented on 2015-08-14 10:00

Build fails because md5sum of the file eagle.xml isn't correct

Bevan commented on 2015-08-09 07:14

Hmm. If people flag this out-of-date although it is not out-of-date I can't do much but unflag it again…

yuyichao commented on 2015-07-08 12:36

@Bevan Feel free to have it.

You can also find the history here[1] but I guess AUR doesn't support history rewrite.

[1] https://github.com/yuyichao/arch-pkg/tree/master/pkg/all/eagle

Bevan commented on 2015-07-08 12:21

I just migrated this package to AUR4. If the original maintainer (yuyichao) wants it back I will transfer the ownership back of course. Otherwise I will keep maintaining it.

stevenhoneyman commented on 2015-05-11 19:11

It starts up and announces that this is out of date, 7.3.0 is released.

JetJaguarXP commented on 2015-03-16 00:18

Thank you so much for this package!!

greyltc commented on 2015-02-07 18:47

The below PKGBUILD for 7.2.0 from @ivanovp gives me:
==> ERROR: PKGBUILD contains CRLF characters and cannot be sourced.
Otherwise it seems to work fine.
I've fixed up the file:
http://hastebin.com/raw/wulosavale

@yuyichao please update this package.

ivanovp commented on 2014-12-15 19:49

PKGBUILD for 7.2.0
http://pastebin.com/mHTnHiNV

Harvie commented on 2014-11-05 17:25

@yuyichao: Well
1.) it works under root but not under user, so problem is with package
2.) i've found it works under regular user when executed directly as /opt/eagle/bin/eagle. so problem is probably in /usr/bin/eagle, which is opensource :)
3.) you can still use strace and similar programs to debug closed source binaries if you need...

yuyichao commented on 2014-10-31 13:34

@Harvie

Unfortunately this is a closed source software and I have no way to tell why it is behaving like that or how to fix it, especially if it does not produce any useful error messages.

If you can somehow use their official install script to produce a workable installation for regular user, I might be able to figure out what's the difference and if there's anything I'm missing for packing. Otherwise, I would suggest asking for help on their forum.

Harvie commented on 2014-10-31 13:27

@yuyichao: no. i've deleted those and they were created again. but it still loops in freeware dialog. even after upgrade from 6.5 to 7.1...

hakunamenta commented on 2014-10-07 19:28

Indeed.
The wrapper in question is pacaur, and I noticed that there is a slight difference in the way dependencies are declared between the examples you mentioned and the PKGBUILD here. For nvidia and skype there is a depends line for all $ARCH and a switch further down. for eagle there are no single depends that are for all $CARCH. My guess is, that pacaur only scans for the first occurrence of depends and stops when it fails to resolve that line. In most cases this probably works just fine only in this rare case not. I will send info to pacaur maintainer.
Thanks for this fine PKGBUILD

hakunamenta commented on 2014-10-07 19:28

Indeed.
The wrapper in question is pacaur, and I noticed that there is a slight difference in the way dependencies are declared between the examples you mentioned and the PKGBUILD here. For nvidia and skype there is a depends line for all $ARCH and a switch further down. for eagle there are no single depends that are for all $CARCH. My guess is, that pacaur only scans for the first occurrence of depends and stops when it fails to resolve that line. In most cases this probably works just fine only in this rare case not. I will send info to pacaur maintainer.
Thanks for this fine PKGBUILD

hakunamenta commented on 2014-10-07 19:27

Indeed.
The wrapper in question is pacaur, and I noticed that there is a slight difference in the way dependencies are declared between the examples you mentioned and the PKGBUILD here. For nvidia and skype there is a depends line for all $ARCH and a switch further down. for eagle there are no single depends that are for all $ARCH. My guess is, that pacaur only scans for the first occurrence of depends and stops when it fails to resolve that line. In most cases this probably works just fine only in this rare case not. I will send info to pacaur maintainer.
Thanks for this fine PKGBUILD

hakunamenta commented on 2014-10-07 19:19

Indeed.
The wrapper in question is pacaur, and I noticed that there is a slight difference in the way dependencies are declared between the examples you mentioned and the PKGBUILD here. For nvidia and skype there is a depends line for all $ARCH and a switch further down. for eagle there are no depends for all $ARCH. My guess is, that pacaur only scans for the first occurrence of depends and stops when it fails to resolve that line. In most cases this probably works just fine only in this rare case not. I will send info to pacaur maintainer.
Thanks for this fine PKGBUILD

yuyichao commented on 2014-10-07 18:56

`$CARCH` is a standard variable. I'm not sure where it is documented but it is used in some official packages[1][2]. I've tested it on my machine locally and it works. You should also try to build it after downloading with makepkg, and all of the dependencies should be in the official repo.

If your AUR helper fetch the dependencies only from the AUR interface rather than from the PKGBUILD itself. It's a bug of the AUR helper. The dependency list on the AUR is generated from .AURINFO, which is in turn generated on a machine with certain architecture. For cases like this that the dependencies are different for different architectures, there's not way (not in the current setup) to make it accurate for both architectures.

[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/nvidia
[2] https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/skype

hakunamenta commented on 2014-10-07 18:02

current dependencies can not be installed on i686 because (excerpt from aur wrapper follows):
:: no results found for lib32-fontconfig
:: no results found for lib32-freetype2
:: no results found for lib32-gcc-libs
:: […]
this is probably because the PKGBUILD uses the var $CARCH which is not defined

hakunamenta commented on 2014-10-07 17:58

current dependencies can not be installed on i686 because (excerpt from aur wrapper follows):
:: no AUR metadata for ruby-systemu package
:: no results found for lib32-fontconfig
:: no results found for lib32-freetype2
:: no results found for lib32-gcc-libs
:: no results found for lib32-libx11
:: no results found for lib32-libxcursor
:: no results found for lib32-libxext
:: no results found for lib32-libxi
:: no results found for lib32-libxrandr
:: no results found for lib32-libxrender
:: no results found for lib32-openssl
:: no results found for lib32-zlib

yuyichao commented on 2014-04-03 04:24

@Harvie

Cannot reproduce.

Is there any error messages? Do you already have ~/.eagle/ and ~/.eaglerc? If you do, what's their owner and permission?

Harvie commented on 2014-04-03 04:06

I've got minor problem with this package...

/usr/bin/eagle works only when run under root (loops in license dialog under regular user)
When i use /opt/eagle/bin/eagle it works as expected...

yuyichao commented on 2014-01-24 12:47

P.S. I didn't bump the pkgrel since there is no need for anyone with the package installed to update.

yuyichao commented on 2014-01-24 12:46

Updated with the additional make dependency.

@trgtylcnky:
A general rule for AUR is you need to install the base-devel group, which include patch. However, I do agree that these dependencies should be explicitly specified (maybe except glibc and gcc) (although it's easy to miss them...).

Also, it is only a make dependency rather than a dependency.

trgtylcnky commented on 2014-01-24 12:39

I think patch should be added to dependencies.

yuyichao commented on 2013-09-06 01:25

@jass0
I did several checks and cannot see where the dependency comes from. Here are what I did.
I checked the output of `objdump -p` on `/opt/eagle/bin/eagle` (and that is how I come up with the dependency list) and icu is not there. It's not even pulled in by other libraries since it does not show up in the output of `ldd` either.
It is true that Qt4 is dlopen'ing icu using its soname if compiled with icu enabled and eagle seems to be statically linking qt4. However after doing a text search in the elf file, I cannot find anything similar either.
The last thing I did was running eagle with icu (in my case lib32-icu) installed and check `/proc/<pid>/maps` and `lsof /usr/lib{,32}/libicu*`. Neither of them shows icu is loaded by eagle.

Where did you find that dependency? Is there anything I am missing or misunderstand here?

Anonymous comment on 2013-09-05 20:17

icu dependency..?

yuyichao commented on 2013-09-01 21:40

Posted on their forum here[1], no idea if it can be merged.... = = ....

[1] http://www.element14.com/community/message/88003

yuyichao commented on 2013-09-01 21:26

I have just uploaded a new version of PKGBUILD. It fixed some stupid bugs in the Chinese translation. The problem doesn't exist in other languages so if you are not using Chinese, feel free to igore it (that's why I didn't bump the $pkgrel).

P.S. anyone know where to report this bug upstream? It's close sourced and I didn't find anywhere obvious on there website to report bugs....

yuyichao commented on 2013-08-07 13:52

Updated to 6.5.0. libpng14 and libjpeg-turbo are both removed from optdepends. I did a simple search in the elf file and it seems that eagle is statically compiled with libpng 1.5 and I suppose it is similar for libjpeg since I cannot find the string "libjpeg" anywhere.

eagle keeps adding random permissions to files/directories (this time setuid). I have removed them in the package. Please tell me if there is any permission related problems that I didn't notice.

Anonymous comment on 2013-08-07 13:09

Hey, flagged out of date, because version 6.5.0 is out:
ftp://ftp.cadsoft.de/eagle/program/6.5/eagle-lin-6.5.0.run

721407ee4011d629c843c4c90d2a5082 eagle-lin-6.5.0.run

paraxor commented on 2013-07-26 04:53

I'm running into a couple of problems with Eagle's licensing.

- When I try to license the program, it says, "Please run EAGLE as administrator to install your license!"
- I ran Eagle as root (in a virtual, throw-away environment). When I attempted to license Eagle, it gave me the error, "Error while decoding license file <keyfile>. Please verify the installation code!" I am fairly certain that the keyfile and installation code are correction.

Has anybody else run into this problem or similar problems?

yuyichao commented on 2013-03-23 22:50

@BotoX:
Reason for flag out-of-date?
I haven't found a new version on the official website. Or is there a dependency problem or sth like this?

Unflag right now, feel free to mark again with a comment for the reason if you think sth is indeed wrong with the package.

yuyichao commented on 2013-02-24 22:06

@ra_fi
Good point. Updated (along with some other fixes). THX.

Anonymous comment on 2013-02-24 21:19

To get a higher resolution program icon (e.g. for gnome3), I would change the Icon line in eagle.desktop to:
"Icon=/opt/eagle/bin/eagleicon50.png"

saabzero commented on 2013-01-09 18:51

Thx for the tips @headcra6 and yuyichao!
Unfortunately the disabling of desktop effects does not solve this problem. Hopefully this will get fixed with a driver update. I'll try some vsync options, if it does not work i'll be using my laptop as a workaround til then!

headcra6 commented on 2013-01-08 20:49

> The well known fact is that both open-source and proprietary drivers sucks... They just suck in different ways....
True that. Fortunately, it finally dawned on me that I've never used anything that utilizes 3D graphics on my machine, so open source driver is the most suitable choice.

yuyichao commented on 2013-01-08 20:38

@headcra6

Well the unfortunate fact is that even if it is a bug in the eagle program, there is nothing I can help with packaging... (The packaging is really simple, extract an archive and it is done......) Luckily, the problem doesn't seem to be there...

There might be some driver options u may want to play with if u still want to use proprietary drivers (vsync and other things that doesn't make sense for me .....). (At least one of my friends had solved a similar problem (with video player) after switching on/off vsync...)

The well known fact is that both open-source and proprietary drivers sucks... They just suck in different ways....

headcra6 commented on 2013-01-08 20:24

Whew, problem solved. After enduring it for so long, I've decided to change catalyst driver for xf86-video-ati.
@saabzero
As you can see, that's how I managed to get rid of those artifacts. But that's kinda radical solution, so maybe try switching off composite first?
@yuyichao
Thanks, it's just as you suggested. Damn proprietary drivers.
Well, it's nice to know that the problem isn't the eagle package.

yuyichao commented on 2013-01-08 19:32

@headcra6 @saabzero
The problem looks like a typical fail-to-synchronize/flush, which may caused by either the graphic card driver and/or the compositor (I haven't experienced such a problem before so not really sure about what exactly it is). You may want to try if the problem remain without composite manager (C-S-F12 to turn off composite in kde), it may be a bug in the program itself if the problem disappear without composite.

Maybe u r interested to report it upstream....

And anyway, whether or not this is a bug in the driver or this close source program itself, there really isn't much I can help with...... (sorry T-T )

saabzero commented on 2013-01-08 19:18

Hi there, i am expiriencing the same problem as described by headcra6.
Using ati hd 6000 series with catalyst-total blobs from aur on kde.
Would appreciate any help on this problem!

yuyichao commented on 2013-01-08 13:59

The package is installed to /opt/eagle instead of /opt/eagle-$pkgver now.

For dependencies, `libjpeg-turbo` and `libpng14` (or the corresponding lib32 package on x86_64) were listed as dependencies but I cannot find them either in the required `.so` files of the executable nor in the files the program uses at runtime. I removed libpng14 and the program runs with no problem (cannot test libjpeg-turbo since it is required by other packages) so I suppose they are not hard dependencies. Since they might be required by some function I didn't notice, I decide to move them to optdeps. Plz let me know if they are not required by anything at all or where they are required. thx.

Just upload two versions within minutes... sorry if that have caused anyone to upgrade twice....

yuyichao commented on 2013-01-08 13:10

@pernix
THX, packaging and checking dependencies

pernix commented on 2013-01-08 13:03

eagle 6.4.0 is out
md5sum is 5e0b4f2864bdbc1677f2897c69ad20a0

headcra6 commented on 2012-11-05 21:33

I've been experiencing some graphical artifacts since the last update.It appears after clicking on main canvas (either in "Board" or "Schematic" window). Basically, it looks like this
http://www.zimagez.com/zimage/screenshot-11062012-012714am.php
http://www.zimagez.com/zimage/screenshot-11062012-013200am.php
Picture becomes normal after zooming in or out.
Does anyone have the same problem? Any ideas how to fix it?

R00KIE commented on 2012-10-18 13:48

Forgot to say that you don't need to use ln -sf, just ln -s, the target directories should be empty therefore no need to force the creation of the link, does no harm either.

R00KIE commented on 2012-10-18 12:15

I did test my changes before posting the patch and rsync seemed to be working fine, but your use of cp does without that extra dependency so it's better.

Here is a new patch [1] with some small modifications.

- Keep your usage of cp, however -r is not needed since it is implied by using -a.
- Use versioned symlink instead of directory, I suppose the directory should not be versioned, no other package I know of has a directory with version (maybe except python but that is a special case). The symlink could go away with the next version since an update would break any links anyway, after the transition links should not break anymore (if anyone needs it).
- Make link for icon in /usr/share/pixmaps and adjust desktop file for that, if you don't want this then you don't need to create the pixmaps directory.
- I suppose you don't really need the TryExec line in the desktop file, if the binary is not there, there is some problem with the user's system or the package.
- I suppose you don't need the exec inside eagle.sh, it works without it, I don't know how other packages that need scrips do it.
- Please consider keeping the line PKGEXT='.pkg.tar', it saves a lot of time when creating the package, if you don't intend to send the package over the internet there is no need to compress it.

[1] http://pastebin.com/7YJWpVs7

yuyichao commented on 2012-10-17 21:52

@ROOKIE

Yes, I also find having to use ~/eagle annoy.

some changes on your patch
1, I use cp instead of rsync, I think it is enough without any additional dependency.
2, I just keep the old versioned directory in /opt and use a symlink for /opt/eagle, just in case someone is expecting the old install path (at least for this version)... (maybe not...)
3, ur use of rsync seems broken(afaik), it will create a subdirectory under .eagle if it exists.

plz test, thx for suggestions.

R00KIE commented on 2012-10-17 20:55

Here's a patch that will make eagle behave a bit more like as expected [1], however I don't know how much you will like it.

Changes:
- No personal lib dir is created, the user can change that later.
- Now the bundled libraries show up when the program starts.
- No more rm -rf, it just seems to be a bad idea to have rm -rf on a script.
- New dependency of rsync, the upside is that it should be faster to start when the version changes and it should leave user added files in place.

http://pastebin.com/HgbJUVm1

yuyichao commented on 2012-10-17 16:49

@ROOKIE
Well neither the install script nor the startup script creates symlinks in ur home dir afaik... so you shouldn't have the problem with this package...

Copying everything every time doesn't sound like a good idea for me either, but since eagle is really doing sth weird (looking for sth systemwide in user directory..... as well as write to this dir) it is a little tricky to do symlinks.... (not hard but basically I cannot simply symlink the directory as a whole) need to find time to do that.

And AFAIK it is eagle's install script that installs the package with the version suffix... so now I will just symlink /opt/eagle to /opt/eagle-$pkgver, hopefully that can help you if u r doing ur own trick.

suggestions/patches welcome.

R00KIE commented on 2012-10-17 14:26

Could you install into /opt/eagle/ instead of /opt/eagle-$pkgver?

Since by default eagle looks for libraries in ~/eagle/lbr, symlinking the libraries in /opt/eagle-$pkgver/lbr into ~/eagle/lbr will break with every update.
Changing the configuration to look for libraries in /opt/eagle-$pkgver/lbr will prevent the user from using personal libraries and copying the libraries in /opt/eagle-$pkgver/lbr into ~/eagle/lbr is also not a good idea because the user would not notice if any library gets updated in the package.

yuyichao commented on 2012-10-10 16:36

@swiftgeek

well it actually does depend on gcc-libs (you can see this by ldd)
although the correct dependency for x86_64 is lib32-gcc-libs (binary for x86) rather than gcc-libs-multilibs (binary for x86_64). Not really sure if it is a direct dependency or pulled in by one of other dependencies (too lazy to check), but since it was here before I will just change the package name rather than remove it.

will soon correct it.

swiftgeek commented on 2012-10-10 16:21

@nboichat: Nothing is building here -.-

swiftgeek commented on 2012-10-10 16:21

gcc-libs-multilib is NOT needed. Having it installed triggers bugs in eagle!

pernix commented on 2012-10-10 11:03

md5sum for eagle 6.3.0 x86_64: 661defb4ae9531e829a96c9aaaa16b0e

Tectu commented on 2012-09-17 09:08

Is this package still broken like a year or two ago when I wanted to try it?
I couldn't use it back then because it f*cked up my entire build chain.

Can I use it without pain?

nboichat commented on 2012-08-19 14:53

Works perfectly on x86_64 architecture if you first run:
# pacman -S gcc-multilib
As indicated there:
https://wiki.archlinux.org/index.php/Arch64_FAQ#Can_I_build_32-bit_packages_for_i686_inside_Arch64.3F

rpodgorny commented on 2012-08-09 17:05

please, be sure to clean up the gcc-libs/multilib mess. shouldn't it be a makedepend instead? is it needed at all? what about lib32-gcc-libs? anyway, i'm running eagle WITHOUT gcc-libs-multilib installed.

Anonymous comment on 2012-08-02 18:53

Oh thanks, that's easy. I trust it won't interfere with the installed libpng15 in any bad way?

yuyichao commented on 2012-08-02 16:28

libpng14 is another aur package. U can use a aur tool like yaourt to download that automatically or u can install it manually if u r using makepkg.

Anonymous comment on 2012-08-02 16:23

Well the package doesn't work (libpng14 not found), but I didn't understand how to fix this, in case it was supposed to be hidden in the other comments here >_>
Any help appreciated.

rpodgorny commented on 2012-07-25 00:52

ha! stupid me! ...anyway, it almost looks like we have the same problem as other distros:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652089

(why on earth don't they at least bundle the libs if they don't want to link statically?)

rpodgorny commented on 2012-07-25 00:38

replaced "gcc-libs-multilib" with "gcc-libs" and "lib32-libpng14" with "lib32-libpng" and it builds. still, i get:

./eagle: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory

swiftgeek commented on 2012-07-07 21:05

Works great with gcc-libs (doesn't need gcc-libs-multilib)

mandos commented on 2012-06-22 12:13

After installing eagle I get the following error:
./eagle: error while loading shared libraries: libpng14.so.14: cannot open shared object file: No such file or directory

However I believe that libpng14 is now libpng15 (right?).

swiftgeek commented on 2012-06-04 11:01

Package is now orphaned… :(

z0id commented on 2012-03-29 18:19

lipng dependency should be changed to libpng14. The libpng version in repos is 1.5 now.

Anonymous comment on 2012-03-14 22:54

@shrimants
You need to have the multilib repo enabled

gcc-multilib allows you to build 32 bit stuff on 64 bit.

Anonymous comment on 2012-03-14 22:20

I'm getting an error: Dependency `gcc-libs-multilib' of `eagle' does not exist. Do I need to have the 32 bit repos enabled to use this?

bbandi commented on 2012-02-14 08:38

I agree with amstan. Also, lib32-libpng14 should be in the depends array.

amstan commented on 2012-02-13 14:23

Could you please change the eagle.sh so it accepts arguments?

Otherwise this happens:
alex@alex-laptop:~% eagle /tmp/ep.brd
install: cannot create directory `/tmp/ep.brd': File exists

And then it puts /tmp/ep.brd in the lib directories setting for some reason.

Kompilator commented on 2012-02-06 08:33

For x86_64 please replace lib32-png with lib32-libpng14.

Anonymous comment on 2011-12-20 17:52

For x86_64 please remove for the depends:
- lib32-libpng12
- lib32-openssl-compat
- lib32-libjpeg6
and add:
- lib32-libjpeg-turbo
- lib32-openssl
- lib32-png

Anonymous comment on 2011-12-19 14:26

v6.0.0 seems to be working fine on x86_64.. I had to delete both ~/.eaglerc and ~/.eagle/ otherwise it would give errors at program startup.
Thanks for maintaining the package!

mortzu commented on 2011-12-13 14:46

updated. hope it works

pernix commented on 2011-12-13 12:23

Version 6.0.0 is out.
md5sum for x86_64 is a3265d222a68c5d7251384063e63e5fc

Anonymous comment on 2011-09-21 21:02

Alas. The error I mention occurs only when on an NFSv4 mount. I still can't explain why it works "by hand". A similar discussion about postgres is here: http://grokbase.com/t/postgresql.org/pgsql-bugs/2009/06/bug-4883-tar-xf-fails-on-nfs4-mounts/257cbrq5uld3hbkkrbangp6vcgcm

Anonymous comment on 2011-09-21 20:48

This package fails to build for me. In particular, I receive the following:

...
/bin/tar: eagle-5.11.0/doc/README_en: Cannot change ownership to uid 507, gid 200: Invalid argument
/bin/tar: eagle-5.11.0/doc: Cannot change ownership to uid 507, gid 100: Invalid argument
/bin/tar: eagle-5.11.0: Cannot change ownership to uid 507, gid 100: Invalid argument
/bin/tar: Exiting with failure status due to previous errors
Error while extracting data from 'eagle-lin-5.11.0.run'
==> ERROR: A failure occurred in build().
Aborting...

Thanks. Jacob

bongo commented on 2011-09-20 19:34

@edenyard yes the current cfg collides with gcc & the various libs but it doesn't hurt to install the multilib versions since that just means additional support for x86. I think it just enables --enable-multilib so your building env works as before. It builds fine after the replacements.

Anonymous comment on 2011-09-14 18:47

This no longer builds with an up-to-date Arch 64-bit system. It requires gcc-libs-multlib which conflicts with the existing gcc-libs. Without gcc-multilib, it seems that the other dependencies (lib32-libjpeg6, lib32-libpng12 and lib-ssl-compatibility) cannot be built either.

Is there any way around this, please?

Anonymous comment on 2010-11-11 21:52

please add lib32-openssl-compatibility and lib32-libpng12 to depends array for x86_64
Thanks

mortzu commented on 2010-11-01 10:49

install it from AUR

Anonymous comment on 2010-11-01 10:39

Does fail to create a working package…


[nils@Eagle eagle]$ makepkg
==> Erstelle Paket: eagle 5.10.0-3 (Mo 1. Nov 11:31:21 CET 2010)
==> Prüfe Laufzeit-Abhängigkeiten...
==> Fehlende Abhängigkeiten:
-> libjpeg6
-> libpng12
-> openssl-compatibility
==> Prüfe Buildtime-Abhängigkeiten...
==> FEHLER: Konnte nicht alle Abhängigkeiten auflösen.

Using '-s' to install dependencys doesn't fix that, because the eagle requires older versions of libpng, libjpeg etc. What to do?

mortzu commented on 2010-06-18 11:01

worksforme

Anonymous comment on 2010-06-18 10:44

Something is wrong with the download path in PKGBUILD:

I get this:
The following sources will be downloaded:
ftp://ftp.cadsoft.de/eagle/program/${pkgver%.*}/eagle-lin-5.10.0.run

Then download fails.

If I substitute ${pkgver%.*} with 5.10 it works.

jcci commented on 2010-06-08 03:47

eagle 5.10.0-1
Incompatible with (lib32-)openssl 1.0.0.a-2.
Install (lib32-)openssl-compatibility 0.9.8-1 from AUR, or better add to dependencies.

Wow, now with Chinese version. Some guys in my company will be pretty happy.
Thanks for maintaining!

Anonymous comment on 2010-04-27 17:13

6,7c6,7
< pkgver=5.9.0
< pkgrel=1
---
> pkgver=5.7.0
> pkgrel=4

20c20
< md5sums=('dc8311b043469a567b40fb87815ab0ef'
---
> md5sums=('0f707d872b67b0a900c7810baebaedb9'

Anonymous comment on 2010-04-13 11:03

6,7c6,7
< pkgver=5.8.0
< pkgrel=1
---
> pkgver=5.7.0
> pkgrel=4
20c20
< md5sums=('39e948ade07fa6e914820c68b9286c35'
---
> md5sums=('0f707d872b67b0a900c7810baebaedb9'

nickoe commented on 2010-04-01 21:36

Version 5.8 has been released