Re: RTTI support in devel/llvm40 (and maybe other llvm ports)

On Sun, Nov 12, 2017 at 07:41:04PM +0700, Alexey Dokuchaev wrote: > On Sun, Nov 12, 2017 at 08:03:19AM +, Brooks Davis wrote: > > On Fri, Nov 10, 2017 at 02:07:48PM +0700, Alexey Dokuchaev wrote: > > > I've just found out that our `devel/llvm40' port comes without > &

Re: Default option changes-lacking explanation

On Mon, Nov 13, 2017 at 09:44:33AM +1100, Dewayne Geraghty wrote: > It would be very helpful if maintainers could add an explanation for the > changes to default options that they make. > > For example freeradius3 recently added heimdal and updfromto as default > options to the build without any

Re: Can a port directory name have capital letters when the project name has them: audio/abGate-lv2 ?

On Mon, Nov 13, 2017 at 09:56:06AM +0100, Mathieu Arnold wrote: > Le 10/11/2017 ?? 23:05, Yuri a ??crit : > > There are two competing directory name suggestions for the project > > with the name abGate: > > > > audio/abGate-lv2 > > > > audio/abgate-lv2 > > > > Should I choose the former one or the

Re: RTTI support in devel/llvm40 (and maybe other llvm ports)

On Sun, Nov 12, 2017 at 02:01:39PM +1030, Shane Ambler wrote: > On 10/11/2017 17:37, Alexey Dokuchaev wrote: > > I've just found out that our `devel/llvm40' port comes without > > -DLLVM_ENABLE_RTTI=ON on the CMAKE_ARGS. This is a regression > > from e.g. 3.4 times when it w

Re: RTTI support in devel/llvm40 (and maybe other llvm ports)

On Sun, Nov 12, 2017 at 08:03:19AM +, Brooks Davis wrote: > On Fri, Nov 10, 2017 at 02:07:48PM +0700, Alexey Dokuchaev wrote: > > I've just found out that our `devel/llvm40' port comes without > > -DLLVM_ENABLE_RTTI=ON on the CMAKE_ARGS. This is a regression > > fro

RTTI support in devel/llvm40 (and maybe other llvm ports)

Hi Brooks, I've just found out that our `devel/llvm40' port comes without -DLLVM_ENABLE_RTTI=ON on the CMAKE_ARGS. This is a regression from e.g. 3.4 times when it was enabled by default. The problem is that RTTI support is required by some consumers, e.g. `graphics/openshadinglanguage' and

Re: LLVM port(s) take very long time to package

On Fri, Apr 14, 2017 at 04:42:35PM +0200, Michael Gmelin wrote: > > On 14. Apr 2017, at 16:22, Alexey Dokuchaev <da...@freebsd.org> wrote: > > On Wed, Apr 12, 2017 at 12:06:42PM +0200, Michael Gmelin wrote: > >>> On 12. Apr 2017, at 11:37, Alexey Dokuc

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

Sorry Matthew, forgot to reply to this one. On Wed, Apr 05, 2017 at 07:01:35PM +0200, Matthew Rezny wrote: > On Wednesday 05 April 2017 16:15:41 Alexey Dokuchaev wrote: > > ... > > Hmm, I don't quite get it: shouldn't static linking actually increase > > the binaries (and t

Re: LLVM port(s) take very long time to package

On Wed, Apr 12, 2017 at 12:06:42PM +0200, Michael Gmelin wrote: > > On 12. Apr 2017, at 11:37, Alexey Dokuchaev <da...@freebsd.org> wrote: > > ... > > Other alternative to PKG_NOCOMPRESS=1 could be PKGSUFFIX=.tbz (pkg-static > > create -f tbz ...), will play with th

Re: LLVM port(s) take very long time to package

On Wed, Apr 12, 2017 at 04:12:45PM +0200, Jan Beich wrote: > Michael Gmelin writes: > > It's probably busy compressing the package. Try setting > > PKG_NOCOMPRESS=1 in /etc/make.conf (works ok when just building a > > package with make, didn't test with poudriere[0]). When

Re: LLVM port(s) take very long time to package

On Wed, Apr 12, 2017 at 10:43:14AM +0200, Michael Gmelin wrote: > > On 12. Apr 2017, at 05:43, Alexey Dokuchaev <da...@freebsd.org> wrote: > > ... > > pkg was eating 100% (of a single core) during that time, so it looks > > like it's actually busy (no

LLVM port(s) take very long time to package

Hi there porters, It had been annoying me for a while, so I figured I try asking here: LLVM ports (particularly, llvm39-3.9.1) take abnormally long time to package, e.g. right now it took 43 minutes (tmpfs-backed build area, pkg-1.10.0_2.txz, AMD A8 APU @1900 MHz, plenty of RAM, no swap). pkg

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On Wed, Apr 05, 2017 at 08:46:22PM +0200, Mathieu Arnold wrote: > Le 05/04/2017 ?? 19:20, Alexey Dokuchaev a ??crit : > > On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: > >> Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : > >>> ... > >>&g

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On Wed, Apr 05, 2017 at 07:12:06PM +0200, Mathieu Arnold wrote: > Le 05/04/2017 ?? 18:15, Alexey Dokuchaev a ??crit : > > ... > > That 1G looks like a big jump from 259M of llvm39-3.9.1_1.txz to me. > > So, you are comparing the size of the llvm39 package with the size

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On Thu, Mar 30, 2017 at 07:26:43PM +0200, Matthew Rezny wrote: > LLVM 3.8 introduced the option to build a shared LLVM library, which is > what Mesa needs for use at runtime (for e.g. compiling shaders), separate > from linking to it. Previous versions only had one option, if the library > was

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote: > On 26 Mar 2017, at 23:36, Mark Millard wrote: > > ... > > Also interesting was: > > > > Installed packages to be REMOVED: > > llvm40-4.0.0.r4 > > > > Number of packages to be removed: 1 > > > > The

Re: buzilla 214400: is is ports/head/base/binutils that is being reported on, freebsd-powe...@freebsd.org assignee is wrong

On Tue, Mar 07, 2017 at 08:19:20AM -0800, Mark Millard wrote: > But I can not fix the assignee: it should not be freebsd-powe...@freebsd.org > > Can you put back the correct assignee for a port problem? May I ask what exactly makes you think that freebsd-ports-b...@freebsd.org is correct

Re: Why standard user mailnull (26:26) is missing from /usr/ports/UIDs?

On Thu, Dec 29, 2016 at 03:31:45PM +, Matthew Seaman wrote: > On 29/12/2016 13:21, Alexey Dokuchaev wrote: > > Hence there're two questions: > > > > 1) $subj > > 2) Is it OK to add `mailnull' to /usr/ports/UIDs similar to `smmsp'? Or, > > 3) every port shou

Why standard user mailnull (26:26) is missing from /usr/ports/UIDs?

Hi porters, I was given a port to commit, it's email-related daemon and wants to keep some stuff around (like its state and socket) owned by its user. Submitter originally had chosen `mailnull' as apparently default system e-mail user; it suits the job and looks reasonable enough for generic

Re: John The Ripper 1.8.0 Jumbo 1

On Fri, Jul 22, 2016 at 01:04:54PM +0200, CeDeROM wrote: > Hello, is it possible to update John to 1.8.0-jumbo1? :-) Yes, it is anticipated. Alexander (Solar Designer) expressed a number of wishes about the port, so it's not going to be just a simple version bump. Stay tuned, and sorry for

Re: tinderbox seems broken after recent commits (python-related?)

On Tue, Aug 19, 2014 at 03:23:15PM +0930, Shane Ambler wrote: This was mentioned earlier on the tinderbox list --- Thanks for the pointer. Not sure why my google-fu failed me this time; is tinderbox list being indexed correctly? (I'm not subscribed.) Comment out the TEST_DEPENDS in

tinderbox seems broken after recent commits (python-related?)

hi there, tinderbox is unable to build more-or-less complex ports for couple of days now; both for 8.4/pkg_tools and 9.3/pkgng: it quietly exits with no package produced and no logs generated, except build/build-name/make.0 that looks always like this (modulo list of dependent packages, can be

Re: Proposal: further OptionsNG improvements

On Thu, Jun 27, 2013 at 01:33:31AM +0700, Alexey Dokuchaev wrote: It just occurred to me that it seems we actually do not support something like OPTIONS_SINGLE_AUDIO_${ARCH}, which simplifies my work (please tell me if I'm wrong). So all I need is to remember about OPTIONS_EXCLUDE's

Re: Boost 1.55.0 (Was: Re: PowerPC Packages)

On Thu, Jun 26, 2014 at 03:59:49PM +, Alexey Dokuchaev wrote: On Thu, Jun 26, 2014 at 05:44:16PM +0200, Baptiste Daroussin wrote: As long as cc is supported upstream, boost being a nightmare to maintain I will reject all patches that are not accepted upstream first, otherwise bumping

Re: Boost 1.55.0 (Was: Re: PowerPC Packages)

On Wed, Jun 25, 2014 at 07:23:05AM -0700, Justin Hibbits wrote: As I mentioned earlier, you can set FAVORITE_COMPILER=gcc in make.conf, and it'll build with gcc47. FAVORITE_COMPILER looks more like a hack to me. Ideally boost's port Makefile should be fixed instead. I also would rather use

Re: Boost 1.55.0 (Was: Re: PowerPC Packages)

On Thu, Jun 26, 2014 at 05:44:16PM +0200, Baptiste Daroussin wrote: As long as cc is supported upstream, boost being a nightmare to maintain I will reject all patches that are not accepted upstream first, otherwise bumping to 1.56 will be painful. I'm currently trying to build it on PowerPC

Boost 1.55.0 (Was: Re: PowerPC Packages)

On Mon, Jun 23, 2014 at 01:12:22PM +, Alexey Dokuchaev wrote: On Sun, Jun 15, 2014 at 08:50:29AM -0700, Nathan Whitehorn wrote: depend upon failed. The largest issues are Boost and QT4 webkit. Boost has failed because it seems to unconditionally prefer clang to gcc when both are present

Re: Boost 1.55.0 (Was: Re: PowerPC Packages)

On Wed, Jun 25, 2014 at 07:33:40AM +, Alexey Dokuchaev wrote: One thing bugs me about it: per https://svn.boost.org/trac/boost/ticket/8769, Sorry, per http://www.boost.org/users/news/a_special_note_for_boost_1_52_0_and_higher.html, of course. ./danfe

Re: PowerPC Packages

On Sun, Jun 15, 2014 at 08:50:29AM -0700, Nathan Whitehorn wrote: depend upon failed. The largest issues are Boost and QT4 webkit. Boost has failed because it seems to unconditionally prefer clang to gcc when both are present. On PowerPC, both are installed but GCC remains the default due to

Re: FreeBSD ports that you maintain require staging updates

On Tue, Jun 10, 2014 at 04:53:17PM +1000, Dylan Leigh wrote: I use httptunnel regularly thanks to RMITU's asinine wireless. Don't know anything about staging yet but I will take maintainership and do it if noone else is willing to save the port. Thanks for volunteering Dylan; I'll stagify it

Re: lang/gcc and tmpfs no space let on device

On Fri, May 16, 2014 at 02:43:09PM +0200, Marko Cupa?? wrote: Hi, I am using 10.0-RELEASE-p3 amd64, and am trying to build lang/gcc as a dependency for emulators/virtualbox-ose. Building fails giving the following messages: jc1: fatal error: error writing to /tmp/ccwgXZ8m.s: No space left

Re: Dependencies: base vs. ports (Was: Re: ports/187468)

On Wed, Mar 12, 2014 at 07:01:20AM -0500, Bryan Drewery wrote: On Mar 11, 2014, at 23:48, Alexey Dokuchaev da...@freebsd.org wrote: On Tue, Mar 11, 2014 at 07:50:37PM -0500, Bryan Drewery wrote: This goes against our plans to have all ports depend only on ports. I admit this has not been

Dependencies: base vs. ports (Was: Re: ports/187468)

On Tue, Mar 11, 2014 at 07:50:37PM -0500, Bryan Drewery wrote: This goes against our plans to have all ports depend only on ports. I admit this has not been communicated well. libexecinfo should probably be moved to /usr/lib/private on head to prevent ports from using it. [ Taking this to

Re: emulators/linux_base-c6 and x11/nvidia-driver conflict

On Fri, Mar 07, 2014 at 01:58:49PM +0100, RenИ Ladan wrote: I noticed that linux_base-c6 and nvidia-driver conflict when one selects the LINUX option in nvidia-driver (default on). The culprit is /compat/linux/usr/lib/libGL.so.1, which is a symbolic link to libGL.so.331.49 (nvidia-driver) and

10.0-release jail on head-hosted tinderbox (Was: Re: 10.0-hosted tinderbox: 8.4 builds broken?)

On Sun, Oct 13, 2013 at 01:36:45PM +0100, Chris Rees wrote: It appears that really weird SRCBASE assumptions are made throughout the code. I'll have to put a temporary hack in to just make SRCBASE appear inside the chroot whatever it's set to. Setting and unsetting SRCBASE just breaks

Re: security/john: bump to 1.7.9-jumbo-7

On Wed, Nov 20, 2013 at 07:27:05AM -0900, Royce Williams wrote: Could someone bump security/john? The simple patch below should be a good start to cover it, and it's been more than a year since jumbo-6 came out, so it's pretty stale. Royce, I'm know I'm slow on this, but I'd really like to

Re: Anyone looked at making a port for https://www.eff.org/https-everywhere ?

shows just security/switzerland/, port creator Alexey Dokuchaev da...@freebsd.org added to CC. Oh, that's a blast from the past. :) Frankly I already forgot why I decided to port it, probably because I needed it back in those days. I'm afraid I cannot say anything about https-everywhere as a whole

Re: 10.0-hosted tinderbox: 8.4 builds broken?

On Mon, Oct 21, 2013 at 03:37:31PM +0700, Alexey Dokuchaev wrote: I have some more here: if plist is broken for one of the dependent ports (not sure if it happens for staged ports only or not), remaining ports also fail to build with two-line logs: building foobar-1.42 in directory /usr

Re: 10.0-hosted tinderbox: 8.4 builds broken?

On Sun, Oct 27, 2013 at 04:33:48PM -0400, Joe Marcus Clarke wrote: The distcache directory is created within the build each time before the cache is mounted. So this becomes a mountpoint. Does your _host_ distcache directory have 0775 perms? If so, I imagine the perms should be inherited

Re: 10.0-hosted tinderbox: 8.4 builds broken?

On Sun, Oct 20, 2013 at 07:05:20PM +0100, Chris Rees wrote: On 2013-10-20 15:51, Alexey Dokuchaev wrote: However I've noticed another regression: doing chmod g+w /usr/ports/distfiles in the middle of the tinder run totally confuses it: all build attempts after chmod fail with identical tiny

Re: 10.0-hosted tinderbox: 8.4 builds broken?

On Sun, Oct 13, 2013 at 01:36:45PM +0100, Chris Rees wrote: It appears that really weird SRCBASE assumptions are made throughout the code. I'll have to put a temporary hack in to just make SRCBASE appear inside the chroot whatever it's set to. Setting and unsetting SRCBASE just breaks

tinderbox behavior during make package (phase 7)

Hi there, I've noticed lots of the following lines when using pkg-enabled tinderbox: [...] === Checking filesystem state Deleting p5-XML-Parser-2.41_1 Deinstallation has been requested for the following 1 packages: p5-XML-Parser-2.41_1 The deinstallation will free 420 KB [1/1] Deleting

Re: wmii-devel

On Sun, Oct 13, 2013 at 05:53:59PM +0200, Mariusz Zaborski wrote: Hi there, I got some problems while compiling wmii-devel. I would like propose some patch to the port. It's removed dependencies of libixp port version and add librrary which was missing while compiling (xrender). Thanks, I

portupgrade and pkgng (again)

Hi there, I have a remote -CURRENT box which i'd rather not src-update now (r248373, ca. March). Apparently it's recent enough to default to pkgng. I wanted to upgrade some ports of mine today, and installed my favorite portupgrade just to discover that it does not see any packages: it seems to

Re: How to disable staging support in ports tree universally?

On Sat, Oct 12, 2013 at 09:15:25AM +0100, Matthew Seaman wrote: Yes, there are a lot of changes happening at the moment. We're trying to catch up with ten or more years of progress in a year or so. The technical reasoning behind our implementing these changes has been discussed elsewhere so

10.0-hosted tinderbox: 8.4 builds broken?

Hi there, I've started to observe the following error when trying to tinderbuild (freshly cvs up'ed from marcuscom.com) a port for -b 8.4: ... add_pkg pkg-1.1.4_7.tbz adding dependencies pkg_add pkg-1.1.4_7.tbz The package management tool is not yet installed on your system. Do you

Re: 10.0-hosted tinderbox: 8.4 builds broken?

On Wed, Oct 09, 2013 at 05:59:50PM +0200, Baptiste Daroussin wrote: On Wed, Oct 09, 2013 at 06:09:55PM +0700, Alexey Dokuchaev wrote: Why does it happen? I was under impression that 8.x will never switch to pkgng. Am I doing something wrong, or need to configure my tindy somehow? 1/ yes

Re: 10.0-hosted tinderbox: 8.4 builds broken?

On Wed, Oct 09, 2013 at 09:11:10PM +0100, Chris Rees wrote: That's really annoying... I'll have to track it down Friday I'm afraid. cvs up'ing back to sources as of Oct 6 (before your recent commits) seems to restore correct behavior for me. Now -b 8.4 builds do not try to find or install

Re: x11/nvidia-driver build failure in head/i386 @r253985 with clang

On Wed, Aug 07, 2013 at 06:02:41AM -0700, David Wolfskill wrote: [...] nvidia_subr.c:997:19: error: incompatible pointer types passing 'vm_map_t' (aka 'struct vm_map *') to parameter of type 'struct vmem *' [-Werror, -Wincompatible-pointer-types] kmem_free(kernel_map,

Re: x11/nvidia-driver build failure in head/i386 @r253985 with clang

On Wed, Aug 07, 2013 at 08:53:02AM -1000, Jeff Roberson wrote: This is my fault. The first argument to the kmem_ functions should now be kernel_arena or kmem_arena. I don't know how to modify ports but I can produce a patch later today to resolve this unless someone beats me to it. It will

Re: x11/nvidia-driver build failure in head/i386 @r253985 with clang

On Wed, Aug 07, 2013 at 02:03:13PM -0700, David Wolfskill wrote: On Wed, Aug 07, 2013 at 08:53:02AM -1000, Jeff Roberson wrote: ... Not sure how much further I'll be able to get for a while; I'm out-of-town and Internet access is a bit flaky. Sorry... This is my fault. The first

CFT: [patch] making -jX builds the default

Hi there, In attempt to catch (hopefully) last few remaining jobs-unsafe ports, and thus to make upcoming expruns fallouts easier to handle, I'm sending small patch I've been using locally for a while to get larger exposure. Patch was sent to portmgr@ guys for review about a month earlier, it

Re: Proposal: further OptionsNG improvements

On Fri, Jun 21, 2013 at 10:04:51AM +0200, Baptiste Daroussin wrote: Sorry it took time for me to reply, after we last talk about this, I thought a lot about this, and while in principe I do like the idea, I have a couple of concerns: 1: this reduces lots of flexibility we now have with the

Re: Proposal: further OptionsNG improvements

On Wed, Jun 26, 2013 at 07:12:41PM +0700, Alexey Dokuchaev wrote: I've cooked something up just now, take a look at the attached diff. I've only barely tested it, but it seems to work for a few of my hand-crafted configurations. It also handles known options groups (single/multi/etc

Re: Proposal: further OptionsNG improvements

On Wed, Jun 26, 2013 at 07:30:55PM +0700, Alexey Dokuchaev wrote: On Wed, Jun 26, 2013 at 07:12:41PM +0700, Alexey Dokuchaev wrote: I've cooked something up just now, take a look at the attached diff. I've only barely tested it, but it seems to work for a few of my hand-crafted

Re: LICENSE and PORTREVISION bump

On Sat, Jun 15, 2013 at 01:18:16PM +0200, Pawel Pekala wrote: Dnia 2013-06-15, o godz. 14:26:27 Boris Samorodov b...@passap.ru napisaЁ(a): The FreeBSD Porters Book claims that a PORTREVISION should be bumped if a significant change is made to a port. My question is Should a PORTREVISION be

Re: Proposal: further OptionsNG improvements

On Tue, Jun 18, 2013 at 12:47:47PM -0700, Jason Helfman wrote: On Tue, Jun 18, 2013 at 11:56:07AM -0500, Mark Felder wrote: So we just got done porting most of the tree to a new options syntax and now we want to change it again? :-) Yeah, why not? ;-) I've discussed that idea

Re: svn mv and changing files at the same time: still prohibited

On Tue, Jun 18, 2013 at 07:22:31AM -0500, Bryan Drewery wrote: Solution: Save your target changes, undo the move (revert rtcw), 'svn update' in rtcw, and mv again. Then copy in your changes and commit. Don't forget to 'svn add' any files as well. This should fix it. Indeed, thanks for the

Proposal: further OptionsNG improvements

Hi there, Now as I understand old-skool OPTIONS knob support is removed, can we do something about ugliness of newish OPTIONS_DEFINE[_arch]/OPTIONS_DEFAULT [_arch] pair of knobs? I am thinking about the following syntax (using now free-again OPTIONS knob, instead of several

Re: Proposal: further OptionsNG improvements

On Tue, Jun 18, 2013 at 11:56:07AM -0500, Mark Felder wrote: So we just got done porting most of the tree to a new options syntax and now we want to change it again? :-) Yeah, why not? ;-) I've discussed that idea before with bapt@ on IRC; there is absolutely no reasons why we should not use

svn mv and changing files at the same time: still prohibited

Hi there, I've been trying to rename a port (games/rtcw - games/linux-rtcw) and had to change something inside port's Makefile at the same time (drop PORTEPOCH and PORTREVISION, and set PKGNAMEPREFIX accordingly), but commit was blocked by pre-commit hook with Do not replace a file. This can lose

Re: [CFH] FreeBSD 10 and ports

On Tue, Jun 11, 2013 at 10:21:56PM +0300, Konstantin Belousov wrote: What you are proposing is de-facto forking the whole open-source code base. This cannot work, and in fact steals the FreeBSD resources for something which has absolutely no relevance for FreeBSD project. From what I see there

Re: Plans for making MAKE_JOBS_SAFE the default?

On Wed, May 22, 2013 at 11:09:02AM +0800, Martin Wilke wrote: Hi, Since we are back on normal rolling packages update for stable and I got pointyhat-west up to do some testing, I would like to move on with this case. I just wonder if someone already has a patch to make it as default, else

Re: Plans for making MAKE_JOBS_SAFE the default?

On Thu, May 23, 2013 at 07:18:26AM -0500, Bryan Drewery wrote: On 5/23/2013 2:56 AM, Alexey Dokuchaev wrote: FORCE_MAKE_JOBS is removed because it is the default. While here, I've moved empty(MAKE_JOBS_NUMBER) check higher, IMHO where it should belong, also saves a few lines. Reviews

Re: Plans for making MAKE_JOBS_SAFE the default?

On Thu, May 23, 2013 at 09:14:21AM -0500, Bryan Drewery wrote: On 5/23/2013 8:00 AM, Alexey Dokuchaev wrote: On Thu, May 23, 2013 at 07:18:26AM -0500, Bryan Drewery wrote: On 5/23/2013 2:56 AM, Alexey Dokuchaev wrote: FORCE_MAKE_JOBS is removed because it is the default. While here, I've

Re: ports/head@r314338 x11/nvidia-driver

On Mon, Apr 01, 2013 at 03:39:37PM +0300, Sergey V. Dyatko wrote: On Mon, 1 Apr 2013 05:28:27 -0700 David Wolfskill da...@catwhisker.org wrote: On Mon, Apr 01, 2013 at 03:24:33PM +0300, Sergey V. Dyatko wrote: ... looks like r248084-patch-src-nvidia_subr.c is incomplete ... here

Re: ports/head@r314338 x11/nvidia-driver

On Mon, Apr 01, 2013 at 03:39:37PM +0300, Sergey V. Dyatko wrote: On Mon, 1 Apr 2013 05:28:27 -0700 David Wolfskill da...@catwhisker.org wrote: On Mon, Apr 01, 2013 at 03:24:33PM +0300, Sergey V. Dyatko wrote: ... looks like r248084-patch-src-nvidia_subr.c is incomplete ... here

Re: net-im/hotot fetch failure (size mismatch)

On Fri, Mar 01, 2013 at 12:35:56PM +0900, meta wrote: net-im/hotot fails to fetch. I'm not sure which is correct distinfo vs actual but please see it. should be fixed in r313393, thanks for reporting! ./danfe ___ freebsd-ports@freebsd.org mailing

Re: CFT: x11/nvidia-driver major update to 304.xx series

On Wed, Sep 26, 2012 at 03:35:07PM -0400, Lawrence K. Chen, P.Eng. wrote: So, now that its in the wild...I upgraded...and it broke my dual monitor desktop (at work). Seems like gdm/gnome can't see the other monitor.] Tried rebuilding a bunch of other things, but didn't help. Reverting to

Re: CFT: x11/nvidia-driver major update to 304.xx series

On Wed, Sep 19, 2012 at 04:55:49PM +0700, Alexey Dokuchaev wrote: Hi there, I am calling for testers to help me make weighted decision about updating the port to 304.43. If, for some reason, 304.43 does not work for you, tell me how does version 295.75 feel. Thanks everyone giving back

CFT: x11/nvidia-driver major update to 304.xx series

Hi there, As many of you had probably noticed, recently folks at NVidia decided that long-cooked three-hundred branch is stable enough to declare it Long Lived Branch. Since ChangeLog from 295.71/.75 is gross, and I've been receiving mixed reviews for early 30x.?? versions, I am calling for

Re: Update to graphics/luminance and transferring ownership

On Thu, Sep 13, 2012 at 01:55:07PM +0200, Hannes wrote: Hi everyone, a while back I created a new (updated) port of graphics/luminance and discussed with the original port maintainer (in CC) that he wants to transfer ownership of the port to me. I also worked with danfe@freebsd (also in

Re: FreeBSD port: stellarium 0.11.4

On Sun, Aug 26, 2012 at 02:52:01AM +0700, Alexander Wolf wrote: Today has been released Stellarium 0.11.4 with improvements for *BSD systems. http://astro.uni-altai.ru/~aw/patches/FreeBSD-stellarium.patch Thanks for the patch (albeit it's incomplete: missing distinfo and pkg-plist changes,

Re: [Full-disclosure] nvidia linux binary driver priv escalation exploit

On Mon, Aug 06, 2012 at 01:49:50PM +0200, Rainer Hurling wrote: Am 06.08.2012 10:03 (UTC+1) schrieb Doug Barton: On 08/01/2012 05:09, Oliver Pinter wrote: I found this today on FD: http://seclists.org/fulldisclosure/2012/Aug/4 Apparently this affects us as well. Any news? Thanks for

Re: [Full-disclosure] nvidia linux binary driver priv escalation exploit

On Wed, Aug 08, 2012 at 08:38:43AM -0400, Wesley Shields wrote: On Wed, Aug 08, 2012 at 10:34:06AM +, Alexey Dokuchaev wrote: VuXML entry will have to follow separately, as it is unclear whether new CVE number will be assigned or not. You can do the VuXML without a CVE for now

Re: Boost ports update

On Wed, Mar 07, 2012 at 11:44:46PM +0100, Baptiste Daroussin wrote: On Wed, Mar 07, 2012 at 11:56:17PM +0300, Alexander Churanov wrote: graphics/luxrender There is a newer version of it (0.8) maybe it works with recent boost, I CC maintainer (danfe@) for him to tell us if he knows Yup, I

Re: Fix nvidia-like ports, help needed

On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: One of the issues with 'alternatives' implementations is that they are not selectable per-user (including non superuser). In this particular case (libGL), also what about the native X server vs. virtual X servers that support using

Re: nvidia-driver + 8-stable PAE == spectacular fail

On Sat, Feb 18, 2012 at 06:19:18PM -0800, Doug Barton wrote: I've been using 8-stable the last several weeks in preparation for the new release and decided to give PAE a try for the first time. I rebuilt my kernel with that option, and it booted fine. Then I rebuilt the nvidia module and as

Re: x11/nvidia-{driver, settings, xconfig}: why not the latest available version (290.10)?

On Sat, Dec 24, 2011 at 04:44:04PM +0800, Denise H. G. wrote: On 2011/12/24 at 08:41, Conrad J. Sabatier conr...@cox.net wrote: Just wondering why the x11/nvidia-{driver,settings,xconfig} ports have yet to be updated to the latest version (290.10). Are there any known issues with any of

Re: [PATCH] multimedia/libdvdnav

On Sun, Oct 23, 2011 at 01:17:05AM +1100, richo wrote: I tried to use vlc to play a dvd on -CURRENT but it fails with libdvdnav: vm: ifoRead_FP_PGC failed Googling, I found a patch from debian bugtracker at

Re: cvs commit: ports/x11/nvidia-driver Makefile distinfo

On Wed, Sep 14, 2011 at 03:52:52AM +0400, Dmitry Marakasov wrote: * Alexey Dokuchaev (da...@freebsd.org) wrote: Log: - Update NVidia drivers to their corresponding latest versions - Apply a workaround to fix the build on recent -CURRENT after fget(9) KPI was changed in r224778

Re: Problem with nvidia-driver and X after upgrade

On Fri, Aug 26, 2011 at 03:30:47PM -0400, Carmel wrote: After updating my system as per the UPDATING file, I now find that the Nvidia driver no longer works with Xorg. I've just updated the driver to version 280.13; perhaps you should update your ports free, rebuild the driver, and see if the

Re: Problem with nvidia-driver and X after upgrade

On Fri, Aug 26, 2011 at 03:30:47PM -0400, Carmel wrote: After updating my system as per the UPDATING file, I now find that the Nvidia driver no longer works with Xorg. Does it happen with the latest stable version from the nvidia.com? I have some pending patches in my queue for the port, but

Re: portlint(1) knobs order: let's make things more logical

On Thu, Jun 23, 2011 at 11:41:17AM +0400, Ilya A. Arkhipov wrote: Hi danfe@ marcus@ if I've got it right for group we need have specific order + checkorder('LICENSE', $tmp, $file, qw( +LICENSE LICENSE_COMB LICENSE_PERMS LICENSE_GROUPS +LICENSE_NAME LICENSE_FILE LICENSE_TEXT+ ));

Re: OpenTTD

On Wed, Jun 22, 2011 at 10:33:14AM +0400, Ilya A. Arkhipov wrote: Ok i rewrite patch and do with argument, and write patch to portlint ;) Wow, if you could write a patch to portlint that is would correctly suggest that MAINTAINER/COMMENT/LICENSE should be grouped together, and FOO_DEPENDS would

portlint(1) knobs order: let's make things more logical

[ Subject changed to reflect new course of the discussion ] On Wed, Jun 22, 2011 at 09:56:55AM +0100, Chris Rees wrote: COMMENT LICENSE So license in a separate block; you can have several license lines making the MAINTAINER/COMMENT block unnecessarily large. Agree here; space looks nice

Re: portlint(1) knobs order: let's make things more logical

On Wed, Jun 22, 2011 at 04:02:33PM +0300, Ion-Mihai Tetcu wrote: *DEPENDS and USE* are really the same thing, dependencies (with, maybe, some rare exceptions). So I'd say they should go together. Precisely. That was my original concern (that currently, portlint advises to put LICENSE knob

Re: OpenTTD

On Wed, Jun 22, 2011 at 03:18:24PM +0100, Chris Rees wrote: Just to satisfy a nagging question inside me (I'm sorry, you're going to regret having me around!). Do you mean: BUILD_DEPENDS LIB_DEPENDS RUN_DEPENDS USE_FOO USE_BAR or BUILD_DEPENDS LIB_DEPENDS RUN_DEPENDS USE_FOO

Re: portlint(1) knobs order: let's make things more logical

On Wed, Jun 22, 2011 at 11:39:54PM +0400, Ilya A. Arkhipov wrote: Hi danfe@ http://micro.heavennet.ru/ports/portlint/portlint.patch please see it? thanks, seems to work fine. I've beautified it a bit (see attach; sections become badly numbered and some whitespace nits). marcus@ is CCed.

Re: x11/nvidia-driver: cc1: error: /src: No such file or directory

On Tue, May 10, 2011 at 01:40:00PM +0400, Pan Tsu wrote: On /head@r221320 for kernel sources -Wmissing-include-dirs was added to force people to provide valid include directories. It can be fixed by either providing default definition in port's Makefile or removing NVIDIA_ROOT from there.

Re: graphics/simpleviewer doesn't build on head(?)

On Fri, Apr 08, 2011 at 01:50:27AM -0500, Zhihao Yuan wrote: Whatever... I don't like this image viewer. While this viewer is far from perfect, I find that it at least works (contrary to gliv which dumps core on me both now and many years ago when I first discovered it) and performs scaling

Re: graphics/simpleviewer doesn't build on head(?)

On Fri, Apr 08, 2011 at 02:22:17AM -0500, Zhihao Yuan wrote: 2011/4/8 Alexey Dokuchaev da...@freebsd.org: On Fri, Apr 08, 2011 at 01:50:27AM -0500, Zhihao Yuan wrote: Whatever... I don't like this image viewer. I'd happily switch to anything at least as good as default viewer in windoze

Re: graphics/simpleviewer doesn't build on head(?)

On Fri, Apr 08, 2011 at 02:39:50AM -0500, Zhihao Yuan wrote: 2011/4/8 Alexey Dokuchaev da...@freebsd.org: Unfortunately, graphics/xli seems to be deprecated and scheduled for termination after 2011-05-01. Perhaps you'd like to become new maintainer? Yes. So far, I only maintain new ports

Re: graphics/simpleviewer doesn't build on head(?)

On Fri, Apr 08, 2011 at 03:03:20AM -0500, Zhihao Yuan wrote: On Fri, Apr 8, 2011 at 2:59 AM, Zhihao Yuan lich...@gmail.com wrote: 2011/4/8 Alexey Dokuchaev da...@freebsd.org: I will clean up graphics/xli and set you as maintainer. Thanks. The original distfile source can be removed

Re: graphics/simpleviewer doesn't build on head(?)

On Fri, Apr 08, 2011 at 05:48:10AM -0500, Zhihao Yuan wrote: 2011/4/8 Alexey Dokuchaev da...@freebsd.org: Done.  You might be interested to know that Debian has this package of version 1.17.0-20061110, which is newer than ours.  I didn't take liberty to update the port which I don't use

Re: graphics/simpleviewer doesn't build on head(?)

On Fri, Apr 08, 2011 at 09:47:33AM -0500, Zhihao Yuan wrote: On Fri, Apr 8, 2011 at 9:10 AM, Alexey Shuvaev wrote: On Fri, Apr 08, 2011 at 07:07:02AM +, Alexey Dokuchaev wrote: I'd happily switch to anything at least as good as default viewer in windoze xp, but have not seen anything

Re: Plans for making MAKE_JOBS_SAFE as default

On Sun, Mar 13, 2011 at 10:14:46PM +0300, Anonymous wrote: Alexey Dokuchaev da...@freebsd.org writes: On Thu, Dec 23, 2010 at 07:12:22AM -0600, Ade Lovett wrote: Given that we're _really_ close to 7.4/8.2 -- not this side of January mumble -- random uneducated guess. In time for 9.0. I

Plans for making MAKE_JOBS_SAFE as default

Hi there, As far as I remember, when _MAKE_JOBS functionality was introduced, one of the ultimate goals was to flip the switch at some point so ports are built with -jX unless marked as MAKE_JOBS_UNSAFE. What is current situation and consensus? Are we ready for that? If not, what is preventing

Re: Plans for making MAKE_JOBS_SAFE as default

On Thu, Dec 23, 2010 at 07:12:22AM -0600, Ade Lovett wrote: On Dec 23, 2010, at 03:18 , Alexey Dokuchaev wrote: I'd really like to see that happen. If there is anything I can help with, don't hesitate to ask. :-) Given that we're _really_ close to 7.4/8.2 -- not this side of January

Re: libgpod

On Thu, Sep 30, 2010 at 12:18:22PM +0200, Alberto Villa wrote: On Wednesday 29 September 2010 21:21:26 Sam Fourman Jr. wrote: would anyone happen to have a port patch for the new libgpod i had one, and sent it to danfe, but afaik he's busy with real life. i'll try to clean it up and make

  1   2   >