Re: "Confused" PORTREVISION

2017-12-24 Thread Kevin Oberman 
On Sun, Dec 24, 2017 at 10:18 PM, Adam Weinberger  wrote:

> On 24 Dec, 2017, at 23:09, Kevin Oberman  wrote:
>>
>> On Sun, Dec 24, 2017 at 9:27 PM, Adam Weinberger  wrote:
>> On 24 Dec, 2017, at 22:23, Kevin Oberman  wrote:
>>
>> On Sun, Dec 24, 2017 at 9:18 PM, Adam Weinberger  wrote:
>> On 24 Dec, 2017, at 20:03, Walter Schwarzenfeld <
>> w.schwarzenf...@utanet.at> wrote:
>>
>> But
>>
>> RUBY_RELVERSION=2.3.6
>> RUBY_PORTREVISION=  0 <=
>> RUBY_PORTEPOCH= 1
>> RUBY_PATCHLEVEL=0
>> RUBY23= ""  # PLIST_SUB helpers
>>
>> PORTREVISION=0 confuses pkg version
>>
>> pkg version |grep ruby23
>> ruby23-2.3.6,1   <
>>
>> this is the version which is installed.
>>
>> PORTREVISION=0 is treated as if it were unset. Some people prefer using
>> that construct because it keeps line numbers consistent in the SVN history.
>>
>> # Adam
>>
>> The Porters Handbook now calls for the use of portrevision=0.
>>
>> It does? I wasn't aware of that.
>>
>> # Adam
>>
>> I learned about this when i submitted a port update to a new release and
>> the committer added PORTREVISION=0. He told me that it was now the approved
>> way if doing ports.
>>
>> 5.2.3.1
>>
>> PORTREVISION is a monotonically increasing value which is reset to 0 with
>> every increase of DISTVERSION, typically every time there is a new official
>> vendor release. If PORTREVISION is non-zero, the value is appended to the
>> package name. Changes toPORTREVISION are used by automated tools like
>> pkg-version(8) to determine that a new package is available.
>>
>
> So that block isn't saying that 'PORTREVISION=0' is the official thing.
> It's saying that the value needs to be reset to 0. Removing the line
> entirely is still the preferred way of resetting it to zero.
>
> # Adam
>
>
> --
> Adam Weinberger
> ad...@adamw.org
> http://www.adamw.org
>

I don't see how it can be read that way. The It says that it is bumped
every time the port is modified (sort of, as there is specific detail on
whether it is bumped) and reset to 0 when the DISTVERSION changes. Nothing
says or implies that it should be removed to do the reset. I think it is
quite clear. I also am seeing this in many other ports including a couple I
have submitted.
--
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: "Confused" PORTREVISION

2017-12-24 Thread Adam Weinberger 

On 24 Dec, 2017, at 23:09, Kevin Oberman  wrote:

On Sun, Dec 24, 2017 at 9:27 PM, Adam Weinberger  wrote:
On 24 Dec, 2017, at 22:23, Kevin Oberman  wrote:

On Sun, Dec 24, 2017 at 9:18 PM, Adam Weinberger  wrote:
On 24 Dec, 2017, at 20:03, Walter Schwarzenfeld  
 wrote:


But

RUBY_RELVERSION=2.3.6
RUBY_PORTREVISION=  0 <=
RUBY_PORTEPOCH= 1
RUBY_PATCHLEVEL=0
RUBY23= ""  # PLIST_SUB helpers

PORTREVISION=0 confuses pkg version

pkg version |grep ruby23
ruby23-2.3.6,1   <

this is the version which is installed.

PORTREVISION=0 is treated as if it were unset. Some people prefer using  
that construct because it keeps line numbers consistent in the SVN  
history.


# Adam

The Porters Handbook now calls for the use of portrevision=0.

It does? I wasn't aware of that.

# Adam

I learned about this when i submitted a port update to a new release and  
the committer added PORTREVISION=0. He told me that it was now the  
approved way if doing ports.


5.2.3.1

PORTREVISION is a monotonically increasing value which is reset to 0 with  
every increase of DISTVERSION, typically every time there is a new  
official vendor release. If PORTREVISION is non-zero, the value is  
appended to the package name. Changes toPORTREVISION are used by  
automated tools like pkg-version(8) to determine that a new package is  
available.


So that block isn't saying that 'PORTREVISION=0' is the official thing.  
It's saying that the value needs to be reset to 0. Removing the line  
entirely is still the preferred way of resetting it to zero.


# Adam


--
Adam Weinberger
ad...@adamw.org
http://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: "Confused" PORTREVISION

2017-12-24 Thread Kevin Oberman 
On Sun, Dec 24, 2017 at 9:27 PM, Adam Weinberger  wrote:

> On 24 Dec, 2017, at 22:23, Kevin Oberman  wrote:
>>
>> On Sun, Dec 24, 2017 at 9:18 PM, Adam Weinberger  wrote:
>> On 24 Dec, 2017, at 20:03, Walter Schwarzenfeld <
>> w.schwarzenf...@utanet.at> wrote:
>>
>> But
>>
>> RUBY_RELVERSION=2.3.6
>> RUBY_PORTREVISION=  0 <=
>> RUBY_PORTEPOCH= 1
>> RUBY_PATCHLEVEL=0
>> RUBY23= ""  # PLIST_SUB helpers
>>
>> PORTREVISION=0 confuses pkg version
>>
>> pkg version |grep ruby23
>> ruby23-2.3.6,1   <
>>
>> this is the version which is installed.
>>
>> PORTREVISION=0 is treated as if it were unset. Some people prefer using
>> that construct because it keeps line numbers consistent in the SVN history.
>>
>> # Adam
>>
>> The Porters Handbook now calls for the use of portrevision=0.
>>
>
> It does? I wasn't aware of that.
>
> # Adam
>

I learned about this when i submitted a port update to a new release and
the committer added PORTREVISION=0. He told me that it was now the approved
way if doing ports.

5.2.3.1

PORTREVISION is a monotonically increasing value which is reset to 0 with
every increase of DISTVERSION, typically every time there is a new official
vendor release. If PORTREVISION is non-zero, the value is appended to the
package name. Changes to PORTREVISION are used by automated tools like
pkg-version(8)

to determine that a new package is available.
--
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: "Confused" PORTREVISION

2017-12-24 Thread Walter Schwarzenfeld 

Der Problem seems was complete another one.

After this I saw default version of ruby is 2.4.

Ruby-bdb fails to install. So  I guess it was mix of ruby 2.3 and 2.4 ports.

After upgrade to 2.4, no such problems anymore.

After upgrade there was no such problem anymore.


(But no entry in /usr/port/UPDATING).

___
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: "Confused" PORTREVISION

2017-12-24 Thread Adam Weinberger 

On 24 Dec, 2017, at 22:23, Kevin Oberman  wrote:

On Sun, Dec 24, 2017 at 9:18 PM, Adam Weinberger  wrote:
On 24 Dec, 2017, at 20:03, Walter Schwarzenfeld  
 wrote:


But

RUBY_RELVERSION=2.3.6
RUBY_PORTREVISION=  0 <=
RUBY_PORTEPOCH= 1
RUBY_PATCHLEVEL=0
RUBY23= ""  # PLIST_SUB helpers

PORTREVISION=0 confuses pkg version

pkg version |grep ruby23
ruby23-2.3.6,1   <

this is the version which is installed.

PORTREVISION=0 is treated as if it were unset. Some people prefer using  
that construct because it keeps line numbers consistent in the SVN  
history.


# Adam

The Porters Handbook now calls for the use of portrevision=0.


It does? I wasn't aware of that.

# Adam


--
Adam Weinberger
ad...@adamw.org
http://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: "Confused" PORTREVISION

2017-12-24 Thread Kevin Oberman 
On Sun, Dec 24, 2017 at 9:18 PM, Adam Weinberger  wrote:

> On 24 Dec, 2017, at 20:03, Walter Schwarzenfeld 
>> wrote:
>>
>> But
>>
>> RUBY_RELVERSION=2.3.6
>> RUBY_PORTREVISION=  0 <=
>> RUBY_PORTEPOCH= 1
>> RUBY_PATCHLEVEL=0
>> RUBY23= ""  # PLIST_SUB helpers
>>
>> PORTREVISION=0 confuses pkg version
>>
>> pkg version |grep ruby23
>> ruby23-2.3.6,1   <
>>
>> this is the version which is installed.
>>
>
> PORTREVISION=0 is treated as if it were unset. Some people prefer using
> that construct because it keeps line numbers consistent in the SVN history.
>
> # Adam


The Porters Handbook now calls for the use of portrevision=0.
--
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: "Confused" PORTREVISION

2017-12-24 Thread Adam Weinberger 
On 24 Dec, 2017, at 20:03, Walter Schwarzenfeld  
 wrote:


But

RUBY_RELVERSION=2.3.6
RUBY_PORTREVISION=  0 <=
RUBY_PORTEPOCH= 1
RUBY_PATCHLEVEL=0
RUBY23= ""  # PLIST_SUB helpers

PORTREVISION=0 confuses pkg version

pkg version |grep ruby23
ruby23-2.3.6,1   <

this is the version which is installed.


PORTREVISION=0 is treated as if it were unset. Some people prefer using  
that construct because it keeps line numbers consistent in the SVN history.


# Adam


--
Adam Weinberger
ad...@adamw.org
http://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"

security/nss vs. TARGET_ARCH=powerpc : error: comparison of constant 18446744073709551615 with expression of type 'unsigned long' is always true

2017-12-24 Thread Mark Millard 
[I experiment with using clang as the system
compiler on/for powerpc (and powerpc64).]

Just an FYI. . .

When I attempted to build updated ( -r457194 ) ports
in poudriere in my clang-based (32-bit) powerpc
environment, security/nss failed with:

pqg.c:345:16: error: comparison of constant 18446744073709551615 with 
expression of type 'unsigned long' is always true 
[-Werror,-Wtautological-constant-out-of-range-compare]
if (addend < MP_DIGIT_MAX) {
~~ ^ 
1 error generated.

( security/nss is an indirect build item,
not something I listed to build directly.)

This was under head -r326075 where world was
cross built with system clang. (kernel fails
to link various things when system clang is
used so was built via gcc 4.2.1 .)

I do not know if other 32 bit contexts have
similar issues.

===
Mark Millard
markmi at dsl-only.net

___
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: OSS Audio

2017-12-24 Thread blubee blubeeme 
On Fri, Dec 22, 2017 at 9:31 PM, Sid  wrote:

> OSS soundcard.h for FreeBSD stable and current
> https://svn.freebsd.org/base/stable/11/sys/sys/
> https://svn.freebsd.org/base/head/sys/sys/
>
> blubee blubeeme; Mon Dec 11 17:03:10 UTC 2017
> > I'm taking a look at soundcard.h in /usr/include/sys/soundcard.h in
> FreeBSD
> > vs the soundcard.h in the offical OSS 4.01
> > https://sourceforge.net/p/opensound/git/ci/master/tree/
> include/soundcard.h
>
> > It seems like there's been a lot of changes between FreeBSD 3.8ish
> version
> > and the 4.0 version.
>
> > I was grepping around to see if any other files included this soundcard.h
> > header and if updating to the latest would break any other programs.
>

I've been looking into this for a bit now and these ioctl seems missing or
returning strange values.

SNDCTL_DSP_COOKEDMODE
SNDCTL_MIDIINFO
SNDCTL_MIX_ENUMINFO
SNDCTL_MIX_EXTINFO
SNDCTL_CARDINFO
SNDCTL_GETLABEL
SNDCTL_SETLABEL
SNDCTL_GETSONG
SNDCTL_SETNAME
SNDCTL_DSP_GET_CHNORDER

oss_digital_control and it's related data structures seems to be missing,
that needed for digital sources.
SNDCTL_DSP_READCTL
SNDCTL_DSP_WRITECTL

The might be implemented in other places if so, where?
___
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: "Confused" PORTREVISION

2017-12-24 Thread Walter Schwarzenfeld 

But

RUBY_RELVERSION=    2.3.6
RUBY_PORTREVISION=  0 <=
RUBY_PORTEPOCH= 1
RUBY_PATCHLEVEL=    0
RUBY23= ""  # PLIST_SUB helpers

PORTREVISION=0 confuses pkg version

pkg version |grep ruby23
ruby23-2.3.6,1   <

this is the version which is installed.

___
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: "Confused" PORTREVISION

2017-12-24 Thread Walter Schwarzenfeld 

sorry, was my error, seems I am confused ;-))

puzzled revision and portepoch.

___
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: "Confused" PORTREVISION

2017-12-24 Thread Walter Schwarzenfeld 

in my first line was a copy/paste error:

 pkg info ruby
ruby-2.3.6,1
Name   : ruby
Version    : 2.3.6,1

___
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"

"Confused" PORTREVISION

2017-12-24 Thread Walter Schwarzenfeld 
maybe a minor "problem" (I saw it cause portrac find it to update, but 
it is updated).


lang/ruby

Name   : ruby
Version    : 2.3.6,1

make -V RUBY_PORTREVISION
0
make -V PORTREVISION
0

may be a problem for this condition in the Makefile

 84 .if ${PORTREVISION} != 0
 85 _SUF1=  _${PORTREVISION}
 86 .endif
 87
 88 .if ${PORTEPOCH} != 0
 89 _SUF2=  ,${PORTEPOCH}
 90 .endif

___
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: Canberra

2017-12-24 Thread Sid 
> blubee blubeeme; Sun Dec 24 06:31:00 UTC 2017

> If you wrote that makefile that removes all the gtk stuff, you can either
> try to get it to Marcus and see if he's
> willing to use that.

> If you'd like me to work on the OSS audio portion, drop me that Makefile
> and I'll look at it in a bit.

This one just uses libcaberra/Makefile, and removes the inclusion of 
libcanberra-gtk3/Makefile, which requires gtk3. It takes the options for 
gstreamer1 and pulseaudio and includes them from this file. gtk2 and gtk3 
references were removed.

Now more ports that ask for libcanberra-gtk3 require it. I haven't tested 
removing references to pkg and sourcecode of libcanberra-gtk from those ports' 
source code. It would be better to have a drop in replacement.

It depends on what the Makefile is instructed to build to get basic 
libcanberra.so. Optionally, gstreamer1 and pulseaudio can be split into its own 
port as libcanberra-plugins.
 
Here's my Makefile -->

# Created by: Joe Marcus Clarke 
# $FreeBSD: head/audio/libcanberra/Makefile 428129 2016-12-08 15:38:24Z tijl $
#   $MCom: ports/trunk/audio/libcanberra/Makefile 20031 2014-11-02 21:47:55Z 
kwm $

PORTNAME=   libcanberra
PKGNAMESUFFIX=  -lite
PORTVERSION=0.30
PORTREVISION=   4
CATEGORIES= audio devel
MASTER_SITES=   http://0pointer.de/lennart/projects/libcanberra/ \

http://pkgs.fedoraproject.org/repo/pkgs/libcanberra/libcanberra-0.30.tar.xz/34cb7e4430afaf6f447c4ebdb9b42072/

MAINTAINER= gn...@freebsd.org
COMMENT=Implementation of the Freedesktop sound theme spec

CONFLICTS=  libcanberra

LICENSE=LGPL21
LICENSE_FILE=   ${WRKSRC}/LGPL

LIB_DEPENDS=libvorbisfile.so:audio/libvorbis \
libltdl.so:devel/libltdl

USES=   gmake libtool pathfix pkgconfig tar:xz
USE_GNOME=  gnomeprefix
USE_LDCONFIG=   yes
GNU_CONFIGURE=  yes
CONFIGURE_ARGS= --disable-lynx --disable-tdb --disable-alsa --disable-gtk3 
--disable-gtk2
CPPFLAGS+=  -I${LOCALBASE}/include
LDFLAGS+=   -L${LOCALBASE}/lib
INSTALL_TARGET= install-strip

OPTIONS_DEFINE= PULSEAUDIO GSTREAMER

PLIST_SUB=  VERSION=${PORTVERSION}

.include 

.if ${PORT_OPTIONS:MPULSEAUDIO}
LIB_DEPENDS+=   libpulse.so:audio/pulseaudio
PLIST_SUB+= PULSE=""
.else
CONFIGURE_ARGS+=--disable-pulse
PLIST_SUB+= PULSE="@comment "
.endif

.if ${PORT_OPTIONS:MGSTREAMER}
USE_GSTREAMER1= yes
PLIST_SUB+= GSTREAMER=""
.else
CONFIGURE_ARGS+=--disable-gstreamer
PLIST_SUB+= GSTREAMER="@comment "
.endif


post-patch:
@${REINPLACE_CMD} -e 's|-Wmissing-include-dirs||g' \
${WRKSRC}/configure

.include 
___
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: Are these Emacs ports still useful?

2017-12-24 Thread Joseph Mingrone 
Joseph Mingrone  writes:
> - japanese/egg-canna/Makefile (does not build with emacs versions >= 23)
> - japanese/migemo-emacs23

Are you Ok if I remove these ports immediately, since Emacs version 23 was 
removed from the
ports tree in 2014.

Joseph


signature.asc
Description: PGP signature

Re: License and adopting software

2017-12-24 Thread Sid 
If the author doesn't respond, it's best to move on. Either use their GPL, or 
completely rewrite it, to avoid infringing on their work. It should be in it's 
own separate files, so it doesn't get absorbed into that other work's more 
restrictive license, before it is its own work. You'll need to look more into 
that.

Their copyright of the work is what you have to avoid, which is allowed for use 
by its respective license variant: GPL, LGPL, BSD, ISC, Apache, MIT, etc.

These publications help with what constitutes general and software copyright, 
to avoid infringing on developers' licensed copyrights.
https://www.copyright.gov/circs/circ01.pdf - Copyright Basics
https://www.copyright.gov/circs/circ33.pdf - Works not Protected by Copyright
https://www.copyright.gov/circs/circ61.pdf - Copyright Registration of Computer 
Programs
There are other organizing bodies on copyright, that will convey useful 
information too.

"The copyright law does not protect the func-
tional aspects of a computer program, such as the program’s 
algorithms, formatting, functions, logic, or system design."

An "ad minima" such as adding obvious words and minimum content like "an" or 
"the" also don't account for copyright protection. Lists and facts don't 
account for copyright.
I don't really understand, if the section "Derivative Computer Programs" in 
circ61 is referring to an author's own work, or others' works. This is worth 
investigating.

The core FreeBSD was rewritten from scratch, as in completely different code 
that accomplished the objective of removed code. It's like the difference 
between a car, shoes, a motorcycle, a bicycle, a scooter, a train, and a dolly 
for function of transport, that most have the inclusion of the common public 
domain wheel.

I'm not familiar with code. But when there's a story, set of facts, other 
ideas, or other information, there are many ways to write about it, without 
infringing on a copyright. There are many summaries, or book reports that don't 
infringe on the author's work, but they all accomplish the task of depicting 
that work. Drawings are a little different: freehand drawing still violates a 
copyright of the original work, even if the end result looks fundamentally 
different than the photo it is from.

I hope this clears up some ideas about licenses, and their relation to what is 
covered by softwares' respective copyrights.
___
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"