Re: Can't get gvim working
On 06/08/2012 03:51, Doug Barton wrote: On 08/05/2012 03:05, David Demelier wrote: On 05/08/2012 11:01, Doug Barton wrote: On 08/05/2012 00:18, David Demelier wrote: On 05/08/2012 00:12, Doug Barton wrote: On 08/04/2012 14:56, David Demelier wrote: I finally found the problem: at the configure target see, checking for GTK - version = 2.2.0... Package glproto was not found in the pkg-config search path. Perhaps you should add the directory containing `glproto.pc' to the PKG_CONFIG_PATH environment variable No package 'glproto' found no x11/glproto was not installed, I think we could add a dependency on it. Seems to apply only to the gnome define, as I can build and run gvim without it. David, what do you think of the attached? Doug I would rather place in the WITH_GTK2 conditional, since gtk2 requires glproto too. ... that was the point of my reporting that with just gtk2 glproto is *not* needed. :) Why do you think it is? Doug Because the check of Gtk2 fails if it is not enabled, thus no gtk2 gui will be enabled the same error as my first post. Ok, let me try again. :) I don't have glproto installed. I have the gtk GUI option enabled. I can configure, build, and run gvim just fine without glproto; with no errors. Doug That's very odd, why it does not work for me then? checking --enable-gui argument... GTK+ 2.x GUI support checking --disable-gtktest argument... gtk test enabled checking for pkg-config... /usr/local/bin/pkg-config checking for GTK - version = 2.2.0... Package glproto was not found in the pkg-config search path. Perhaps you should add the directory containing `glproto.pc' to the PKG_CONFIG_PATH environment variable No package 'glproto' found no checking X11/SM/SMlib.h usability... yes checking X11/SM/SMlib.h presence... yes checking for X11/SM/SMlib.h... yes checking X11/xpm.h usability... yes checking X11/xpm.h presence... yes checking for X11/xpm.h... yes checking X11/Sunkeysym.h usability... yes checking X11/Sunkeysym.h presence... yes checking for X11/Sunkeysym.h... yes checking for XIMText in X11/Xlib.h... yes no GUI selected; xim has been disabled no GUI selected; fontset has been disabled Can you show me your /etc/make.conf? Cheers, -- David Demelier ___ 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: Can't get gvim working
On 08/05/2012 23:54, David Demelier wrote: That's very odd, why it does not work for me then? You also had the gnome option enabled, I don't. If you've disabled that since you posted about it, -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46
On 8/6/12, Doug Barton do...@freebsd.org wrote: On 07/31/2012 08:57, Gerald Pfeifer wrote: On Sun, 29 Jul 2012, Doug Barton wrote: skipping quibbles and polemics Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. For the most part, yes. The upstream developers have a policy of avoiding version bumps for the runtime support libraries when possible, and instead using symbol versioning to maintain backward-compatibility. Only a very few pieces of software using libgcj or libobjc will have to be recompiled. For default packages, IIRC, that is only print/pdftk. Of course, it will be to the advantage of most users to recompile their packages with the new version of the compiler. In other words, if there is a challenge it's not GCC per se, more our packaging of it (and some work Bapt is doing on the packaging infrastructure should help with that). I don't know of any magic solutions in the works that will solve the separation of libgcc from the compiler. :) I think Gerald was referring to Bapt's plan to make it easier to make multiple packages from a single port, so that those who used packages exclusively could install a package consisting of only the runtime support libraries, rather than the whole compiler suite. I had patches to do this even without pkgng, but it made things a little more complicated, and didn't seem to be a high priority, so I didn't pursue it. If people feel that it is important, I could work with Gerald to revive that, or use a knob like that of ports/155408 with static linking to allow users to remove the runtime dependency for a lot of software, at the cost of some added overhead from redundancies. b. ___ 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: lang/gcc46
On 08/06/2012 00:30, b. f. wrote: On 8/6/12, Doug Barton do...@freebsd.org wrote: On 07/31/2012 08:57, Gerald Pfeifer wrote: On Sun, 29 Jul 2012, Doug Barton wrote: skipping quibbles and polemics Sure, whatever. Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. For the most part, yes. In my mind, this isn't good enough. But I'm not in charge of anything. :) I think Gerald was referring to Bapt's plan to make it easier to make multiple packages from a single port, so that those who used packages exclusively could install a package consisting of only the runtime support libraries, rather than the whole compiler suite. Universal support for that is years away, minimum. I had patches to do this even without pkgng, but it made things a little more complicated, and didn't seem to be a high priority, so I didn't pursue it. If people feel that it is important, I could work with Gerald to revive that, or use a knob like that of ports/155408 with static linking to allow users to remove the runtime dependency for a lot of software, at the cost of some added overhead from redundancies. Making this change now would benefit a lot of people, now. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: [RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
On 08/03/2012 17:49, Bryan Drewery wrote: Hi, While developing on ports-mgmt/poudriere I've added support to automatically rebuild packages if the selected options in /var/db/ports, or make.conf change. This so far has worked well with pkgng as it records the OPTIONS selected into the package already. By suggestion of bapt, 'pretty-print-config' is used to compare the packaged OPTIONS to the selected OPTIONS. This has worked great for pkgng. Just today I added support [1] to poudriere for pkg_create(1) packages by storing the 'pretty-print-config' into the /var/db/pkg/PKGNAME/+CONTENTS as a comment: @comment OPTIONS:`make pretty-print-config` I'd like to add it to 'fake-pkg' so that the @comment is saved on every port/package creation. This may potentially benefit portmaster and portupgrade as well. [1] http://fossil.etoilebsd.net/poudriere/ci/98426527c8?sbs=0 Comparison of the package +CONTENTS after patch: diff -ur /tmp/zsh-5.0.0.orig/+CONTENTS /var/db/pkg/zsh-5.0.0/+CONTENTS --- /tmp/zsh-5.0.0.orig/+CONTENTS 2012-08-04 02:31:51.0 +0200 +++ /var/db/pkg/zsh-5.0.0/+CONTENTS 2012-08-04 02:33:26.0 +0200 @@ -639,7 +639,7 @@ share/zsh/5.0.0/functions/Completion/Solaris/_zones @comment MD5:858863d60ce982e149dbe3f2adb679c3 share/zsh/5.0.0/functions/Completion/Unix.zwc -@comment MD5:13a3ee08695e76219a326f722d7006c7 +@comment MD5:8219096a131f65761e23864a62088298 share/zsh/5.0.0/functions/Completion/Unix/_a2ps @comment MD5:e2d2d6b9f68fd43ce63040fc680ef9d6 share/zsh/5.0.0/functions/Completion/Unix/_adb @@ -2013,6 +2013,7 @@ @dirrm share/zsh/5.0.0/scripts @dirrm share/zsh/5.0.0 @unexec rmdir %D/share/zsh 2/dev/null || true +@comment OPTIONS:-DEBUG +DOCS -GDBM +MAILDIR -MEM +MULTIBYTE -PCRE +SECURE_FREE -STATIC @cwd @dirrm share/licenses/zsh-5.0.0 @unexec rmdir %D/share/licenses 2/dev/null || true I think this is a fantastic idea, as it would more fully answer the question of how was this package built? I would also like to see us embed the distfile information, either in +CONTENTS or in its own file. This information is very useful for tools like portmaster to better handle automated distfile cleanup. hth, Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: [Full-disclosure] nvidia linux binary driver priv escalation exploit
On 08/01/2012 05:09, Oliver Pinter wrote: Hi all! I found this today on FD: http://seclists.org/fulldisclosure/2012/Aug/4 Apparently this affects us as well. Any news? -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46
On 8/6/12, Doug Barton do...@freebsd.org wrote: On 08/06/2012 00:30, b. f. wrote: On 8/6/12, Doug Barton do...@freebsd.org wrote: On 07/31/2012 08:57, Gerald Pfeifer wrote: On Sun, 29 Jul 2012, Doug Barton wrote: Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. For the most part, yes. In my mind, this isn't good enough. But I'm not in charge of anything. :) Oops: I forgot though, that partly due to this policy of not bumping gcc shared library versions, we have some shared libraries in the base system that conflict with the shared libraries of the various gcc ports, and we have been enforcing the right links by inscribing hints in the binaries to look first in the right gcc port directories. But if we update lang/gcc from 4.6.x to another major version (e.g. 4.7.x), the directory changes, and linking for the old binaries will fail. So let me qualify my earlier answer: you can keep the old software working with minimal intervention, for example, by adding a symlink from the old directory to the new one. I think Gerald was referring to Bapt's plan to make it easier to make multiple packages from a single port, so that those who used packages exclusively could install a package consisting of only the runtime support libraries, rather than the whole compiler suite. Universal support for that is years away, minimum. I had patches to do this even without pkgng, but it made things a little more complicated, and didn't seem to be a high priority, so I didn't pursue it. If people feel that it is important, I could work with Gerald to revive that, or use a knob like that of ports/155408 with static linking to allow users to remove the runtime dependency for a lot of software, at the cost of some added overhead from redundancies. Making this change now would benefit a lot of people, now. Okay, but since I'm not in charge either, it will require (at least) Gerald's consent. And if you adopt the latter approach, it won't be one size fits all: it may make sense to use static linking to the support libraries for default packages, of which a comparatively few are built with lang/gcc4*, but it will be less suitable for those who routinely use lang/gcc4* for most if not all of their packages. b. ___ 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: [CFT] editors/emacs to 24.1
On Sun, 5 Aug 2012, the wise Ashish SHUKLA wrote: % gdb $(which emacs) (gdb) core-file emacs.core (gdb) bt full Hi Marco, Could you provide output of those () ? Output of this is: (gdb) core /var/coredumps/emacs.core Core was generated by `emacs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libgobject-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgobject-2.0.so.0 Reading symbols from /usr/local/lib/libgmodule-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgmodule-2.0.so.0 Reading symbols from /usr/local/lib/libpango-1.0.so.0...done. Loaded symbols for /usr/local/lib/libpango-1.0.so.0 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /usr/local/lib/libcairo.so.2...done. Loaded symbols for /usr/local/lib/libcairo.so.2 Reading symbols from /usr/local/lib/libfreetype.so.9...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libfontconfig.so.1...done. Loaded symbols for /usr/local/lib/libfontconfig.so.1 Reading symbols from /usr/local/lib/libpangoft2-1.0.so.0...done. Loaded symbols for /usr/local/lib/libpangoft2-1.0.so.0 Reading symbols from /usr/local/lib/libpangocairo-1.0.so.0...done. Loaded symbols for /usr/local/lib/libpangocairo-1.0.so.0 Reading symbols from /usr/local/lib/libgio-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgio-2.0.so.0 Reading symbols from /usr/local/lib/libX11.so.6...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libXext.so.6...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libXrender.so.1...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libXinerama.so.1...done. Loaded symbols for /usr/local/lib/libXinerama.so.1 Reading symbols from /usr/local/lib/libXi.so.6...done. Loaded symbols for /usr/local/lib/libXi.so.6 Reading symbols from /usr/local/lib/libXrandr.so.2...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libXcursor.so.1...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/libXfixes.so.3...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /usr/local/lib/libXcomposite.so.1...done. Loaded symbols for /usr/local/lib/libXcomposite.so.1 Reading symbols from /usr/local/lib/libXdamage.so.1...done. Loaded symbols for /usr/local/lib/libXdamage.so.1 Reading symbols from /usr/local/lib/libgdk_pixbuf-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /usr/local/lib/libgdk-x11-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgdk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libatk-1.0.so.0...done. Loaded symbols for /usr/local/lib/libatk-1.0.so.0 Reading symbols from /usr/local/lib/libgtk-x11-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgtk-x11-2.0.so.0 Reading symbols from /usr/local/lib/libSM.so.6...done. Loaded symbols for /usr/local/lib/libSM.so.6 Reading symbols from /usr/local/lib/libICE.so.6...done. Loaded symbols for /usr/local/lib/libICE.so.6 Reading symbols from /usr/local/lib/libtiff.so.4...done. Loaded symbols for /usr/local/lib/libtiff.so.4 Reading symbols from /usr/local/lib/libjpeg.so.11...done. Loaded symbols for /usr/local/lib/libjpeg.so.11 Reading symbols from /usr/local/lib/libpng15.so.15...done. Loaded symbols for /usr/local/lib/libpng15.so.15 Reading symbols from /lib/libz.so.6...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/local/lib/libgif.so.5...done. Loaded symbols for /usr/local/lib/libgif.so.5 Reading symbols from /usr/local/lib/libXpm.so.4...done. Loaded symbols for /usr/local/lib/libXpm.so.4 Reading symbols from /usr/local/lib/libXft.so.2...done. Loaded symbols for /usr/local/lib/libXft.so.2 Reading symbols from /usr/local/lib/librsvg-2.so.2...done. Loaded symbols for /usr/local/lib/librsvg-2.so.2 Reading symbols from /usr/local/lib/libMagickCore.so.5...done. Loaded symbols for /usr/local/lib/libMagickCore.so.5 Reading symbols from /usr/local/lib/libMagickWand.so.5...done. Loaded symbols for /usr/local/lib/libMagickWand.so.5 Reading symbols from /usr/local/lib/libdbus-1.so.3...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /lib/libutil.so.9...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libncurses.so.8...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /usr/local/lib/libgconf-2.so.4...done. Loaded symbols
Re: Jenkins+FreeBSD handbooks
On Sun, Aug 5, 2012 at 8:37 PM, Bernhard Fröhlich de...@freebsd.org wrote: Hello Bernhard, Thank you for the feedback. Could you clarify a bit more why you think Jenkins does not fit well there? I don't know how redports.org is designed and how it scales, but with Jenkins it's quite easy to create a package build farm for distributed building. Redports is a public compile testing environment for FreeBSD ports. So like Ports Tinderbox but with a nice multiuser GUI, cluster functionality for scaling and an own Subversion tree for the users to commit their ports to. Before I decided to write the code myself I had a closer look at Bitten and Jenkins. Both could be made into what redports is now but they all have their weak spots. Jenkins GUI looks very cluttered and is quite hard to understand if you just want to manually schedule a few new jobs for your ports as Joe Average. It's also quite hard to understand and complex as a developer and administrator so I was concerned that fixing it if it breaks is non trivial. Not to talk about all the special customizations that we need which would require me to write extensions in Java and understand how all that jenkins internals work. Like any other system Jenkins has it's own learning curve as well, but once you get to know it, you see how intuitive it is to use the system. I agree with you on the Java stuff. That's the one thing I don't like about Jenkins being Java.. But I can tell from my experience with it so far, that I haven't had any issues with it, e.g. breaking and spending lots of time figuring out how to fix it. Maybe one day I will, but so far I'm quite happy with it :) Bitten looked simpler and less complex but would also work for standard things but it got me on the right track to use Trac as webinterface and just extend Trac with a custom plugin that includes a few simple pages to have an overview of jobs and add new ones. Jenkins comes with lots of ready-to-use plugins as well, which makes it easier to integrate a particular thing easier as well and not re-invent the wheel. Yeah that is nice and there is almost everything that you can think of but none of them did what I needed. A simple web interface for average people that don't want to learn Jenkins internals and is easily customizable. Probably there is a plugin for that but I didn't find it. Writing some glue code around tinderbox to schedule new jobs, checkout repositories and such stuff is custom code anyway. A more suitable place for jenkins would be automatic building our doc tree on every commit. But I don't know if that doesn't already exist. Yep, that's one of the things we could use Jenkins for, but I would say we could use it for lots of other stuff as well :) I'm sure we could. Examples? Besides the ones I've already posted in my first email (documentation, scan-build, project test build, package test build) on top of my head I can think of the following examples as well: - Integration between Jenkins Gerrit for code review and collaboration projects. One possible place where this can be used for example is replacing the PR system and gnats. This would allow contributors to send patches directly to the Gerrit server and behind the scenes Jenkins does all the automatic verification of a change, e.g. whether this patch applies or not. A committer then approves and pushes a single button to get a change deployed. This saves a lot of time for committers and contributors as well as all the test-verify-deploy cycle of a change is done by Jenkins automatically. - Jenkins also supports the concept of upstream and downstream projects, which makes possible to trigger a build/test/whatever on other projects when something happens, e.g. changes to a particular part of the kernel might trigger a specific set of tests to be performed; port being updated which triggers building of the port and then deploying to all systems via Jenkins. Similar thing I use for the pkgng project - a commit triggers a build on the downstream projects for a) building with gcc; b) building with clang; c) building documentation; etc.. - You can use Jenkins for doing QA of configuration changes managed by Cfengine for example. Just put the Cfengine repository under Jenkins control and let Jenkins go over a set of verification steps and tests before a change actually gets merged in. This makes it suitable to ensure you are not going to break the configuration by making a typo for example. - I like graphs :) Having graphs gives a better visibility for example how often a build fails, who breaks the build, etc. over time. Jenkins has lots of plugins which generate graphs - you just need to configure what you need. And you can use for other cool stuff, but that really depends on the needs and requirements. So far I've been quite happy with Jenkins and doing what I needed, and that was the reason for writing these short handbooks on Jenkins - just to share
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description f ports/170396[PATCH] net-mgmt/nagiosql: update to 3.2.0 SP1 o ports/170386editors/omegaT update to 2.5.5_01 o ports/170384[ports] UPDATING: Correct 20120804 entry and add portu f ports/170381x11/slim window manager gives dbus errors starting xfc o ports/170371[patch] lang/sdcc: update to 3.2.0 o ports/170366lang/libobjc2: update to 1.6.1 f ports/170365Patch updating finance/trytond from version 1.4.7 to 2 f ports/170357net-mgmt/tcptrack Segmentation fault (core dumped) f ports/170348[update]: databases/tarantool up to 1.4.7 o ports/170347New port: benchmarks/nosqlbench Micro-benchmarking NoS f ports/170344[UPDATE] net/tcpflow: update to 1.2.8, take maintainer f ports/170339www/node: segmentation violation in v8::internal::Hand o ports/170336New port: textproc/confetti Configuration file parser f ports/170308[MAINTAINER] net/xrdp: Convert to OptionsNG etc o ports/170293Port japanese/a2ps generates a warning message on Perl o ports/170285Update mail/mailman from 2.1.14 to 2.1.15 o ports/170280mail/mailman reports incorrect value for MM_USERID o ports/170242[PATCH] devel/arduino: fix avr-libc SIG_USART1_RECV is o ports/170241[PATCH] devel/libftdi: upgrade to 0.20 and fix automak o ports/170229sysutils/ntfsprogs is in conflict with sysutils/fusefs f ports/170186Update sysutils/modules to version 3.2.9 o ports/170185sysutils/mgeupsd not correctly works. o ports/170180[patch] Mk/bsd.options.mk allow make.conf and command o ports/170104error setting source interface in net/mcast-tools, net o ports/170100astro/orsa: version 0.7.0 in ports hopelessly outdated o ports/170097devel/libunwind 20110911: prevents upgrade to current o ports/170089chinese/ibus-chewing 1.3.10 can't be compiled with ibu o ports/170078New port: databases/mysql-workbench: a cross-platform, o ports/170057[NEW PORT] games/nelly: Nelly's Rooftop Garden, A phys o ports/170020[NEW PORT] sysutils/gigolo: Gigolo is a frontend to ea o ports/17emulators/vmware-tools6: Can not install VMware Tools o ports/169916new port: sysutils/salt-cloud - Provisioning salted mi o ports/169910[NEW PORT] www/trac-childtickets: Support for having c o ports/169893[NEW PORT] games/tuxfighter: TuxFighter is a little As f ports/169876devel/flyspray: Strict Standards: Non-static method Fl o ports/169861new port: audio/bristol, Bristol Synthesiser Emulation f ports/169770[patch] audio/alsa-lib: make async handler work (from f ports/169767audio/alsa-plugins: desync with oss plugin f ports/169759net-mgmt/nrpe2 doesn't start after subsequent reboots o ports/169741[new port] devel/visualparadigm o ports/169732[NEW PORT] dns/credns: A verifier performing validatio f ports/169722[patch] Update games/bzflag to 2.4.0 f ports/169716net-mgmt/ndpmon several problems with build and instal o ports/169687new port: www/xpi-ghostery o ports/169628sysutils/devcpu-data f ports/169613security/botan: Fix ECDSA for dns/powerdns and maybe o f ports/169521astro/weatherspect: Exiting with SIGUse of uninitializ o ports/169519[net/cvsup] socksify and cvsup cannot be used together o ports/169506[NEW PORT] devel/pecl-inotify: The inotify extension a o ports/169492[new port] databases/pecl-sqlite must be restored f ports/169430net-mgmt/flowviewer Makefile does not install scripts o ports/169383New Port: graphics/puf Photographer productivity tool o ports/169371port graphics/sane-backends segfaults f ports/169333[PATCH] sysutils/syslog-ng2: move sample config to EXA o ports/169322New port: net/armsd: SMFv2/ARMS Service Adapter daemon o ports/169314graphics/ImageMagick fails to build: test failure o ports/169296New port: textproc/libcrm114 CRM114 C-callable Library f ports/169165sysutils/fusefs-kmod: calling fchown(2) on sshfs files o ports/169112[patch] Fix build of devel/valgrind on clang. o ports/169090New Port: comms/ge-x2212-2 An EEPROM programmer for GE o
Re: [Full-disclosure] nvidia linux binary driver priv escalation exploit
Am 06.08.2012 10:03 (UTC+1) schrieb Doug Barton: On 08/01/2012 05:09, Oliver Pinter wrote: Hi all! I found this today on FD: http://seclists.org/fulldisclosure/2012/Aug/4 Apparently this affects us as well. Any news? Thanks for the info. I had been not aware of it before. NVidia has released a driver version 304.32 for FreeBSD i386 and amd64, which should remedy these security issues. ___ 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: Jenkins+FreeBSD handbooks
* Marin Atanasov Nikolov [Mon, 6 Aug 2012 13:40:52 +0300]: Redports is a public compile testing environment for FreeBSD ports. So like Ports Tinderbox but with a nice multiuser GUI, cluster functionality for scaling and an own Subversion tree for the users to commit their ports to. Before I decided to write the code myself I had a closer look at Bitten and Jenkins. Both could be made into what redports is now but they all have their weak spots. Jenkins GUI looks very cluttered and is quite hard to understand if you just want to manually schedule a few new jobs for your ports as Joe Average. It's also quite hard to understand and complex as a developer and administrator so I was concerned that fixing it if it breaks is non trivial. Not to talk about all the special customizations that we need which would require me to write extensions in Java and understand how all that jenkins internals work. Like any other system Jenkins has it's own learning curve as well, but once you get to know it, you see how intuitive it is to use the system. I agree with you on the Java stuff. That's the one thing I don't like about Jenkins being Java.. But I can tell from my experience with it so far, that I haven't had any issues with it, e.g. breaking and spending lots of time figuring out how to fix it. Maybe one day I will, but so far I'm quite happy with it :) Jenkins comes with lots of ready-to-use plugins as well, which makes it easier to integrate a particular thing easier as well and not re-invent the wheel. I am surprised you haven't run into any plugin incompatibilities. We use Jenkins at work and have frequently hard to debug issues with plugins being incompatible with certain jenkins versions or with other plugins. Sometimes a broken plugin manages to take down the whole Jenkins, sometimes there are just random Java backtraces causing build failures in projects. IMHO the whole Jenkins architecture is way too fragile to be used for large projects like FreeBSD. ___ 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: [RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
On 8/6/2012 3:00 AM, Doug Barton wrote: I would also like to see us embed the distfile information, either in +CONTENTS or in its own file. This information is very useful for tools like portmaster to better handle automated distfile cleanup. hth, I like that idea. My only feedback is to make the auto-delete on deinstall be optional in bsd.port.mk. They may turnaround and reinstall it right away and not want to waste the bandwidth again. Makes sense for port building tools to wipe the old files on upgrade! -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ 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: [RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
On 08/06/2012 06:34 AM, Bryan Drewery wrote: On 8/6/2012 3:00 AM, Doug Barton wrote: I would also like to see us embed the distfile information, either in +CONTENTS or in its own file. This information is very useful for tools like portmaster to better handle automated distfile cleanup. hth, I like that idea. My only feedback is to make the auto-delete on deinstall be optional in bsd.port.mk. They may turnaround and reinstall it right away and not want to waste the bandwidth again. Makes sense for port building tools to wipe the old files on upgrade! Sorry I wasn't clear, I use the information on the old package to delete the old distfiles, after first comparing to the list of distfiles used by other ports to make sure that it isn't in use elsewhere (such as QT). In portmaster un-installing the port is a different option from upgrading, and has a component of deleting the current distfiles if the user chooses it. ___ 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: [RFC] bsd.port.mk: Record OPTIONS into /var/db/pkg on install
On 8/6/2012 9:38 AM, Doug Barton wrote: On 08/06/2012 06:34 AM, Bryan Drewery wrote: On 8/6/2012 3:00 AM, Doug Barton wrote: I would also like to see us embed the distfile information, either in +CONTENTS or in its own file. This information is very useful for tools like portmaster to better handle automated distfile cleanup. hth, I like that idea. My only feedback is to make the auto-delete on deinstall be optional in bsd.port.mk. They may turnaround and reinstall it right away and not want to waste the bandwidth again. Makes sense for port building tools to wipe the old files on upgrade! Sorry I wasn't clear, I use the information on the old package to delete the old distfiles, after first comparing to the list of distfiles used by other ports to make sure that it isn't in use elsewhere (such as QT). Ah I see my confusion now. http://www.freebsd.org/cgi/query-pr.cgi?pr=106483 I saw the $RM lines in deinstall and didn't look close enough. They are just removing the distfile list, not the actual files. Regards, Bryan ___ 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
Questions about/issues with new OPTIONS framework
(Please keep me CC'd, as I'm not subscribed to the list) I've been trying to adapt my /etc/make.conf to make use of the new OPTIONS framework. I've run into some snags that I was hoping someone could help me with, as I'm unable to find any official documentation other than these two documents, which don't help me in this case: http://wiki.freebsd.org/Ports/Options/OptionsNG http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html Below are my questions so far. Note that these questions are all preceded by a key fact: /var/db/ports/* is completely empty. Keep that in mind please. 1. databases/mysql55-server and databases/mysql55-client both ask for the same variables (OPENSSL and FASTMTX). I want FASTMTX to be enabled by default for both ports. When I have the following in /etc/make.conf: mysql_SET= FASTMTX Doing make config in databases/mysql55-server shows FASTMTX as checked (which is correct). However, when I do the exact same procedure in databases/mysql55-client, FASTMTX is not checked. I am aware that databases/mysql55-client is a slave port, but I'm not sure how/why that would matter...? What am I doing wrong, or is this a port bug which needs to be fixed by the maintainer? 2. ports/KNOBS is very explicit in stating, and even visually demonstrating (using pipe symbols to delimit length maximums and so on), the following: # - Knob description must be 45 characters or less Yet, a very good number of descriptions violate this (see the file for yourself). I'm inclined to think the limit is to be extra friendly towards 80-column terminals, but I'm still not sure. Is this 45-character-limit untrue, or are numerous descriptions blatantly too long? Thanks. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: Questions about/issues with new OPTIONS framework
On Mon, 6 Aug 2012, Jeremy Chadwick wrote: (Please keep me CC'd, as I'm not subscribed to the list) 2. ports/KNOBS is very explicit in stating, and even visually demonstrating (using pipe symbols to delimit length maximums and so on), the following: # - Knob description must be 45 characters or less Yet, a very good number of descriptions violate this (see the file for yourself). I'm inclined to think the limit is to be extra friendly towards 80-column terminals, but I'm still not sure. Is this 45-character-limit untrue, or are numerous descriptions blatantly too long? On the older version of dialog(1) included with 8.x, longer descriptions trigger a bug that messes up the displayed menu. As an example, try a 'make config' on security/tripwire. We should not limit the length of descriptions, many of which are already less than helpful to the user. I wrote a wrapper script for dialog(1) that addresses the length problem, truncating long descriptions on 8.x and showing them in full on 9.x. It also makes the menu take advantage of larger terminals, showing more of the descriptions and more lines: http://www.wonkity.com/~wblock/dialogwrapper/ It makes no changes to ports or ports infrastructure. However, so far there has been very little feedback. ___ 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: Questions about/issues with new OPTIONS framework
On 8/6/2012 11:04 AM, Jeremy Chadwick wrote: 2. ports/KNOBS is very explicit in stating, and even visually demonstrating (using pipe symbols to delimit length maximums and so on), the following: # - Knob description must be 45 characters or less Yet, a very good number of descriptions violate this (see the file for yourself). I'm inclined to think the limit is to be extra friendly towards 80-column terminals, but I'm still not sure. Is this 45-character-limit untrue, or are numerous descriptions blatantly too long? The KNOBS file is deprecated. The new file is Mk/bsd.options.desc.mk, which has similar length comments and restrictions. The limit *does* matter as otherwise the description a) Gets cut off b) Wraps, causing display issues on 8.x and 7.x. If you find descriptions that are cut off or wrapping, please do report them. Regards, Bryan Drewery ___ 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: Jenkins+FreeBSD handbooks
On Mon, Aug 6, 2012 at 3:43 PM, Tilman Keskinöz ar...@freebsd.org wrote: * Marin Atanasov Nikolov [Mon, 6 Aug 2012 13:40:52 +0300]: Redports is a public compile testing environment for FreeBSD ports. So like Ports Tinderbox but with a nice multiuser GUI, cluster functionality for scaling and an own Subversion tree for the users to commit their ports to. Before I decided to write the code myself I had a closer look at Bitten and Jenkins. Both could be made into what redports is now but they all have their weak spots. Jenkins GUI looks very cluttered and is quite hard to understand if you just want to manually schedule a few new jobs for your ports as Joe Average. It's also quite hard to understand and complex as a developer and administrator so I was concerned that fixing it if it breaks is non trivial. Not to talk about all the special customizations that we need which would require me to write extensions in Java and understand how all that jenkins internals work. Like any other system Jenkins has it's own learning curve as well, but once you get to know it, you see how intuitive it is to use the system. I agree with you on the Java stuff. That's the one thing I don't like about Jenkins being Java.. But I can tell from my experience with it so far, that I haven't had any issues with it, e.g. breaking and spending lots of time figuring out how to fix it. Maybe one day I will, but so far I'm quite happy with it :) Jenkins comes with lots of ready-to-use plugins as well, which makes it easier to integrate a particular thing easier as well and not re-invent the wheel. Hi Tilman, I am surprised you haven't run into any plugin incompatibilities. So far not. I always try to keep my Jenkins and plugins to the latest versions and so far didn't have any issues. If a newer version of a plugin appears to be broken then just downgrading it solves the issue, but such issues are noticed quickly. We use Jenkins at work and have frequently hard to debug issues with plugins being incompatible with certain jenkins versions or with other plugins. Sometimes a broken plugin manages to take down the whole Jenkins, sometimes there are just random Java backtraces causing build failures in projects. We use Jenkins at work quite extensively as well for quite some time already. The only major failure with Jenkins I had by this moment is when a Jenkins instance went out of memory, but the problem itself was that Jenkins was running on an old machine with very low resources. Migrating it to a more recent system with enough memory solved the issue. We run Jenkins under a Debian GNU/Linux and FreeBSD systems. IMHO the whole Jenkins architecture is way too fragile to be used for large projects like FreeBSD. I have to say that we use Jenkins in some very critical parts of our infrastructure and it's been doing well so far. Jenkins like almost every system has it's weak and strong spots and maybe you had a different experience with it than I did. Thank you for the feedback Tilman :) Best regards, Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/ ___ 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
%gconf key files
Hi,
I am working on a port which installs %gconf key file in ${PREFIX}/
etc/gconf/gconf.xml.defaults/.
Now according I cannot mention %gconf files in pkg-plist but I have to
mention them in Makefile under GCONF_SCHEMAS. But When I mention that file
it gives an error like the following while deinstalling :
Failed to open `/usr/local/etc/gconf/schemas/gconf-tree.xml': No such file
or directory
pkg_delete: file '/usr/local/etc/gconf/schemas/%gconf-tree.xml' doesn't
exist
That means GCONF_SCHEMAS are loaded from ${PREFIX}/etc/gconf/schmas but
what about source fles from ${PREFIX}/etc/gconf/gconf.xml.defaults/
Howto mention them in Makefile. Portlint gives a FATAL error if mentioned
in pkg-plist :(
Thanks in advance.
Regards,
Muhammad
___
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
How to determine Python.h location in Makefile?
Hi, all! Could anybody tell me how to detect Python.h location automatically in port Makefile, or how to add its path to gmake's arguments in a reliable way? B.R. HU Dong ___ 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: How to determine Python.h location in Makefile?
Hi,
On Tue, Aug 07, 2012 at 10:21:13AM +0800, HU Dong wrote:
Hi, all! Could anybody tell me how to detect Python.h location
automatically in port Makefile, or how to add its path to gmake's arguments
in a reliable way?
There's a list of variables in bsd.python.mk. This should work:
${PYTHON_INCLUDEDIR}/Python.h
--
Denny Lin
___
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: How to determine Python.h location in Makefile?
It helps. Thank you!
B.R.
HU Dong
On Tue, Aug 7, 2012 at 11:24 AM, Denny Lin dennyli...@hs.ntnu.edu.twwrote:
Hi,
On Tue, Aug 07, 2012 at 10:21:13AM +0800, HU Dong wrote:
Hi, all! Could anybody tell me how to detect Python.h location
automatically in port Makefile, or how to add its path to gmake's
arguments
in a reliable way?
There's a list of variables in bsd.python.mk. This should work:
${PYTHON_INCLUDEDIR}/Python.h
--
Denny Lin
___
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
How to change docdir in port Makefile?
Hi, all. I'm making a new port. It uses GNU configure to generate a
GNU Makefile. But it set DOCSDIR to
${PREFIX}/share/doc/${PORTNAME}-${PORTVERSION} instead
of ${PREFIX}/share/doc/${PORTNAME}:
***
docdir = $(prefix)/share/doc/$(PACKAGE)-$(VERSION)
***
I've tried post-patch, but it didn't help, cause post-patch phase is
earlier than the time when GNU Makefile is generated. So how to modify the
GNU Makefile to correct this problem?
B.R.
HU Dong
___
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: How to change docdir in port Makefile?
On Mon, Aug 6, 2012 at 8:36 PM, HU Dong itechb...@gmail.com wrote:
Hi, all. I'm making a new port. It uses GNU configure to generate a
GNU Makefile. But it set DOCSDIR to
${PREFIX}/share/doc/${PORTNAME}-${PORTVERSION} instead
of ${PREFIX}/share/doc/${PORTNAME}:
***
docdir = $(prefix)/share/doc/$(PACKAGE)-$(VERSION)
***
I've tried post-patch, but it didn't help, cause post-patch phase is
earlier than the time when GNU Makefile is generated. So how to modify the
GNU Makefile to correct this problem?
B.R.
HU Dong
If it is generated from, I assume a Makefile.in, or similar file, try
patching that file. Then your change
should follow. I had to take this approach for deskutils/virt-manager
recently for NLS location
change.
Hope this helps.
-jgh
--
Jason Helfman | FreeBSD Committer
j...@freebsd.org | http://people.freebsd.org/~jgh
___
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
