Warning: file_exists(): open_basedir restriction in effect. File(/srv/http/vhosts/aur.archlinux.org/public/web/locale//en/LC_MESSAGES/aurweb.mo) is not within the allowed path(s): (/srv/http/vhosts/aur-dev.archlinux.org/:/etc/aurweb/) in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/streams.php on line 90
AUR (en) - microchip-mplabx-bin

Notice: Undefined variable: name in /srv/http/vhosts/aur-dev.archlinux.org/public/web/lib/pkgfuncs.inc.php on line 248

Package Details: microchip-mplabx-bin 3.51-1

Git Clone URL: https://aur-dev.archlinux.org/microchip-mplabx-bin.git (read-only)
Package Base: microchip-mplabx-bin
Description: IDE for Microchip PIC and dsPIC development
Upstream URL: http://www.microchip.com/mplabx
Licenses: custom
Conflicts: mplab
Provides: mplab
Submitter: bxs
Maintainer: mickael9
Last Packager: mickael9
Votes: 46
Popularity: 1.087783
First Submitted: 2011-12-17 04:28
Last Updated: 2017-01-22 17:11

Latest Comments

1 2 3 4 5 6 ... Next › Last »

torkelatgenet commented on 2017-01-17 19:41

==> Validating source files with md5sums...
MPLABX-v3.50-linux-installer.tar ... Passed
LICENSE ... Passed
==> Validating source_x86_64 files with md5sums...
fakechroot-i686.pkg.tar.xz ... FAILED
==> ERROR: One or more files did not pass the validity check!

Im getting this.

potatoe commented on 2016-11-01 22:24

@mickael9: You're right, I didn't realize how much was bundled in with MPLABX. I think just renaming the rules file to something unique to this package, like 99-mplab-jlink.rules, is indeed the best choice.

I agree there shouldn't be any harm with both rules files installed, they're both the same file contents currently, and I think they're just setting a world-writable MODE on the devices anyway.

mickael9 commented on 2016-10-31 20:13

@potatoe: I'm not sure what to do here here and I don't use J-Link.

MPLABX seems to bundle everything that is needed, requiring installation of a a separate package just for the udev rules seems a bit silly unless most users needing J-Link support are most likely to also want jlink-software-and-documentation (you tell me)

One solution would be to rename the jlink rules file so that it doesn't conflict with the one from jlink-software-and-documentation. The rules will be applied twice but this won't cause any harm. What do you think?

potatoe commented on 2016-10-31 18:33

I'd just like to echo @maximevince and say that it would be nice if this package didn't include the file '/etc/udev/rules.d/99-jlink.rules', and instead listed jlink-software-and-documentation as an optdepend for J-Link support. I hit the file conflict every time I try to upgrade, and always have to edit the updated PKGBUILD to rm that file from this package (I prefer to have that file provided by jlink-software-and-documentation on my system).

If you'd rather continue to include the 99-jlink.rules file, could you add a conflicts=(mplab jlink-software-and-documentation)?

It would be helpful to J-Link owners to know about the conflict before downloading and building, instead of only discovering it when it errors out on the package installation. Especially since many AUR helpers seem to delete the package they built when they hit an error during installation, meaning lots of re-downloading and re-building after discovering the conflict.

vinadoros commented on 2016-08-11 18:18

@mickael9 With this new lib32-fakeroot 1.21 PKGBUILD, this mplabx package is now building properly. Thank you for digging into this, I really appreciate it.

mickael9 commented on 2016-08-11 17:16

For anyone getting the dlsym() errors, this is caused by an older lib32-fakeroot (which hasn't been updated to 1.21 in the official repos). Here is a PKGBUILD for a working lib32-fakeroot: https://gist.github.com/mickael9/6ae2b1856560941919ab1534308e52c9

mickael9 commented on 2016-08-11 16:11

@vinadoros: It might be worth researching those dlsym() issues, because I don't have them.

Here is my bitrock_install.log for reference: http://ix.io/1daz
And the MPLABComm one: http://ix.io/1daA

The JRE is correctly extracted into pkg/microchip-mplabx-bin/opt/microchip/mplabx/v3.35/sys/java/jre1.8.0_91/

(That is, with "exit 1" added in the PKGBUILD just after running the installer, before any customization is done)

**EDIT**: Actually, I just updated my system and I have the same errors that you have, I'll try to research those.

vinadoros commented on 2016-08-11 15:49

@mickael9 Thanks for the tip. So I used the Arch Rollback Machine and downgraded using the following package (I don't have it in my own pacman cache): https://archive.archlinux.org/packages/f/fakeroot/fakeroot-1.20.2-1-x86_64.pkg.tar.xz. This means both fakeroot and lib32-fakeroot are 1.20.2-1. After installing this (and a reboot just to be on the safe side), this output occurs (and I have stripped the dlsym fakeroot messages from the output, which there are a lot of):

==> Extracting sources...
-> Extracting MPLABX-v3.35-linux-installer.tar with bsdtar
-> Extracting fakechroot-i686.pkg.tar.xz with bsdtar
==> Entering fakeroot environment...
==> Starting package()...
Extracting installers...
Running MPLABX installer...
Problem running post-install step. Installation may not complete correctly
Error running /opt/microchip/mplabx/v3.35/MPLABCOMM-v3.20.00-linux-installer.run --jrebinary "/opt/microchip/mplabx/v3.35/sys/java/jre1.8.0_91/bin/java":
==> ERROR: A failure occurred in package().

Just to be on the safe side, I tried cloning the MPLAB-X 3.30 PKGBUILD from the AUR (which I know for sure used to work), and used makepkg on it. Similar sort of error:

Problem running post-install step. Installation may not complete correctly
Error running /opt/microchip/mplabx/v3.30/MPLABCOMM-v3.17.02-linux-installer.run --jrebinary "/opt/microchip/mplabx/v3.30/sys/java/jre1.8.0_65/bin/java"

In the pkg/microchip-mplabx-bin/tmp folder of the PKGBUILD, there are bitrock_installer logs which are more descriptive about the problem. I noticed that the jre it is looking for in the above command (1.8.0_91 for 3.35 and 65 for 3.30)is supposed to be unpacked by the installer. I can see this in the bitrock_installer.log:

Unpacking files
Unpacking /opt/microchip/mplabx/v3.30/sys/java/jre-8u65-linux-x64.tar.gz

However, this jre tar remains only a tar file when it gets to the above MPLABCOMM install steps. This suggests to me that something is still wrong with fakeroot (or maybe the lib32 version of fakeroot, which I don't think has changed at all). I have no idea why the MPLAB installer can't extract that inside the fakeroot...

mickael9 commented on 2016-08-11 14:52

@vinadoros I rolled back fakeroot to 1.20.2 and it worked.

I think it might fail because lib32-fakeroot is still at 1.20.2 while fakeroot is at 1.21

vinadoros commented on 2016-08-11 12:12

I'm not able to build this on my Arch x86_64 machine (its a recent clean install, and is up-to-date) for some reason (either with yaourt or makepkg in a place other than /tmp). The stdout log seems to stop at this point:

==> Extracting sources...
-> Extracting MPLABX-v3.35-linux-installer.tar with bsdtar
-> Extracting fakechroot-i686.pkg.tar.xz with bsdtar
==> Entering fakeroot environment...
==> Starting package()...
Extracting installers...
Running MPLABX installer...
dlsym(acl_get_fd): /usr/lib32/libfakeroot/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /usr/lib32/libfakeroot/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /usr/lib32/libfakeroot/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /usr/lib32/libfakeroot/libfakeroot.so: undefined symbol: acl_set_file

The ACL errors are probably not even relevant to whatever issue is occurring. After this, no processes are consuming CPU, and it looks like the MPLAB installer isn't proceeding at all (even after about 30 minutes). Anyone else with this issue? Maybe I am missing some dependency I am not aware of?