The engrampa port is broken, which by extension also breaks the mate meta port. The issue is a bad package name. And I have a solution. The build stops at "gobject-introspection". Specifically "py27-gobject-2.*...This package is in reality named "py-gobject"...sans the "27" prefix. Here is what is weird. "pkg search" shows up the very name of the package this port is calling for spelled with "py27-gobject". While "whereis py-gobject" fails stating that this port is not found. Yet in reality, once I cd into /usr/ports/devel....I see that "py-gobject" does indeed exist...just not under the name of "py27-gobject". If I manually build py-gobject first, then build engrampa...the build of engrampa proceeds flawlessly, then I can build the rest of Mate. So "pkg" shows it under the old name of "py27-gobject", but in reality it isn't there.....Seems like there may be a package naming problem between the ports, packages, and the build script for engrampa, or a combination of all of the above. Sincerely and respectfully, Dave
Auto-assigned to maintainer gnome@FreeBSD.org
I tested the build on 10.0-amd64, works for me. Can you show how the build breaks for you ? Can you add /etc/make.conf from your system and uname -a ?
These are new systems. Not existing ones. I would suspect that existing systems would build flawlessly as the py-gobject package would already be installed. The issue is when I bring a new system out of the ground as I am doing...not update an existing system. The builds are using FreeBSD 10.0 AMD64 I install the base OS, then update it to the -p9 release. Followed by installing the X server and mate in that order. Kernels are all default. Thanks! Dave
(In reply to Dave from comment #3) > These are new systems. Then the problem should be reproducable with poudriere ? Have you tried that ? If you try it on a fresh install, can you provide a link to a build log on such a system ? Try script ~/build-log cd /usr/ports/archivers/engrampa make install <ctrl-d> and put the build-log up somewhere on a webserver and post the URL here.
> > These are new systems. > > Then the problem should be reproducable with poudriere ? I build it with poudriere, see http://people.freebsd.org/~pi/logs/archivers__engrampa-10a-1412018881.txt looks fine ?
May I recommend removing py27-gobject, or py-gobject (whichever naming convention is used on your system)...and then making sure no vestiges of the package remains on your system....then try to build Mate..... This is how to reproduce the bug.... Sincerely and respectfully, Dave
FYI, I've built four systems from the ground up in as many days for the City. 32 and 64 bit. With the same issue spanning both new systems regardless of bitness...and the same solution works as well..... Then I took my old MSI-U100, and after updating the ports tree...same issue (I was using openbox raw prior to Mate) Thanks! Sincerely and respectfully, Dave
(In reply to Dave from comment #6) > May I recommend removing py27-gobject, or py-gobject (whichever naming > convention is used on your system)...and then making sure no vestiges of the > package remains on your system....then try to build Mate..... This is how to > reproduce the bug.... This is what poudriere builds are doing: They use a clean system and build the port requested. In my case: poudriere testport -j 10a -o archivers/engrampa -n Which version of the ports tree are you using ? I'm using a very recent one (from yesterday).
> Which version of the ports tree are you using ? Have you updated your ports tree using portsnap before you build engrampa ?
I see that bugzilla is missing one of my posts.... I'll rebuild it... Yes....I always update the ports tree immediately before build. IN this case, each of the four systems has had the ports tree refreshed in the last four days before attemping a build. Let me resend the missing post, and you'll see exactly how I build a system to reproduce the issue. Thanks! Sincerely and respectfully, Dave
The definition of "bringing a system out of the ground"...well at least how I do it! a) Customer sends me a brand new PC in box. b) I go into the BIOS and update it with the installed Windows OS. (if applicable) c) I modify the BIOS to use legacy mode and turn off the EFI. d) I boot from the FreeBSD 10.0 Release AMD64 DVD and go into a shell first thing. From the cli I issue "gpart destroy -F /dev/ada0". Then I exit the shell. e) I install FreeBSD normally from the DVD and reboot. I do not install any users at this stage. f) From the cli I issue "freebsd-update fetch install" Followed by a reboot g) On the next boot I rebuild the world following Warren Blocks excellent article: http://www.wonkity.com/~wblock/docs/html/buildworld.html h) Once the rebuilding world process is completed, then I "portsnap fetch extract" i) Then from the cli I "cd /usr/ports/ports-mgmt/portmaster". Followed by "make clean install clean (I know...an extra clean in there..but humor me please) j) I then navigate back into root's home dir and: "portmaster x11/xorg" k) Followed by "portmaster x11/mate" This is where the bug rears it's head. I want to make sure you understand...in my forensics...I am finding differing naming conventions for "py-gobject" vs "py27-gobject" These port name issues span the website, the "pkg search" and the "whereis" utilities. I think the issue is not so much with your build....as it is with inconsistent package naming conventions for py-gobject. The mate port is calling for "py27-gobject"...which doesn't exist in fresh ports that are recently installed from scratch. Instead the package is installed in the ports tree as "py-gobject" If I manually "portmaster devel/py-gobject"...Then after building this one port...I can continue mate's build with "portmaster -R x11/mate"...and all builds, installs, and runs perfectly. Hope this helps! Thanks again. Sincerely and respectfully, Dave
Different resolution since updating ports on 09-OCT-2014. Another new system. Fails at the same place.....Only action taken was to go into the port tree itself for engrampa and make the old way (make install clean) When I did this after Mate failed....evidently some dependency issue was met, because on two new systems today, I was able to continue my buid of Mate without issues. Summary: portmaster x11/mate <Build dies after a while @ engrampa> cd /usr/ports/archivers/engrampa make install clean <builds and installs without issue> cd portmaster -R x11/mate <Followed by Mate complely building without further issue> Sincerely and respectfully, Dave
(In reply to Dave from comment #12) > Different resolution since updating ports on 09-OCT-2014. So: if one uses portmaster, the port does not build sucessfully ? Should we try to find the cause or is the current state of affairs acceptable ?
(In reply to Dave from comment #0) > The engrampa port is broken, which by extension also breaks the mate meta > port. The issue is a bad package name. And I have a solution. > > The build stops at "gobject-introspection". Specifically > "py27-gobject-2.*...This package is in reality named "py-gobject"...sans the > "27" prefix. devel/py-gobject is the port directory name, the installed port or package is called py27-gobject. Which means that it gobject bindings build for python 2.7. Lets take py-gobject3 for example since py-gobject only builds for python 2.7, if we build it agains python 3.3 the package name would be py33-gobject3. Please report the actualy error so we might find out where it fails.
Well, I got frustrated with all the new systems I was provisioning and got tired of fighting with the Mate port. So I went with XFCE and the associated archivers for that DE, and put a custom theme I wrote to make it a close analog to Mate. So I no longer have Mate on my systems, nor on my client's systems, so I can't provide any further details than what I have already provided. My apologies. Sincerely and respectfully, Dave