FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ devel/pear-PHP_CodeSniffer | 1.5.4 | 2.1.0 +-+ devel/ucommon | 6.1.11 | 6.3.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Audacious and GTK3
Hello. I've recently updated Audacious and see it switched to GTK3. Since that, I've got a few problems... A) Some icons won't show up: those on he left of the progress bar are fine, but the three on the right won't display, and I get three missing link icons. The same happens in the tab titles. B) Toggles in menus won't show up: as an example to show what I mean, I can hit Ctrl-M to enable Stop After This Song and the same can be done from Playback menu; however, when looking in that menu, there is no tick near this option, so there is no way to know if it is enabled or not. C) Clicking on an empty space in the menu bar starts moving the window; I can press Esc to cancel this nuisance, but the mouse icon will still be the movement one (two crossing arrows), until I click somewhere. There seem to be an Ubuntu bug report about this: https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/1001936 I'm not sure this applies to me however (I'm using XFCE4). Is there any way to solve the above bugs or switch back to GTK2 (short of downgrading Audacious)? bye Thanks av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
HHVM
Hi It is possible porting to FreeBSD this fork of php ? https://github.com/facebook/hhvm/wiki/Getting-Started In my opinion FreeBSD without this software may a lot of losing. Regards ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for instance always builds N targets instead of building just the desired TARGET/TARGET_ARCH combo. It's not very easy, at least not without breaking various parts of our fragile build system, but I surely want to put something like this on the TODO list for *after* the import has completed. The branch is making progress right now, and I would not want to complicate matters further by introducing yet another tricky feature. :) - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. A more interesting case would be to remodel the build system so it can use one toolchain (external, or pkg-ng'd, maybe?) for building an entire universe. With clang, that should be relatively easy to do. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 6:34 AM, owner-freebsd-...@freebsd.org wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? Only people working on a single binary of clang to build all architectures are interested, which is a vanishingly small number. There’s little point to build this stuff even for hard-core developers. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 6:02 AM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for instance always builds N targets instead of building just the desired TARGET/TARGET_ARCH combo. It's not very easy, at least not without breaking various parts of our fragile build system, but I surely want to put something like this on the TODO list for *after* the import has completed. The branch is making progress right now, and I would not want to complicate matters further by introducing yet another tricky feature. :) The build system isn’t so much the issue, but you wind up with files that refer to all the architectures. But this is a request for a new feature, not quite in scope for a compiler upgrade. - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. This is a new feature. Various people have tried in the past to implement it and compiling just the mips files on mips is straight forward. However, convincing clang to not reference the other architectures requires more sophistication than we currently have in the clang build process. A more interesting case would be to remodel the build system so it can use one toolchain (external, or pkg-ng'd, maybe?) for building an entire universe. With clang, that should be relatively easy to do. Another useful new feature. The hard part with this is getting all the fiddly bits in the tree that depend on default CC producing proper binaries to cooperate.. Doable, but that’s a lot of universe builds. And today it isn’t very practical because sparc64 and mips are broken... Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On 18 Dec 2014, at 14:34, Robert Huff wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? It's not a simple switch, at least not now. If you use the upstream build system for llvm, e.g. autoconf or CMake, it has an option to select all the architectures that are supported. Several config files are then generated differently, and parts of the target support subdirectories are selectively enabled or disabled. In fact, we already build just a subset of the available architectures, since FreeBSD only supports about 5 of them. We can probably arrange for a more minimal configuration in our build system, but since the build time saved is quite small, I don't think it makes much sense in complicating our build system even further. If people are really so interested in shaving off a little, for more complication, that is fine with me. But unfortunately, I have too many tasks on my plate right now, and I cannot work on it. Besides, doing such a new feature now would interfere with the current branch work. Also, after the 3.5.0 import, there are much more interesting fish to fry, in my opinion. For example, importing newer versions of libc++ and compiler-rt, which can bring address sanitizer support, etc. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
This is excellent news Dimitry! On Dec 16, 2014, at 12:36 PM, Dimitry Andric d...@freebsd.org wrote: On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64 have been tested through make universe, and everything should compile and run. * Little-endian ARM builds should now compile and run, thanks to Andrew Turner for putting in lots of work. * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. I know Andrew doesn’t have the right arm gear to do this test, and emulation environments that run FreeBSD have had poor big-endian support for arm. * PowerPC64 should mostly work, thanks to Justin Hibbits. * PowerPC32 might start working soon; it really needs some backporting of fixes to clang 3.4.1, which is now in head, so there is an easier upgrade path for PowerPC users. * Sparc64 still does not work, and I don't see any quick solutions to it for now. It should probably stay with gcc. * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. * Another ports exp-run was done [3], after fixing the problem with lang/gcc, which lead to many skipped dependent ports. * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. Will users of our stable branch have code similar to the code that caused problems? One warning flag about your upgrade to the stable branch would be if there’s a significant number of user-written programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there’s a good chance we won’t find them until users hit them and start to complain (by which point it is likely too late). Could you post a summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. I would really like to merge this branch to head in about a week, pending portmgr approvall; I don't expect the base system (outside of llvm/clang) to need any further updates. I think there’s good reason to do this, but we should chat about the build issues below before doing it. They are minor, but an important detail. I’ll see if I can find a few minutes to pull the branch and send patches. Lastly, to clear things up about the requirements for this branch (and thus for head, in a while); to build it, you need to have: * A C++11 capable host compiler, e.g. clang = 3.3 or later, or gcc = 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) * A C++11 standard library, e.g. libc++, or libstdc++ from gcc = 4.8. So from any earlier standard 10.x or 11.x installation, you should be good, unless you explicitly disabled clang or libc++. In that case, you must build and install both of those first. This is true only on i386, amd64, and arm hosts. Given that some people do try to do weird things, tightening up how you present this will get the word out a little better. On a 9.x installation, you will have clang by default, but not libc++, so libc++ should be built and installed first, before attempting to build the clang350-import branch. Can you make sure that the UPDATING entry you are writing for this contains explicit instructions. On 8.x an earlier, you need to upgrade to at least 9.x first, follow the previous instruction. We should remove building on 8 support then, unless there external toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc). As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while (roughly a month), but this will cause upgrades from 9.x to 10.x to start requiring the build of libc++, as described above. I don't think we can merge clang 3.5.x to 9.x, unless clang becomes the default compiler there (but that is very unlikely). Let’s see how it goes, and what the upgrade issues wind up being before doing this merge back. New “major” compilers on stable branches traditionally haven’t been done, but if clang is
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 7:44 AM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 14:34, Robert Huff wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? It's not a simple switch, at least not now. If you use the upstream build system for llvm, e.g. autoconf or CMake, it has an option to select all the architectures that are supported. Several config files are then generated differently, and parts of the target support subdirectories are selectively enabled or disabled. In fact, we already build just a subset of the available architectures, since FreeBSD only supports about 5 of them. We can probably arrange for a more minimal configuration in our build system, but since the build time saved is quite small, I don't think it makes much sense in complicating our build system even further. If people are really so interested in shaving off a little, for more complication, that is fine with me. But unfortunately, I have too many tasks on my plate right now, and I cannot work on it. Besides, doing such a new feature now would interfere with the current branch work. With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. Creating a hack to do this is easy (which is how I measured it). But Dimitry is right that creating a robust solution is hard. Even harder if you want it to be completely clean. Also, after the 3.5.0 import, there are much more interesting fish to fry, in my opinion. For example, importing newer versions of libc++ and compiler-rt, which can bring address sanitizer support, etc. I tend to agree. IMHO, supporting the work going on to bring the meta-mode stuff will pay far higher dividends than optimizing this corner of the build. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: HHVM
On Thu, Dec 18, 2014 at 6:05 AM, Michał Jędrzejczak jedrzejczak.mic...@gmail.com wrote: Hi It is possible porting to FreeBSD this fork of php ? https://github.com/facebook/hhvm/wiki/Getting-Started In my opinion FreeBSD without this software may a lot of losing. There was a port of this which was removed due to lack of maintainer duties. Are you volunteering to fulfill this? https://github.com/facebook/hhvm/wiki/Building%20and%20installing%20HHVM%20on%20FreeBSD%20from%20ports http://www.freshports.org/lang/hiphop-php/ -- Adam ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Audacious and GTK3
Andrea Venturoli m...@netfence.it writes: I've recently updated Audacious and see it switched to GTK3. Since that, I've got a few problems... A) Some icons won't show up: those on he left of the progress bar are fine, but the three on the right won't display, and I get three missing link icons. The same happens in the tab titles. Do you use default icon theme? If so it needs to be manually installed. The issue is common for any gtk30 app. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195455 B) Toggles in menus won't show up: as an example to show what I mean, I can hit Ctrl-M to enable Stop After This Song and the same can be done from Playback menu; however, when looking in that menu, there is no tick near this option, so there is no way to know if it is enabled or not. A consequence of the above issue. Don't confuse with similar issue that often happens with apps not supporting :checked since gtk-3.14. - VFEmail.net - http://www.vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Audacious and GTK3
On 12/18/14 13:10, Jan Beich wrote: Do you use default icon theme? If so it needs to be manually installed. The issue is common for any gtk30 app. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195455 B) Toggles in menus won't show up: as an example to show what I mean, I can hit Ctrl-M to enable Stop After This Song and the same can be done from Playback menu; however, when looking in that menu, there is no tick near this option, so there is no way to know if it is enabled or not. A consequence of the above issue. Don't confuse with similar issue that often happens with apps not supporting :checked since gtk-3.14. Thanks. Both issues were solved by installing adwaita-icon-theme; I agree that should be a dependency (of audacious at least, if not of gtk3). I'm still trying to solve the third issue. bye av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Audacious and GTK3
On Thu, 18 Dec 2014 13:10:07 +0100 Jan Beich jbe...@vfemail.net wrote: Andrea Venturoli m...@netfence.it writes: I've recently updated Audacious and see it switched to GTK3. Since that, I've got a few problems... A) Some icons won't show up: those on he left of the progress bar are fine, but the three on the right won't display, and I get three missing link icons. The same happens in the tab titles. Do you use default icon theme? If so it needs to be manually installed. The issue is common for any gtk30 app. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195455 B) Toggles in menus won't show up: as an example to show what I mean, I can hit Ctrl-M to enable Stop After This Song and the same can be done from Playback menu; however, when looking in that menu, there is no tick near this option, so there is no way to know if it is enabled or not. A consequence of the above issue. Don't confuse with similar issue that often happens with apps not supporting :checked since gtk-3.14. For GTK3 applications with Xfce, you must install x11-themes/gnome-themes-standard and change value of /Net/ThemeName property: xfconf-query -c xsettings -p /Net/ThemeName \ -t string -s Adwaita Or install x11-themes/clearlooks-phenix-theme (GTK and xfwm4 themes). Since GTK 3.10, new widgets have been added, especially GtkPopover, GtkFlowBox, GtkActionBar and GtkHeaderBar, which are not well displayed with GTK2 theme. In Xfce repository, we are ready to replace current default icon theme by misc/gnome-icon-theme. It won't be x11-themes/adwaita-icon-theme, because Thunar and some specific Xfce's widgets still use stock icons (these are macros in GTK toolkit) which are deprecated since GTK 3.10 and not available in this icon theme. - VFEmail.net - http://www.vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- olivier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Audacious and GTK3
On 18-12-2014 16:39, Andrea Venturoli wrote: On 12/18/14 13:10, Jan Beich wrote: Do you use default icon theme? If so it needs to be manually installed. The issue is common for any gtk30 app. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195455 B) Toggles in menus won't show up: as an example to show what I mean, I can hit Ctrl-M to enable Stop After This Song and the same can be done from Playback menu; however, when looking in that menu, there is no tick near this option, so there is no way to know if it is enabled or not. A consequence of the above issue. Don't confuse with similar issue that often happens with apps not supporting :checked since gtk-3.14. Thanks. Both issues were solved by installing adwaita-icon-theme; I agree that should be a dependency (of audacious at least, if not of gtk3). I'm still trying to solve the third issue. bye av. adwaita-icon-theme will be a run_dep of gtk3 in the next update. I was under the impression that it already was, but it got apparently lost in transition. -Koop ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Perl update failure
After today's update to Perl, following the instructions in UPDATING, I have an important script that dies because it can't find Class/Load.pm. I can confirm that the file no longer is present in /usr/local/lib/perl5. This module is used by p5-Crypt-Random-Source-0.10. It results in the following error: Can't locate Class/Load.pm in @INC (you may need to install the Class::Load module) (@INC contains: /usr/local/lib/perl5/site_perl/mach/5.18 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.18/mach /usr/local/lib/perl5/5.18 /usr/local/lib/perl5/site_perl/5.18 /usr/local/lib/perl5/site_perl/5.18/mach .) at /usr/local/lib/perl5/site_perl/Crypt/Random/Source/Factory.pm line 5. I thought it unlikely to work any better, but I tried re-building the port and got n even moe disturbing report: *** WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING *** If you're seeing this warning, your toolchain is really, really old* and you'll almost certainly have problems installing CPAN modules from this century. But never fear, dear user, for we have the technology to fix this! If you're using CPAN.pm to install things, then you can upgrade it using: cpan CPAN If you're using CPANPLUS to install things, then you can upgrade it using: cpanp CPANPLUS If you're using cpanminus, you shouldn't be seeing this message in the first place, so please file an issue on github. If you're installing manually, please retrain your fingers to run Build.PL when present instead. This public service announcement was brought to you by the Perl Toolchain Gang, the irc.perl.org #toolchain IRC channel, and the number 42. * Alternatively, you are doing something overly clever, in which case you should consider setting the 'prefer_installer' config option in CPAN.pm, or 'prefer_makefile' in CPANPLUS, to 'mb and '0' respectively. You can also silence this warning for future installations by setting the PERL_MM_FALLBACK_SILENCE_WARNING environment variable. What the heck is going on here? How to I get my random number generator back! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
current ports/converters/recode missing / wrong recode-3.6.tar.gz
Hi de...@freebsd.org Maintainer of ports/converters/recode with svn_revision 374898 distinfo has: SHA256 (recode-3.6.tar.gz) = a9beecec22be42b1096de74d4dfb1051fa9cd252e4ae149d8aa6b5243d729e5e SIZE (recode-3.6.tar.gz) = 1760172 Which I cant find, so I used: SHA256 (recode-3.6.tar.gz) = e3e6a4f3f8e5c6052ab70155990c074d87aa0b614fc1be31d194750d1d962fcf 1751886 Jan 22 2001 recode-3.6.tar.gz Then I hit: === Extracting for recode-3.6_12 = SHA256 Checksum OK for recode-3.6.tar.gz. cp: /data/release/11.0-CURRENT/usr/ports/converters/recode/work/pinard-Recode-2127b34/i18n: No such file or directory *** Error code 1 Cheers, Julian -- Julian Stacey, BSD Linux Unix'78 C Sys Eng Consultant Munich http://berklix.com Indent previous with . Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
pkg install from local poudriere repo creates links to txz
I build my binaries in poudriere, then run pkg upgrade -r myrepo Before running upgrade, the repo is clean. After executing pkg upgrade (or install) all, processed files by the command get a sym-link pointing to the actual file. For example: mariadb55-client-5.5.40-058c8a2d74.txz mariadb55-client-5.5.40.txz - mariadb55-client-5.5.40-058c8a2d74.txz The sym-link breaks further poudriere runs, with poudriere complaining that the sym-link file does not exist. Only way to get poudriere to make a run is to manually unlink all sym-links in the repo. My environment has no PKG* related settings. How does one correct this? Regards. -- FreeBSD_amd64_11-Current_RadeonKMS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On 18 Dec 2014, at 15:47, Warner Losh i...@bsdimp.com wrote: ... * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. Yes, and it could even be one of the ports, if that is easier to use. * Another ports exp-run was done [3], after fixing the problem with lang/gcc, which lead to many skipped dependent ports. * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. Will users of our stable branch have code similar to the code that caused problems? I'm not sure which code you are referring to here, the openjdk6 code? The code itself is basically fine, but for reasons unknown to me, the port is compiled with -Werror (which is not the case for the other openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings for shaky C++ constructions, these appear during the openjdk6 build, but they are easily suppressed, if upstream does not fix them, or does not care to fix them. I already sent Jung-uk an alternative fix for openjkd6, similar to the one used for www/squid, where warnings are suppressed based on the COMPILER_VERSION variable provided the ports infrastructure. In my opinion it would still be easier to just to turn off -Werror for any third-party code, if we don't feel like modifying it (with all the risks involved). One warning flag about your upgrade to the stable branch would be if there’s a significant number of user-written programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there’s a good chance we won’t find them until users hit them and start to complain (by which point it is likely too late). Could you post a summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. The base system is already completely free of warnings, as far as I know of, so no action is needed there. For ports, the number of failures introduced by new warnings are quite small, as far as I can see, and mostly for ports that are compiled with -Werror. The most encountered new warnings are, off the top of my head: -Wabsolute-value This warns in two cases, for both C and C++: * When the code is trying to take the absolute value of an unsigned quantity, which is effectively a no-op, and almost never what was intended. The code should be fixed, if at all possible. * When the code is trying to take the absolute value, but the called abs() variant is of the wrong type, which may lead to truncation. If the warning is turned off, better make sure any truncation does not lead to unwanted side-effects. -Wtautological-undefined-compare and -Wundefined-bool-conversion These warn when C++ code is trying to compare 'this' against NULL, while 'this' should never be NULL in well-defined C++ code. However, there is some legacy (pre C++11) code out there, which actively abuses this feature, which was less strictly defined in previous C++ versions. Squid does this, and apparently openjdk too. The warning can be turned off for C++98 and earlier, but compiling the code in C++11 mode might result in unexpected behavior, for example the unreachable parts of the program could be optimized away. I would really like to merge this branch to head in about a week, pending portmgr approvall; I don't expect the base system (outside of llvm/clang) to need any further updates. I think there’s good reason to do this, but we should chat about the build issues below before doing it. They are minor, but an important detail. I’ll see if I can find a few minutes to pull the branch and send patches. Lastly, to clear things up about the requirements for this branch (and thus for head, in a while); to build it, you need to have: * A C++11 capable host compiler, e.g. clang = 3.3 or later, or gcc = 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) * A C++11 standard library, e.g. libc++, or libstdc++ from gcc = 4.8. So from any earlier standard 10.x or 11.x installation, you should be good, unless you explicitly disabled clang or libc++. In that case, you must build and install both of those first. This is true only on i386, amd64, and arm hosts. Given that some people do try to do weird things, tightening up how you present this will get the word out a little better. On a 9.x installation, you will have clang by
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 5:02, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for instance always builds N targets instead of building just the desired TARGET/TARGET_ARCH combo. It's not very easy, at least not without breaking various parts of our fragile build system, but I surely want to put something like this on the TODO list for *after* the import has completed. The branch is making progress right now, and I would not want to complicate matters further by introducing yet another tricky feature. :) Fair enough :). - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Yes. If make tinderbox could use this it would be useful, otherwise, for most folks it seems like a less interesting feature. A more interesting case would be to remodel the build system so it can use one toolchain (external, or pkg-ng'd, maybe?) for building an entire universe. With clang, that should be relatively easy to do. Agreed. bdrewery is working on something similar to that internally for Isilon. Building the same toolchain N times internally when building the system and your upstream revision of FreeBSD doesn’t change is like testing your sanity — not much changes with the bootstrap compiler/toolchain then! Thanks for the reply :)! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: current ports/converters/recode missing / wrong recode-3.6.tar.gz
Hi! with svn_revision 374898 distinfo has: SHA256 (recode-3.6.tar.gz) = a9beecec22be42b1096de74d4dfb1051fa9cd252e4ae149d8aa6b5243d729e5e SIZE (recode-3.6.tar.gz) = 1760172 Which I cant find, so I used: Hmm, I tried to fetch it, works fine from https://codeload.github.com/pinard/Recode/legacy.tar.gz/v3.6?dummy=/recode-3.6.tar.gz -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 6:51, Warner Losh i...@bsdimp.com wrote: With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. I’m curious. How much is 10% in terms of minutes and with what -j value? Creating a hack to do this is easy (which is how I measured it). But Dimitry is right that creating a robust solution is hard. Even harder if you want it to be completely clean. It didn’t seem incredibly hard — it just required a bit more “generated files” in clang AFAICT. I’ll hang ten until clang35 is in so I can re-asses what’s going on with building it. I tend to agree. IMHO, supporting the work going on to bring the meta-mode stuff will pay far higher dividends than optimizing this corner of the build. True… probably will! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 12:01 PM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 15:47, Warner Losh i...@bsdimp.com wrote: ... * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. Yes, and it could even be one of the ports, if that is easier to use. * Another ports exp-run was done [3], after fixing the problem with lang/gcc, which lead to many skipped dependent ports. * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. Will users of our stable branch have code similar to the code that caused problems? I'm not sure which code you are referring to here, the openjdk6 code? The code itself is basically fine, but for reasons unknown to me, the port is compiled with -Werror (which is not the case for the other openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings for shaky C++ constructions, these appear during the openjdk6 build, but they are easily suppressed, if upstream does not fix them, or does not care to fix them. I meant “similar code to what’s causing problems” with the build run in their code they build on FreeBSD. If it is a few new warnings for obscure things, we can advice to the release notes about what to avoid and how to mitigate things. I already sent Jung-uk an alternative fix for openjkd6, similar to the one used for www/squid, where warnings are suppressed based on the COMPILER_VERSION variable provided the ports infrastructure. In my opinion it would still be easier to just to turn off -Werror for any third-party code, if we don't feel like modifying it (with all the risks involved). Yea, we can sort out the code in src and ports. I’m more worried about what to tell our users that may be compiling their own code that we don’t control. If these new warnings are ubiquitous, then that could be a problem for adoption (since many shops mandate -Werror as much as possible, and to comply with that mandate would require additional resources when trying to upgrade). If there are a few, then we could just document them and move on. One warning flag about your upgrade to the stable branch would be if there’s a significant number of user-written programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there’s a good chance we won’t find them until users hit them and start to complain (by which point it is likely too late). Could you post a summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. The base system is already completely free of warnings, as far as I know of, so no action is needed there. For ports, the number of failures introduced by new warnings are quite small, as far as I can see, and mostly for ports that are compiled with -Werror. Yea, I wasn’t too worried about this aspect of things. The most encountered new warnings are, off the top of my head: -Wabsolute-value This warns in two cases, for both C and C++: * When the code is trying to take the absolute value of an unsigned quantity, which is effectively a no-op, and almost never what was intended. The code should be fixed, if at all possible. * When the code is trying to take the absolute value, but the called abs() variant is of the wrong type, which may lead to truncation. If the warning is turned off, better make sure any truncation does not lead to unwanted side-effects. -Wtautological-undefined-compare and -Wundefined-bool-conversion These warn when C++ code is trying to compare 'this' against NULL, while 'this' should never be NULL in well-defined C++ code. However, there is some legacy (pre C++11) code out there, which actively abuses this feature, which was less strictly defined in previous C++ versions. Squid does this, and apparently openjdk too. The warning can be turned off for C++98 and earlier, but compiling the code in C++11 mode might result in unexpected behavior, for example the unreachable parts of the program could be optimized away. This is the kind of information I was talking about. Do we have a process to make sure this gets into the release notes? I would really like to merge this branch to head in about a week, pending portmgr approvall; I don't expect the base system (outside of llvm/clang) to need any further updates. I
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 2:17 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Dec 18, 2014, at 6:51, Warner Losh i...@bsdimp.com wrote: With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. I’m curious. How much is 10% in terms of minutes and with what -j value? That depends on how long the build takes. For my 20 minute builds it was about 2 minutes faster. At the time, -j didn’t really effect build times once you got north of 4 because parallelism really sucked. Now it doesn’t suck and it scales much better and I suspect that the time savings would be tiny because it would be done at the same time as other things anyway, but I’ve not measured it directly. Creating a hack to do this is easy (which is how I measured it). But Dimitry is right that creating a robust solution is hard. Even harder if you want it to be completely clean. It didn’t seem incredibly hard — it just required a bit more “generated files” in clang AFAICT. I’ll hang ten until clang35 is in so I can re-asses what’s going on with building it. Yea, and that file generation is a pita, or I’d have committed my changes a while ago... I tend to agree. IMHO, supporting the work going on to bring the meta-mode stuff will pay far higher dividends than optimizing this corner of the build. True… probably will! Yea, this isn’t a problem worth solving today. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: current ports/converters/recode missing / wrong recode-3.6.tar.gz
Kurt Jaeger wrote: Hi! with svn_revision 374898 distinfo has: SHA256 (recode-3.6.tar.gz) = a9beecec22be42b1096de74d4dfb1051fa9cd252e4ae149d8aa6b5243d729e5e SIZE (recode-3.6.tar.gz) = 1760172 Which I cant find, so I used: Hmm, I tried to fetch it, works fine from https://codeload.github.com/pinard/Recode/legacy.tar.gz/v3.6?dummy=/recode-3.6.tar.gz Thanks Kurt! That worked, installed :-) Previously my proxy (Apache) had rejected fetch with: Authentication error I then had searched various sites with wrong SHA256 SIZE. The URL with firefox via my proxy puts right data in wrong name pinard-Recode-v3.6-0-g2127b34.tar.gz some firefox feature perhaps ? Avoiding a proxy, fetch gets right SHA256 SIZE name, so I have to fix or replace my apache proxy. Cheers, Julian -- Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com Indent previous with . Interleave reply paragraphs like a play script. Send plain text, not quoted-printable, HTML, base64, or multipart/alternative. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
INDEX build failed for 8.x
INDEX build failed with errors: Generating INDEX-8 - please wait..--- describe.accessibility --- --- describe.arabic --- --- describe.archivers --- --- describe.astro --- --- describe.audio --- --- describe.benchmarks --- --- describe.biology --- --- describe.cad --- --- describe.chinese --- --- describe.comms --- --- describe.converters --- --- describe.databases --- --- describe.deskutils --- --- describe.devel --- --- describe.dns --- --- describe.editors --- --- describe.emulators --- --- describe.finance --- --- describe.french --- --- describe.ftp --- [...] --- describe.print --- --- describe.russian --- --- describe.science --- --- describe.security --- --- describe.shells --- --- describe.sysutils --- --- describe.textproc --- --- describe.ukrainian --- --- describe.vietnamese --- --- describe.www --- --- describe.x11 --- --- describe.x11-clocks --- --- describe.x11-drivers --- --- describe.x11-fm --- --- describe.x11-fonts --- --- describe.x11-servers --- --- describe.x11-themes --- --- describe.x11-toolkits --- --- describe.x11-wm --- Done. make_index: /home/indexbuild/tindex/ports/www/mod_spdy: no entry for /home/indexbuild/tindex/ports/lang/clang32 Committers on the hook: antoine bdrewery brooks cy des jkim pawel robak Most recent SVN update was: Updating '.': UMOVED Uchinese/libreoffice-zh_CN/distinfo Uchinese/libreoffice-zh_TW/distinfo Dnet-mgmt/pandorafms_console/files/patch-update Anet-mgmt/pandorafms_console/files/patch-WLB-2014110100 Unet-mgmt/pandorafms_console/pkg-plist Unet-mgmt/pandorafms_console/Makefile Unet-mgmt/pandorafms_console/distinfo Dnet-mgmt/pandorafms_agent/files/patch-update Unet-mgmt/pandorafms_agent/pkg-plist Unet-mgmt/pandorafms_agent/Makefile Unet-mgmt/pandorafms_agent/distinfo Unet-mgmt/pandorafms_server/pkg-plist.spool Unet-mgmt/pandorafms_server/pkg-plist Unet-mgmt/pandorafms_server/Makefile Unet-mgmt/pandorafms_server/distinfo Unet-mgmt/pandorafms_server/bsd.pandora.mk Dnet-mgmt/pandorafms_server/files/patch-update Upolish/libreoffice/distinfo Uportuguese/libreoffice/distinfo Uportuguese/libreoffice-pt_BR/distinfo Urussian/libreoffice/distinfo Usysutils/syslog-ng-devel/pkg-plist Usysutils/syslog-ng-devel/Makefile Usysutils/syslog-ng-devel/distinfo Ueditors/libreoffice-ca_valencia/distinfo Ueditors/libreoffice-af/distinfo Ueditors/libreoffice-am/distinfo Ueditors/libreoffice/distinfo Deditors/libreoffice/files/patch-collada Deditors/libreoffice/files/patch-sw__Module_sw.mk Deditors/libreoffice/files/extra-collada2gltf Deditors/libreoffice/files/patch-Makefile.in Deditors/libreoffice/files/patch-bridges__Module_bridges.mk Deditors/libreoffice/files/patch-editeng__Module_editeng.mk Aeditors/libreoffice/files/extra-Makefile.in Aeditors/libreoffice/files/enable-opencollada A editors/libreoffice/files/patch-external__collada2gltf__patches__kill_c++11_code.patch.1 Ueditors/libreoffice/Makefile.common Ueditors/libreoffice/Makefile Ueditors/libreoffice-as/distinfo Ueditors/libreoffice-be/distinfo Ueditors/libreoffice-bg/distinfo Ueditors/libreoffice-sa_IN/distinfo Ueditors/libreoffice-en_ZA/distinfo Ueditors/libreoffice-bn/distinfo Ueditors/libreoffice-bo/distinfo Ueditors/libreoffice-br/distinfo Ueditors/libreoffice-bs/distinfo Ueditors/libreoffice-ro/distinfo Ueditors/libreoffice-ca/distinfo Ueditors/libreoffice-rw/distinfo Ueditors/libreoffice-cs/distinfo Ueditors/libreoffice-sd/distinfo Ueditors/libreoffice-si/distinfo Ueditors/libreoffice-cy/distinfo Ueditors/libreoffice-sk/distinfo Ueditors/libreoffice-sl/distinfo Ueditors/libreoffice-sq/distinfo Ueditors/libreoffice-sr/distinfo Ueditors/libreoffice-da/distinfo Ueditors/libreoffice-ss/distinfo Ueditors/libreoffice-st/distinfo Ueditors/libreoffice-sv/distinfo Ueditors/libreoffice-ta/distinfo Ueditors/libreoffice-te/distinfo Ueditors/libreoffice-tg/distinfo Ueditors/libreoffice-th/distinfo Ueditors/libreoffice-dz/distinfo Ueditors/libreoffice-tn/distinfo Ueditors/libreoffice-kok/distinfo Ueditors/libreoffice-tr/distinfo Ueditors/libreoffice-bn_IN/distinfo Ueditors/libreoffice-ts/distinfo Ueditors/libreoffice-ast/distinfo Ueditors/libreoffice-tt/distinfo Ueditors/libreoffice-el/distinfo Ueditors/libreoffice-eo/distinfo Ueditors/libreoffice-es/distinfo Ueditors/libreoffice-et/distinfo Ueditors/libreoffice-eu/distinfo Ueditors/libreoffice-ug/distinfo Ueditors/libreoffice-fa/distinfo Ueditors/libreoffice-pa_IN/distinfo Ueditors/libreoffice-brx/distinfo Ueditors/libreoffice-fi/distinfo Ueditors/libreoffice-uz/distinfo Ueditors/libreoffice-kmr_Latn/distinfo Ueditors/libreoffice-ve/distinfo Ueditors/libreoffice-sat/distinfo Ueditors/libreoffice-ga/distinfo U
Re: RFT: Please help testing the llvm/clang 3.5.0 import
Warner Losh wrote this message on Thu, Dec 18, 2014 at 07:47 -0700: This is excellent news Dimitry! On Dec 16, 2014, at 12:36 PM, Dimitry Andric d...@freebsd.org wrote: On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64 have been tested through make universe, and everything should compile and run. * Little-endian ARM builds should now compile and run, thanks to Andrew Turner for putting in lots of work. * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. I know Andrew doesn???t have the right arm gear to do this test, and emulation environments that run FreeBSD have had poor big-endian support for arm. I have a board that I plan to test on shortly... If Andrew would like, I know Jim Thompson has a standing offer to send board(s) to people who will test it... He provided me w/ the board I will be testing on soon... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Email verification (LAST WARNING)
Your mailbox is almost full. Dear po...@freebsd.org, 3840MB4096MB Current size Maximum size Please reduce your mailbox size. Delete any items you don't need from your mailbox and empty your Deleted Items folder. Click here to do reduce size automatically. Thanks, Mail System AdministratorThis notification was sent to %email%; Don't want occasional updates about subscription preferences and friendly suggestions? Change what email Google+ sends you. Google Inc., 1600 Amphitheatre Pkwy, Mountain View, CA 94043 USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkg install from local poudriere repo creates links to txz
On 12/18/2014 12:29 PM, Beeblebrox wrote: I build my binaries in poudriere, then run pkg upgrade -r myrepo Before running upgrade, the repo is clean. After executing pkg upgrade (or install) all, processed files by the command get a sym-link pointing to the actual file. For example: mariadb55-client-5.5.40-058c8a2d74.txz mariadb55-client-5.5.40.txz - mariadb55-client-5.5.40-058c8a2d74.txz The sym-link breaks further poudriere runs, with poudriere complaining that the sym-link file does not exist. Only way to get poudriere to make a run is to manually unlink all sym-links in the repo. My environment has no PKG* related settings. How does one correct this? Regards. This should only happen if you set PKG_CACHEDIR to the same as your repodir, which is no longer supported since 1.3. In 1.3 the cachedir was skipped with local repositories to avoid this issue, but now in 1.4 it is again used which can lead to this surprising behavior (https://github.com/freebsd/pkg/issues/1103). Check /usr/local/etc/pkg.conf and make sure you did not set PKG_CACHEDIR. Also check 'pkg config PKG_CACHEDIR' to make sure it is showing /var/cache/pkg. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: pkg 1.4.0 pkg: Cannot solve problem using SAT solver: spandsp-devel
On 12/18/2014 12:06 AM, Craig Rodrigues wrote: On Wed, Dec 17, 2014 at 8:54 AM, Guido Falsi m...@madpilot.net wrote: On 12/17/14 17:34, Craig Rodrigues wrote: Hi, I did a pkg update -f ; pkg upgrade -y on a FreeBSD 10-stable system and ran into this error: Checking integrity... done (3 conflicting) pkg: Cannot solve problem using SAT solver: pkg: cannot find spandsp-devel in the request pkg: cannot solve job using SAT solver Checking integrity... done (0 conflicting) Conflicts with the existing packages have been found. One more solver iteration is needed to resolve them. As an end-user installing packages, this error message makes no sense at all to me, and doesn't tell me what I need to do to fix the problem. Can this (and other SAT solver) error messages be enhanced to include some hints as to what a user must do to solve the problem? What seemed to get me past this problem was to: pkg delete -f spandsp-devel pkg upgrade -y that's what UPDATING entry 20141215 suggests. It is always better to look at it. Thanks for the UPDATING pointer. You are correct. However, I would still like to see an error message from pkg which gives the user a better idea of what to do to solve the problem. For people who install/upgrade binary packages, they don't always read ports/UPDATING. I know I don't. The promise/goal with 1.3+ is that you should not have to. Pkg is bugged here. The solver integration is not yet mature. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
INDEX now builds successfully on 8.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Bug 195798] [PATCH] devel/fb303: Fix pkg-plist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195798 Real Huang realhuan...@gmail.com changed: What|Removed |Added CC||freebsd-ports@FreeBSD.org, ||realhuan...@gmail.com -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[Bug 196088] [PATCH] net/scribe Support FreeBSD 10.0+
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196088 Real Huang realhuan...@gmail.com changed: What|Removed |Added CC||freebsd-bugs-ports@FreeBSD. ||org, ||freebsd-ports@FreeBSD.org, ||realhuan...@gmail.com -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFT: Please help testing the llvm/clang 3.5.0 import
Dimitry Andric wrote this message on Tue, Dec 16, 2014 at 20:36 +0100: * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. hmmm... I can't get it to compile... Maybe I'm missing something... I tried to do: # make buildworld TARGET_ARCH=armeb WITH_BOOTSTRAP_CLANG= WITH_CLANG= WITHOUT_GCC= WITHOUT_BOOTSTRAP_GCC= This is from an amd64 host, though it is a month or two out of date... But it ended w/: c++ -O -pipe -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\armeb-gnueabi-freebsd11.0\ -DLLVM_HOST_TRIPLE=\armeb-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -fno-exceptions -fno-rtti -static -o clang cc1_main.o cc1as_main.o driver.o /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangserializati on/libclangserialization.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangedit/libclangedit.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmoption/libllvmoption.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmlinker/libllvmlinker.a /usr/obj/arm.armeb/a/src/usr.bin /clang/clang/../../../lib/clang/libllvmirreader/libllvmirreader.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmvectorize/libllvmvectorize.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvminstrumentation/libllvminstrumentation.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdisassembler/libllvmarmdisassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/obj/ar m.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdesc/libllvmarmdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsdisassembler/libllvmmipsdisassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmparser/libllvmmipsasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsdesc/libllvmmipsdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinstprinter/libllvmmipsinstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmp owerpccodegen/libllvmpowerpccodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmparser/libllvmpowerpcasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcdesc/libllvmpowerpcdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a
