Re: mesa libs issue

[Kevin Oberman]

On Mon, May 15, 2017 at 7:31 PM, bob prohaska  wrote:

> On Tue, May 16, 2017 at 12:33:28AM +, Tatsuki Makino wrote:
> >
> > Probably, pkg set -[no] cannot combine records of multiple packages
> (libglapi, libGL, gbm, libEGL and libglesv2) into one (mesa-libs).
> > It means that pkg delete is mandatory.
> > After deleting, the dependency needs to be reconnected by something.
>
> In playing a little with deleting libEGL it appears to demolish much
> of the GUI infrastructure, deleting something like 4G of applications
> and libraries. At that declaration I hesitated, and hit n. 8-)
>
> If it's really the only way to update the system please indicate so,
> and I'll give it a try. I'm on RPI2, running -current.
>
> Thanks very much,
>
> bob prohaska
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>

Do NOT 'pkg delete libEGL" or and of the others! You need to "pkg delete -f
libEGL". If you don't use '-f' when deleting a port, all ports dependent on
that port will also be deleted, as you saw. '-f' will force deletion of the
port WITHOUT touching anything else.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: mesa libs issue

[bob prohaska]

On Tue, May 16, 2017 at 12:33:28AM +, Tatsuki Makino wrote:
> 
> Probably, pkg set -[no] cannot combine records of multiple packages 
> (libglapi, libGL, gbm, libEGL and libglesv2) into one (mesa-libs).
> It means that pkg delete is mandatory.
> After deleting, the dependency needs to be reconnected by something.

In playing a little with deleting libEGL it appears to demolish much
of the GUI infrastructure, deleting something like 4G of applications
and libraries. At that declaration I hesitated, and hit n. 8-)

If it's really the only way to update the system please indicate so,
and I'll give it a try. I'm on RPI2, running -current.

Thanks very much,

bob prohaska
 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

RE: mesa libs issue

[Tatsuki Makino]

Thank you for your reply.

Probably, pkg set -[no] cannot combine records of multiple packages (libglapi, 
libGL, gbm, libEGL and libglesv2) into one (mesa-libs).
It means that pkg delete is mandatory.
After deleting, the dependency needs to be reconnected by something.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

RE: mesa libs issue

[Tatsuki Makino]

Thank you for your reply.

> What I would do:
> 
> pkg delete -f libEGL-17.0.3 libGL-17.0.3 libglesv2-17.0.3 gbm-17.0.3 
> libglapi-17.0.3 dri-17.0.3,2
> portmaster -d graphics/mesa-libs graphics/mesa-dri
> portmaster -ad

Probably, additional steps are required before or after portmaster -ad.
This time the version of packages that depend on mesa have not been changed 
(ex. www/seamonkey).
Running portmaster --check-depends (or pkg check -d -n) is needed to check and 
solve dependency problem.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: sysutils/tmux - strange behaviour with new version 2.4

[Vanilla Hsu]

I got the same problem too, but after update to 2.5-rc2, all issues gone.

maybe you can try to update to 2.5-rc2 (2.5 not yet released) by yourself.

2017-05-16 1:18 GMT+08:00 Miroslav Lachman <000.f...@quip.cz>:

> I noticed some strange behaviours with Tmux 2.4.
> If I run "cat /path/to/somefile.txt" sometimes part of file is missing in
> the output (no special characters in this text file, it is log of "pkg
> upgrade")
>
> And I thing some key presses are interpreted differently. (in Vim)
>
> I know that nobody can solve this without more details... so I am just
> asking if I am alone or somebody else have this problem too?
>
> Miroslav Lachman
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Tomoaki AOKI]

On Mon, 15 May 2017 10:51:51 -0700 (PDT)
"Jeffrey Bouquet"  wrote:

> 
> 
> On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI  
> wrote:
> 
> > Hi.
> > If including its version to nvidia.ko and nvidia-modeset.ko,
> > [hard / symbolic] link to it with current name should be needed
> > not to bother admins every time upgrading.
> > 
> > BTW, I personally using below in rc.conf for safety.
> > This only helps situations that...
> > 
> >  *Insufficient loader memory, but OK after kernel is started.
> > 
> >  *Accidentally backed to older version that doesn't have
> >   nvidia-modeset.ko and only nvidia-modeset.ko is written in
> >   /boot/loader.conf.
> > 
> > ## Temporary settings for nvidia-driver when failed loading via loader.conf
> > kldstat -q -n nvidia.ko
> > if [ 0 -ne $? ] ; then
> >   echo "Loading nvidia-driver modules via rc.conf."
> > #  kldload nvidia
> >   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> > #kldload nvidia-modeset
> > kld_list="${kld_list} nvidia-modeset.ko"
> >   else
> > #kldload nvidia
> > kld_list="${kld_list} nvidia.ko"
> >   fi
> > fi
> > 
> > 
> > On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> > "Jeffrey Bouquet"  wrote:
> > 
> > >  Just had a unique to me, unbootable backup [beside the point,
> > > just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> > > that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> > > 
> > >   12.0 - CURRENT
> > > 
> > >   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail 
> > > for me to peruse as I was in the terminal ]
> > > 
> > > Lessons I learned, maybe
> > > 
> > > [RFC]  rename nvidia-driver.ko to include its version, for instance 
> > > nvidia-modeset-37539.ko
> > >   which would make one's diagnosis a fix easier. 
> > > 
> > > [suggestions]
> > > 
> > > ... Document that the kernel will load a /boot/modules/_nvidia.ko if 
> > > you'd thus made it 'unavailable'
> > > ... document better that one can load nvidia[modeset] later than 
> > > /boot/loader.conf [cli, rc.conf...]
> > > 
> > > [ mini 'what fixed it for you '  and/or stalled the same ... 
> > > ] 
> > > ... I had a make.conf in place, 'trapping' a
> > > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> > > install in failure
> > > ... I had no clue if Xorg was at fault, and luckily did not have to 
> > > rebuild.
> > > ... I had no access to the forums, as the desktop could not be loaded 
> > > [yet]
> > > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> > > usable module numbers,
> > > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include 
> > > its 5 digit number
> > > as above.
> > > ... I was taken aback by the less infomative
> > > this client has the .39 but the module has the .26 ... 
> > > specifically stating which file/port/kernel module the 'client' 
> > > refers to
> > >and which specific modules 'this module' was referring to.  Unknown if 
> > > that is
> > >fixable here in a .c, .h , or is closed-source upstream in nvidia 
> > > [corp ] where we can
> > > ask them to be more specific or code in some more verbose error 
> > > messages.
> > > ...  Relieved I did not have to rebuild Xorg nor the kernel, just move 
> > > files out of the
> > >   way and do a simple rebuild of the nvidia-driver.
> > > [... Not relieved that the nvidia-driver needed install during the 
> > > mesa-lib reshuffle,  maybe
> > >did not need to be, just a hazy recollection on my part.  So ignore 
> > > this little bit ]
> > > 
> > > ... All in all a learning experience.  Howsoever, I would like this 
> > > nvidia stuff to be put eventuall
> > >  in /usr/src/UPDATING so the half or third of persons who run into this 
> > > yearly will have a more
> > >  authoritative flowchart of sorts to determine the next course of action.
> > >something like
> > >   if ... this thta
> > >if... this that
> > >if ... this that
> > >   OTOH... error message... a... you may need to...
> > >...
> > >error message ... r... you may need to...
> > > 
> > >  ... And it would have maybe saved a bit of time here, and I would almost 
> > > if eventually
> > >  possible be sure to copy /usr/src/UPDATING to 
> > > /usr/ports/x11/nvidia-driver for
> > >  more easy access if the desktop was broken
> > > 
> > > 
> > > Apologies for the hurried post. Indeed, I have tasked myself to write it 
> > > up here
> > > locally [ still in scribbled notations...] so I can forestall/fix more 
> > > quickly this
> > > error the next time.
> > > also...
> > > Running late  in other personal matters, and out of time.
> > > 
> > > Respectfully..
> > > 
> > > J. Bouquet 
> > > ___
> > > freebsd-curr...@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > 

Re: 64-bit inodes (ino64) Status Update and Call for Testing

[Shawn Webb]

On Mon, May 15, 2017 at 03:41:45PM -0400, Shawn Webb wrote:
> On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote:
> > Inodes are data structures corresponding to objects in a file system,
> > such as files and directories. FreeBSD has historically used 32-bit
> > values to identify inodes, which limits file systems to somewhat under
> > 2^32 objects. Many modern file systems internally use 64-bit identifiers
> > and FreeBSD needs to follow suit to properly and fully support these
> > file systems.
> > 
> > The 64-bit inode project, also known as ino64, started life many years
> > ago as a project by Gleb Kurtsou (gleb@).  After that time several
> > people have had a hand in updating it and addressing regressions, after
> > mckusick@ picked up and updated the patch, and acted as a flag-waver.
> > 
> > Sponsored by the FreeBSD Foundation I have spent a significant effort
> > on outstanding issues and integration -- fixing compat32 ABI, NFS and
> > ZFS, addressing ABI compat issues and investigating and fixing ports
> > failures.  rmacklem@ provided feedback on NFS changes, emaste@ and
> > jhb@ provided feedback and review on the ABI transition support. pho@
> > performed extensive testing and identified a number of issues that
> > have now been fixed.  kris@ performed an initial ports investigation
> > followed by an exp-run by antoine@. emaste@ helped with organization
> > of the process.
> > 
> > This note explains how to perform useful testing of the ino64 branch,
> > beyond typical smoke tests.
> > 
> > 1. Overview.
> > 
> > The ino64 branch extends the basic system types ino_t and dev_t from
> > 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit.  The struct dirent
> > layout is modified due to the larger size of ino_t, and also gains a
> > d_off (directory offset) member. As ino64 implies an ABI change anyway
> > the struct statfs f_mntfromname[] and f_mntonname[] array length
> > MNAMELEN is increased from 88 to 1024, to allow for longer mount path
> > names.
> > 
> > ABI breakage is mitigated by providing compatibility using versioned
> > symbols, ingenious use of the existing padding in structures, and by
> > employing other tricks.  Unfortunately, not everything can be fixed,
> > especially outside the base system.  For instance, third-party APIs
> > which pass struct stat around are broken in backward and forward-
> > incompatible way.
> > 
> > 2. Motivation.
> > 
> > The main risk of the ino64 change is the uncontrolled ABI breakage.
> > Due to expansion of the basic types dev_t, ino_t and struct dirent,
> > the impact is not limited to one part of the system, but affects:
> > - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo
> >   and more)
> > - libc interface (mostly related to the readdir(3), FTS(3))
> > - collateral damage in other libraries that happens to use changed types
> >   in the interfaces.  See, for instance, libprocstat, for which compat
> >   was provided using symbol versioning, and libutil, which shlib version
> >   was bumped.
> > 
> > 3. Quirks.
> > 
> > We handled kinfo sysctl MIBs, but other MIBs which report structures
> > depended on the changed type, are not handled in general.  It was
> > considered that the breakage is either in the management interfaces,
> > where we usually allow ABI slip, or is not important.
> > 
> > Struct xvnode changed layout, no compat shims are provided.
> > 
> > For struct xtty, dev_t tty device member was reduced to uint32_t.  It
> > was decided that keeping ABI compat in this case is more useful than
> > reporting 64bit dev_t, for the sake of pstat.
> > 
> > 4. Testing procedure.
> > 
> > The ino64 project can be tested by cloning the project branch from
> > GitHub or by applying the patch  > at URL | attached> to a working tree.  The authorative source is the
> > GitHub, I do not promise to update the review for each update.
> > 
> > To clone from GitHub:
> > % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64
> > 
> > To fetch the patch from Phabricator:
> > - Visit https://reviews.freebsd.org/D10439
> > - Click "Download Raw Diff" at the upper right of the page
> > 
> > Or
> > % arc patch D10439
> > 
> > After that, in the checkout directory do
> > % (cd sys/kern && touch syscalls.master && make sysent)
> > % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent)
> > If you use custom kernel configuration, ensure that
> > options COMPAT_FREEBSD11
> > is included into the config.  Then build world and kernel in the
> > usual way, install kernel, reboot, install new world.  Do not make
> > shortcuts in the update procedure.
> 
> Hey Kostik,
> 
> On my HardenedBSD system, world compiled fine with the patch, but the
> kernel didn't compile. I've uploaded the log to:
> 
> https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log
> 
> This was from importing the patch from Phabricator into
> hardened/current/master in HardenedBSD.

Update: I missed a step. Kernel and 

Re: sysutils/tmux - strange behaviour with new version 2.4

[Dewayne Geraghty]

Thanks for the hint.  That probably explains why a long awk script
misbehaved by "processing a comment", on FreeBSD 11stable amd64 updated
fortnightly. (Thought it was a bad awk, but there are other gremlins
lurking)
-- 
*Disclaimer:*



*As implied by email protocols, the information in this message is not
confidential. Any intermediary or recipient may inspect, modify (add),
copy, forward, reply to, delete, or filter email for any purpose unless
said parties are otherwise obligated.  Nothing in this message may be
legally binding without cryptographic evidence of its integrity and/or
confidentiality.*
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: 64-bit inodes (ino64) Status Update and Call for Testing

[Shawn Webb]

On Thu, Apr 20, 2017 at 10:43:14PM +0300, Konstantin Belousov wrote:
> Inodes are data structures corresponding to objects in a file system,
> such as files and directories. FreeBSD has historically used 32-bit
> values to identify inodes, which limits file systems to somewhat under
> 2^32 objects. Many modern file systems internally use 64-bit identifiers
> and FreeBSD needs to follow suit to properly and fully support these
> file systems.
> 
> The 64-bit inode project, also known as ino64, started life many years
> ago as a project by Gleb Kurtsou (gleb@).  After that time several
> people have had a hand in updating it and addressing regressions, after
> mckusick@ picked up and updated the patch, and acted as a flag-waver.
> 
> Sponsored by the FreeBSD Foundation I have spent a significant effort
> on outstanding issues and integration -- fixing compat32 ABI, NFS and
> ZFS, addressing ABI compat issues and investigating and fixing ports
> failures.  rmacklem@ provided feedback on NFS changes, emaste@ and
> jhb@ provided feedback and review on the ABI transition support. pho@
> performed extensive testing and identified a number of issues that
> have now been fixed.  kris@ performed an initial ports investigation
> followed by an exp-run by antoine@. emaste@ helped with organization
> of the process.
> 
> This note explains how to perform useful testing of the ino64 branch,
> beyond typical smoke tests.
> 
> 1. Overview.
> 
> The ino64 branch extends the basic system types ino_t and dev_t from
> 32-bit to 64-bit, and nlink_t from 16-bit to 64-bit.  The struct dirent
> layout is modified due to the larger size of ino_t, and also gains a
> d_off (directory offset) member. As ino64 implies an ABI change anyway
> the struct statfs f_mntfromname[] and f_mntonname[] array length
> MNAMELEN is increased from 88 to 1024, to allow for longer mount path
> names.
> 
> ABI breakage is mitigated by providing compatibility using versioned
> symbols, ingenious use of the existing padding in structures, and by
> employing other tricks.  Unfortunately, not everything can be fixed,
> especially outside the base system.  For instance, third-party APIs
> which pass struct stat around are broken in backward and forward-
> incompatible way.
> 
> 2. Motivation.
> 
> The main risk of the ino64 change is the uncontrolled ABI breakage.
> Due to expansion of the basic types dev_t, ino_t and struct dirent,
> the impact is not limited to one part of the system, but affects:
> - kernel/userspace interface (syscalls ABI, mostly stat(2), kinfo
>   and more)
> - libc interface (mostly related to the readdir(3), FTS(3))
> - collateral damage in other libraries that happens to use changed types
>   in the interfaces.  See, for instance, libprocstat, for which compat
>   was provided using symbol versioning, and libutil, which shlib version
>   was bumped.
> 
> 3. Quirks.
> 
> We handled kinfo sysctl MIBs, but other MIBs which report structures
> depended on the changed type, are not handled in general.  It was
> considered that the breakage is either in the management interfaces,
> where we usually allow ABI slip, or is not important.
> 
> Struct xvnode changed layout, no compat shims are provided.
> 
> For struct xtty, dev_t tty device member was reduced to uint32_t.  It
> was decided that keeping ABI compat in this case is more useful than
> reporting 64bit dev_t, for the sake of pstat.
> 
> 4. Testing procedure.
> 
> The ino64 project can be tested by cloning the project branch from
> GitHub or by applying the patch  at URL | attached> to a working tree.  The authorative source is the
> GitHub, I do not promise to update the review for each update.
> 
> To clone from GitHub:
> % git clone -b ino64 https://github.com/FreeBSDFoundation/freebsd.git ino64
> 
> To fetch the patch from Phabricator:
> - Visit https://reviews.freebsd.org/D10439
> - Click "Download Raw Diff" at the upper right of the page
> 
> Or
> % arc patch D10439
> 
> After that, in the checkout directory do
> % (cd sys/kern && touch syscalls.master && make sysent)
> % (cd sys/compat/freebsd32 && touch syscalls.master && make sysent)
> If you use custom kernel configuration, ensure that
>   options COMPAT_FREEBSD11
> is included into the config.  Then build world and kernel in the
> usual way, install kernel, reboot, install new world.  Do not make
> shortcuts in the update procedure.

Hey Kostik,

On my HardenedBSD system, world compiled fine with the patch, but the
kernel didn't compile. I've uploaded the log to:

https://hardenedbsd.org/~shawn/2017-05-15_ino64-r01.log

This was from importing the patch from Phabricator into
hardened/current/master in HardenedBSD.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: How should we name node-js ports ?

[Rodrigo Osorio]

On 05/15/17 14:57, Ruslan Makhmatkhanov wrote:

Rodrigo Osorio wrote on 05/14/2017 15:16:

Hi,

I have a bunch of nodejs ports to add, most of them as dependencies,
and I wonder if we can find a naming standard like adding 'node' or
'node-js' prefix in the name ; I personally prefer 'node'.

As a result a port who install the node package xxx will be named 
'node-xxx'


Does it sounds good to you ?

Thanks for your time,

-- rodrigo


Am I right they will be actually installed with npm? If so, it would 
make sense to name them npm-, like rubygems installed packages.



Hi Ruslan,

That sounds good to me, if everyone agrees we can move this way.

-- rodrigo
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How should we name node-js ports ?

[Rodrigo Osorio]

Hi Adam,

Thanks for your feedback.

On 05/15/17 18:52, Adam Weinberger wrote:

On 15 May, 2017, at 6:57, Ruslan Makhmatkhanov  wrote:


npm packages can be installed by yarn as well; nodejs is really the common name 
and makes a better prefix.

That said, making node ports does not sit well with me. npm/yarn manages node 
packages. Things will break if a user has those same packages installed 
globally and tries to update or remove them, or if a user needs specific global 
versions installed.

Rodrigo, I think your better option is simply to bundle those dependencies 
yourself, at the specific versions that your port requires, and install them to 
a private location.
I decide to split the dependencies in several packages and I use npm a 
short perform the package installation before
the staging. That way node packages remains available to other and can 
be reused as dependencies for others node ports.




# Adam






___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI  
wrote:

> Hi.
> If including its version to nvidia.ko and nvidia-modeset.ko,
> [hard / symbolic] link to it with current name should be needed
> not to bother admins every time upgrading.
> 
> BTW, I personally using below in rc.conf for safety.
> This only helps situations that...
> 
>  *Insufficient loader memory, but OK after kernel is started.
> 
>  *Accidentally backed to older version that doesn't have
>   nvidia-modeset.ko and only nvidia-modeset.ko is written in
>   /boot/loader.conf.
> 
> ## Temporary settings for nvidia-driver when failed loading via loader.conf
> kldstat -q -n nvidia.ko
> if [ 0 -ne $? ] ; then
>   echo "Loading nvidia-driver modules via rc.conf."
> #  kldload nvidia
>   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> #kldload nvidia-modeset
> kld_list="${kld_list} nvidia-modeset.ko"
>   else
> #kldload nvidia
> kld_list="${kld_list} nvidia.ko"
>   fi
> fi
> 
> 
> On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> "Jeffrey Bouquet"  wrote:
> 
> >  Just had a unique to me, unbootable backup [beside the point,
> > just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> > that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> > 
> >   12.0 - CURRENT
> > 
> >   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail 
> > for me to peruse as I was in the terminal ]
> > 
> > Lessons I learned, maybe
> > 
> > [RFC]  rename nvidia-driver.ko to include its version, for instance 
> > nvidia-modeset-37539.ko
> >   which would make one's diagnosis a fix easier. 
> > 
> > [suggestions]
> > 
> > ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd 
> > thus made it 'unavailable'
> > ... document better that one can load nvidia[modeset] later than 
> > /boot/loader.conf [cli, rc.conf...]
> > 
> > [ mini 'what fixed it for you '  and/or stalled the same ... 
> > ] 
> > ... I had a make.conf in place, 'trapping' a
> > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> > install in failure
> > ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> > ... I had no access to the forums, as the desktop could not be loaded [yet]
> > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> > usable module numbers,
> > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include 
> > its 5 digit number
> > as above.
> > ... I was taken aback by the less infomative
> > this client has the .39 but the module has the .26 ... 
> > specifically stating which file/port/kernel module the 'client' refers 
> > to
> >and which specific modules 'this module' was referring to.  Unknown if 
> > that is
> >fixable here in a .c, .h , or is closed-source upstream in nvidia [corp 
> > ] where we can
> > ask them to be more specific or code in some more verbose error 
> > messages.
> > ...  Relieved I did not have to rebuild Xorg nor the kernel, just move 
> > files out of the
> >   way and do a simple rebuild of the nvidia-driver.
> > [... Not relieved that the nvidia-driver needed install during the mesa-lib 
> > reshuffle,  maybe
> >did not need to be, just a hazy recollection on my part.  So ignore this 
> > little bit ]
> > 
> > ... All in all a learning experience.  Howsoever, I would like this nvidia 
> > stuff to be put eventuall
> >  in /usr/src/UPDATING so the half or third of persons who run into this 
> > yearly will have a more
> >  authoritative flowchart of sorts to determine the next course of action.
> >something like
> >   if ... this thta
> >if... this that
> >if ... this that
> >   OTOH... error message... a... you may need to...
> >...
> >error message ... r... you may need to...
> > 
> >  ... And it would have maybe saved a bit of time here, and I would almost 
> > if eventually
> >  possible be sure to copy /usr/src/UPDATING to 
> > /usr/ports/x11/nvidia-driver for
> >  more easy access if the desktop was broken
> > 
> > 
> > Apologies for the hurried post. Indeed, I have tasked myself to write it up 
> > here
> > locally [ still in scribbled notations...] so I can forestall/fix more 
> > quickly this
> > error the next time.
> > also...
> > Running late  in other personal matters, and out of time.
> > 
> > Respectfully..
> > 
> > J. Bouquet 
> > ___
> > freebsd-curr...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> 
> 
> -- 
> Tomoaki AOKI


I found just then that one can load it manually
first, though the nvidia.ko  [ one has newly built ] THEN
the nvidia-modeset.ko  

if it has not been loaded via /boot/loader.conf which did not load it
in the 

Re: sysutils/tmux - strange behaviour with new version 2.4

[DutchDaemon - FreeBSD Forums Administrator]

On 15-5-2017 19:18, Miroslav Lachman wrote:
> I noticed some strange behaviours with Tmux 2.4.
> If I run "cat /path/to/somefile.txt" sometimes part of file is missing
> in the output (no special characters in this text file, it is log of
> "pkg upgrade")
>
> And I thing some key presses are interpreted differently. (in Vim)
>
> I know that nobody can solve this without more details... so I am just
> asking if I am alone or somebody else have this problem too?
>
> Miroslav Lachman

You're ringing a bell. I wanted to mail someone the content of a shell
script, which I printed in tmux using `cat`. When I pasted the output in
my mail program it seemed to be missing a block of text, which was
commented out in the script. So there may be some unwanted interaction
going on with lines starting with #, perhaps?



signature.asc
Description: OpenPGP digital signature

sysutils/tmux - strange behaviour with new version 2.4

[Miroslav Lachman]

I noticed some strange behaviours with Tmux 2.4.
If I run "cat /path/to/somefile.txt" sometimes part of file is missing 
in the output (no special characters in this text file, it is log of 
"pkg upgrade")


And I thing some key presses are interpreted differently. (in Vim)

I know that nobody can solve this without more details... so I am just 
asking if I am alone or somebody else have this problem too?


Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How should we name node-js ports ?

[Adam Weinberger]

> On 15 May, 2017, at 6:57, Ruslan Makhmatkhanov  wrote:
> 
> Rodrigo Osorio wrote on 05/14/2017 15:16:
>> Hi,
>> I have a bunch of nodejs ports to add, most of them as dependencies,
>> and I wonder if we can find a naming standard like adding  'node' or
>> 'node-js' prefix in the name ; I personally prefer 'node'.
>> As a result a port who install the node package xxx will be named 'node-xxx'
>> Does it sounds good to you ?
>> Thanks for your time,
>> -- rodrigo
> 
> Am I right they will be actually installed with npm? If so, it would make 
> sense to name them npm-, like rubygems installed packages.

npm packages can be installed by yarn as well; nodejs is really the common name 
and makes a better prefix.

That said, making node ports does not sit well with me. npm/yarn manages node 
packages. Things will break if a user has those same packages installed 
globally and tries to update or remove them, or if a user needs specific global 
versions installed.

Rodrigo, I think your better option is simply to bundle those dependencies 
yourself, at the specific versions that your port requires, and install them to 
a private location.

# Adam


-- 
Adam Weinberger
ad...@adamw.org
https://www.adamw.org

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Which wine do I need?

[David Naylor]

On Sunday, 14 May 2017 23:23:05 Thomas Mueller wrote:
> I see several different wine ports and would like to know which I need for
> amd64 and which I need for an i386 installation.

 - On an i386 environment with 32-bit Windows binaries use lang/wine.
 - On an amd64 environment with 32-bit Windows binaries use lang/i386-wine.
 - On an amd64 environment with 64-bit Windows binaries use lang/wine.

Note: a i386 chroot would be considered an i386 environment (even if the host 
environment/kernel was amd64)

signature.asc
Description: This is a digitally signed message part.

Re: How should we name node-js ports ?

[scratch65535]

[Default] On Sun, 14 May 2017 14:16:23 +0200, Rodrigo Osorio
 wrote:

>Hi,
>
>I have a bunch of nodejs ports to add, most of them as dependencies,
>and I wonder if we can find a naming standard like adding  'node' or
>'node-js' prefix in the name ; I personally prefer 'node'.
>
>As a result a port who install the node package xxx will be named 'node-xxx'
>
>Does it sounds good to you ?

Since "node" already has a well-established general meaning that
has no immediate connection to software, it'd be much less
confusing to use "nodejs", since that *does* have a direct and
immediate connection to the software ports you plan to add.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Regression in devel/py(27)-configargparse 0.12

[Kubilay Kocak]

On 5/14/17 11:26 PM, j...@ohlste.in wrote:
> Hello,
> 
> This is a runtime dependency for py-certbot. Trying to check
> certificates I get the following error:
> 
> # certbot renew --dryrun
> An unexpected error occurred:
> AttributeError: 'tuple' object has no attribute 'add'
> Please see the logfile 'certbot.log' for more details.
> 
> # cat certbot.log
> Traceback (most recent call last):
>   File "/usr/local/bin/certbot", line 11, in 
> load_entry_point('certbot==0.13.0', 'console_scripts', 'certbot')()
>   File "/usr/local/lib/python2.7/site-packages/certbot/main.py", line
> 738, in main
> args = cli.prepare_and_parse_args(plugins, cli_args)
>   File "/usr/local/lib/python2.7/site-packages/certbot/cli.py", line
> 1072, in prepare_and_parse_args
> helpful.add_deprecated_argument("--agree-dev-preview", 0)
>   File "/usr/local/lib/python2.7/site-packages/certbot/cli.py", line
> 726, in add_deprecated_argument
> self.parser.add_argument, argument_name, num_args)
>   File "/usr/local/lib/python2.7/site-packages/certbot/util.py", line
> 440, in add_deprecated_argument
> configargparse.ACTION_TYPES_THAT_DONT_NEED_A_VALUE.add(ShowWarning)
> AttributeError: 'tuple' object has no attribute 'add'
> 
> 
> Reverting to 0.11 fixes the issue.
> 

Tracking in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219306

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Tomoaki AOKI]

Hi.
If including its version to nvidia.ko and nvidia-modeset.ko,
[hard / symbolic] link to it with current name should be needed
not to bother admins every time upgrading.

BTW, I personally using below in rc.conf for safety.
This only helps situations that...

 *Insufficient loader memory, but OK after kernel is started.

 *Accidentally backed to older version that doesn't have
  nvidia-modeset.ko and only nvidia-modeset.ko is written in
  /boot/loader.conf.

## Temporary settings for nvidia-driver when failed loading via loader.conf
kldstat -q -n nvidia.ko
if [ 0 -ne $? ] ; then
  echo "Loading nvidia-driver modules via rc.conf."
#  kldload nvidia
  if [ -e /boot/modules/nvidia-modeset.ko ] ; then
#kldload nvidia-modeset
kld_list="${kld_list} nvidia-modeset.ko"
  else
#kldload nvidia
kld_list="${kld_list} nvidia.ko"
  fi
fi


On Mon, 15 May 2017 06:41:33 -0700 (PDT)
"Jeffrey Bouquet"  wrote:

>  Just had a unique to me, unbootable backup [beside the point,
> just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> 
>   12.0 - CURRENT
> 
>   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for 
> me to peruse as I was in the terminal ]
> 
> Lessons I learned, maybe
> 
> [RFC]  rename nvidia-driver.ko to include its version, for instance 
> nvidia-modeset-37539.ko
>   which would make one's diagnosis a fix easier. 
> 
> [suggestions]
> 
> ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd 
> thus made it 'unavailable'
> ... document better that one can load nvidia[modeset] later than 
> /boot/loader.conf [cli, rc.conf...]
> 
> [ mini 'what fixed it for you '  and/or stalled the same ... 
> ] 
> ... I had a make.conf in place, 'trapping' a
> make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> install in failure
> ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> ... I had no access to the forums, as the desktop could not be loaded [yet]
> ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> usable module numbers,
> THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 
> 5 digit number
> as above.
> ... I was taken aback by the less infomative
> this client has the .39 but the module has the .26 ... 
> specifically stating which file/port/kernel module the 'client' refers to
>and which specific modules 'this module' was referring to.  Unknown if 
> that is
>fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] 
> where we can
> ask them to be more specific or code in some more verbose error messages.
> ...  Relieved I did not have to rebuild Xorg nor the kernel, just move files 
> out of the
>   way and do a simple rebuild of the nvidia-driver.
> [... Not relieved that the nvidia-driver needed install during the mesa-lib 
> reshuffle,  maybe
>did not need to be, just a hazy recollection on my part.  So ignore this 
> little bit ]
> 
> ... All in all a learning experience.  Howsoever, I would like this nvidia 
> stuff to be put eventuall
>  in /usr/src/UPDATING so the half or third of persons who run into this 
> yearly will have a more
>  authoritative flowchart of sorts to determine the next course of action.
>something like
>   if ... this thta
>if... this that
>if ... this that
>   OTOH... error message... a... you may need to...
>...
>error message ... r... you may need to...
> 
>  ... And it would have maybe saved a bit of time here, and I would almost if 
> eventually
>  possible be sure to copy /usr/src/UPDATING to 
> /usr/ports/x11/nvidia-driver for
>  more easy access if the desktop was broken
> 
> 
> Apologies for the hurried post. Indeed, I have tasked myself to write it up 
> here
> locally [ still in scribbled notations...] so I can forestall/fix more 
> quickly this
> error the next time.
> also...
> Running late  in other personal matters, and out of time.
> 
> Respectfully..
> 
> J. Bouquet 
> ___
> freebsd-curr...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


-- 
Tomoaki AOKI
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Miroslav Lachman]

Torsten Zuehlsdorff wrote on 2017/05/15 15:00:


I search the internet and didn't found any problem reports for this.

PHP manual still shows this
http://php.net/manual/en/mssql.requirements.php


If you read the manual this section is very important:
This extension is not available anymore on Windows with PHP 5.3 or later.


Yes, I know that, but the important part is "Windows". I think it was 
due to some licence / patent issue. For Windows there is SQLSRV provided 
by Microsoft for a long time.



(Don't ask me why its available up to PHP 5.6)


Because limitation was for Windows and not unix-like systems :)


When dealing with MS SQL you have (out of my limited experience - i
avoid it when possible) basically two options:
- Using odbc (http://php.net/manual/en/book.uodbc.php)
- Using PDO-MS SQL (http://php.net/manual/en/ref.pdo-sqlsrv.php)


I know about this but it is very bad for all of our legacy projects and 
webapplications - nobody want to rewrite them.



But one step back: i'm not really sure why there is no port and FreeTDS.
If you have some time i will check if i can recreate the php56-mssql
port for php70 and php71. After this i can give an answer with greater
detail.


It would be very nice if we can continue to use mssql_connect and other 
functions from phpXX-mssql extension.


Thanks in advance

Miroslav Lachman

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

[RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

 Just had a unique to me, unbootable backup [beside the point,
just a sidebar comment... ]  quandry dealing with the nvidia-driver update
that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]

  12.0 - CURRENT

  [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for 
me to peruse as I was in the terminal ]

Lessons I learned, maybe

[RFC]  rename nvidia-driver.ko to include its version, for instance 
nvidia-modeset-37539.ko
  which would make one's diagnosis a fix easier. 

[suggestions]

... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus 
made it 'unavailable'
... document better that one can load nvidia[modeset] later than 
/boot/loader.conf [cli, rc.conf...]

[ mini 'what fixed it for you '  and/or stalled the same ... 
] 
... I had a make.conf in place, 'trapping' a
make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
install in failure
... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
... I had no access to the forums, as the desktop could not be loaded [yet]
... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable 
module numbers,
THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 
digit number
as above.
... I was taken aback by the less infomative
this client has the .39 but the module has the .26 ... 
specifically stating which file/port/kernel module the 'client' refers to
   and which specific modules 'this module' was referring to.  Unknown if that 
is
   fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] 
where we can
ask them to be more specific or code in some more verbose error messages.
...  Relieved I did not have to rebuild Xorg nor the kernel, just move files 
out of the
  way and do a simple rebuild of the nvidia-driver.
[... Not relieved that the nvidia-driver needed install during the mesa-lib 
reshuffle,  maybe
   did not need to be, just a hazy recollection on my part.  So ignore this 
little bit ]

... All in all a learning experience.  Howsoever, I would like this nvidia 
stuff to be put eventuall
 in /usr/src/UPDATING so the half or third of persons who run into this yearly 
will have a more
 authoritative flowchart of sorts to determine the next course of action.
   something like
  if ... this thta
   if... this that
   if ... this that
  OTOH... error message... a... you may need to...
   ...
   error message ... r... you may need to...

 ... And it would have maybe saved a bit of time here, and I would almost if 
eventually
 possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver 
for
 more easy access if the desktop was broken


Apologies for the hurried post. Indeed, I have tasked myself to write it up here
locally [ still in scribbled notations...] so I can forestall/fix more quickly 
this
error the next time.
also...
Running late  in other personal matters, and out of time.

Respectfully..

J. Bouquet 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Martin Wilke]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When I've ported php7 to FreeBSD the mssql part was not ported,

https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts?s%5B%5D=mssql

I am not sure if there was a change since 7.1 have been relased.

- - Martin


On Mon, May 15, 2017 at 03:00:37PM +0200, Torsten Zuehlsdorff wrote:
> Hello Miroslav,
> 
> On 15.05.2017 14:53, Miroslav Lachman wrote:
> > We are using php56-mssql for connecting to some MSSQL servers and we are
> > planning to upgrade to PHP 7.1 now but unfortunately I cannot find
> > php71-mssql port.
> > Why is it missing? Are there any problems to build this extension for
> > PHP 7.1?
> > 
> > I search the internet and didn't found any problem reports for this.
> > 
> > PHP manual still shows this http://php.net/manual/en/mssql.requirements.php
> 
> If you read the manual this section is very important:
> This extension is not available anymore on Windows with PHP 5.3 or later.
> 
> (Don't ask me why its available up to PHP 5.6)
> 
> When dealing with MS SQL you have (out of my limited experience - i avoid it
> when possible) basically two options:
> - Using odbc (http://php.net/manual/en/book.uodbc.php)
> - Using PDO-MS SQL (http://php.net/manual/en/ref.pdo-sqlsrv.php)
> 
> But one step back: i'm not really sure why there is no port and FreeTDS. If
> you have some time i will check if i can recreate the php56-mssql port for
> php70 and php71. After this i can give an answer with greater detail.
> 
> Greetings,
> Torsten
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

- -- 
+-oOO--(_)--OOo-+
With best Regards,
Martin Wilke (miwi_(at)_FreeBSD.org)


  Mess with the Best, Die like the Rest


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJZGbIcAAoJEB8/xmUxOhJn6ZAH/2ntmmyUzoL0vMSiDox+s55c
e3BF1i3sMTYkRLzB26W/1HGk9CxhrWxc/GPHv8tXkS/Hm0CupQeviQoiC5yuQWfx
iVXBLRU/Nh6cu4eBlD7LncG/2nJ5+UNa7SjXpQuKef+6YKWWJoLim3SbJPOluQcl
u75sR4gVYtg3LJ8Ot2DtD2q3ZTx4kvbVZGnufgaKi4sOmOphUEFXnSuGQeJlWYsg
g4N3y7d/EoMi7CpUDEuDaUhktTd25sYbGTsWaRDChts/aZdOfYubww9BeVIR3mpn
PX8Yh0gDGgg2yz8806x2SBhGR1BwWWANW0G7l2YyJJkiZ6CtZw4ZAFdx+OOZXok=
=5Ct+
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Franco Fichtner]

> On 15. May 2017, at 3:01 PM, Torsten Zuehlsdorff  wrote:
> 
>>> We are using php56-mssql for connecting to some MSSQL servers and we are 
>>> planning to upgrade to PHP 7.1 now but unfortunately I cannot find 
>>> php71-mssql port.
>>> Why is it missing? Are there any problems to build this extension for PHP 
>>> 7.1?
>> PHP 7 does not have mysql anymore, only mysqli.
> 
> He asked for mSsql not mYsql. ;)

True, sorry for the noise.  :)


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Bug report assistance

[Karli Sjöberg via freebsd-ports]

On Mon, 2017-05-15 at 13:16 +0200, Kurt Jaeger wrote:
> Hi!
> 
> > I would like to know what I can do to help progress a bug report
> > further. I have had my eyes on bug 212420 for four months now, and
> > proposed a solution about two months ago but I haven't gotten any
> > responses back so far.
> > 
> > What can I do, more than adding to the bug report (that no one
> > seems to
> > read), to help resolve this bug report?
> 
> Posting here helps. And yes, the changes you propose are complex,
> so the number of committers able to work on that is smaller.
> 
> If I find a quiet hour, I'll have a look but I can not
> promise anything.
> 

Thank you Kurt, I appreciate it!

/K
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Torsten Zuehlsdorff]

Aloha Franco,


We are using php56-mssql for connecting to some MSSQL servers and we are 
planning to upgrade to PHP 7.1 now but unfortunately I cannot find php71-mssql 
port.
Why is it missing? Are there any problems to build this extension for PHP 7.1?


PHP 7 does not have mysql anymore, only mysqli.


He asked for mSsql not mYsql. ;)

Greetings,
Torsten

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: How should we name node-js ports ?

[Ruslan Makhmatkhanov]

Rodrigo Osorio wrote on 05/14/2017 15:16:

Hi,

I have a bunch of nodejs ports to add, most of them as dependencies,
and I wonder if we can find a naming standard like adding  'node' or
'node-js' prefix in the name ; I personally prefer 'node'.

As a result a port who install the node package xxx will be named 
'node-xxx'


Does it sounds good to you ?

Thanks for your time,

-- rodrigo


Am I right they will be actually installed with npm? If so, it would 
make sense to name them npm-, like rubygems installed packages.


--
Regards,
Ruslan

T.O.S. Of Reality
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Torsten Zuehlsdorff]

Hello Miroslav,

On 15.05.2017 14:53, Miroslav Lachman wrote:
We are using php56-mssql for connecting to some MSSQL servers and we are 
planning to upgrade to PHP 7.1 now but unfortunately I cannot find 
php71-mssql port.
Why is it missing? Are there any problems to build this extension for 
PHP 7.1?


I search the internet and didn't found any problem reports for this.

PHP manual still shows this http://php.net/manual/en/mssql.requirements.php


If you read the manual this section is very important:
This extension is not available anymore on Windows with PHP 5.3 or later.

(Don't ask me why its available up to PHP 5.6)

When dealing with MS SQL you have (out of my limited experience - i 
avoid it when possible) basically two options:

- Using odbc (http://php.net/manual/en/book.uodbc.php)
- Using PDO-MS SQL (http://php.net/manual/en/ref.pdo-sqlsrv.php)

But one step back: i'm not really sure why there is no port and FreeTDS. 
If you have some time i will check if i can recreate the php56-mssql 
port for php70 and php71. After this i can give an answer with greater 
detail.


Greetings,
Torsten
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Franco Fichtner]

> On 15. May 2017, at 2:53 PM, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> We are using php56-mssql for connecting to some MSSQL servers and we are 
> planning to upgrade to PHP 7.1 now but unfortunately I cannot find 
> php71-mssql port.
> Why is it missing? Are there any problems to build this extension for PHP 7.1?

PHP 7 does not have mysql anymore, only mysqli.


Cheers,
Franco
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

FreeBSD Port: lang/php71-extensions - missing php71-mssql

[Miroslav Lachman]

We are using php56-mssql for connecting to some MSSQL servers and we are 
planning to upgrade to PHP 7.1 now but unfortunately I cannot find 
php71-mssql port.
Why is it missing? Are there any problems to build this extension for 
PHP 7.1?


I search the internet and didn't found any problem reports for this.

PHP manual still shows this http://php.net/manual/en/mssql.requirements.php

And I also found this Github project 
https://github.com/Microsoft/msphpsql but I don't know if it is 
something different than what php56-mssql is.



Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Bug report assistance

[Kurt Jaeger]

Hi!

> I would like to know what I can do to help progress a bug report
> further. I have had my eyes on bug 212420 for four months now, and
> proposed a solution about two months ago but I haven't gotten any
> responses back so far.
> 
> What can I do, more than adding to the bug report (that no one seems to
> read), to help resolve this bug report?

Posting here helps. And yes, the changes you propose are complex,
so the number of committers able to work on that is smaller.

If I find a quiet hour, I'll have a look but I can not
promise anything.

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Bug report assistance

[Karli Sjöberg via freebsd-ports]

Hey all!

I would like to know what I can do to help progress a bug report
further. I have had my eyes on bug 212420 for four months now, and
proposed a solution about two months ago but I haven´t gotten any
responses back so far.

What can I do, more than adding to the bug report (that no one seems to
read), to help resolve this bug report?

Thanks in advance!
Karli Sjöberg
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: mesa libs issue

[Herbert J. Skuhra]

Jan Beich skrev:
> 
> Maybe try the following:
> 
>   $ pkg set -n dri:mesa-dri
>   $ pkg set -o graphics/dri:graphics/mesa-dri
> 
>   $ pkg set -n libglapi:mesa-libs
>   $ pkg set -o graphics/libglapi:graphics/mesa-libs
> 
>   $ pkg set -n libGL:mesa-libs
>   $ pkg set -o graphics/libGL:graphics/mesa-libs
> 
>   $ pkg set -n gbm:mesa-libs
>   $ pkg set -o graphics/gbm:graphics/mesa-libs
> 
>   $ pkg set -n libEGL:mesa-libs
>   $ pkg set -o graphics/libEGL:graphics/mesa-libs
> 
>   $ pkg set -n libglesv2:mesa-libs
>   $ pkg set -o graphics/libglesv2:graphics/mesa-libs

I tried this, but for gbm and libEGL I get:

pkg: sqlite error while executing UPDATE deps SET name = ?1,
version=(SELECT version FROM packages WHERE name = ?1) WHERE
package_id = ?2 AND name = ?3 in file pkgdb.c:2622: UNIQUE constraint
failed: deps.name, deps.version, deps.package_id

--
Herbert
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

lxsession/consolekit problem

[Bob Eager]

I've been struggling with this for a few days, so in desperation I'm
asking!

I've installed FreeBSD-11-STABLE. Latest ports tree (as of a few days
ago).

I have installed xorg and LXDE. My .xinitrc contains just:

  exec startlxde

When I use startx, the screen turns graphical, and I get a dialog box
that says:

 GDBus.Error:org.freedesktop.ConsoleKit.Manager.GeneralError: Unable to lookup 
session information for process '5389'

5389 is lxsession. If I acknowledge the box, LXDE then seems to load
OK, and work. But I'm uneasy.

As far as I can tell, ConsoleKit is looking for an environment variable
called XDG_SESSION_COOKIE - which doesn't appear to be there. Noen of
the documentation seems to help much.

Any ideas, please?
-- 
Bob

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"